MicroVM イメージ

このセクションでは、MicroVM イメージを構築、設定、更新、管理する方法について説明します。

MicroVM イメージは、MicroVM のファイルシステムとアプリケーション環境を定義するリソースです。MicroVM イメージには、ランタイム環境、アプリケーションコード、サポートプログラム (バックグラウンドプロセスやオブザーバビリティエージェントなど) が含まれます。MicroVM イメージを作成するには、Dockerfile とアプリケーションアーティファクトを含む zip パッケージを Amazon S3 にアップロードします。Dockerfile は、アプリケーションをパッケージ化する方法を定義します。Lambda は、Lambda が管理する MicroVM ベースイメージによって提供されるオペレーティングシステム環境上で Dockerfile を実行して、アプリケーションコンテナイメージを構築します。MicroVM ベースイメージについては、以下の「MicroVM ベースイメージ」セクションで説明します。

MicroVM ベースイメージを更新して、MicroVM のアプリケーションコードまたは設定を更新できます。更新をトリガーするたびに新しい MicroVM イメージバージョンが作成されます。

Lambda が MicroVM イメージを構築する方法

MicroVM イメージを作成すると、Lambda は次の処理を行います。

スナップショットプロセスが完了すると、MicroVM イメージは CREATED 状態になります。これで、この MicroVM イメージを使用して MicroVM を作成し、各 MicroVM イメージを使用して複数の独立した MicroVM を作成できるようになります。MicroVM イメージから実行される MicroVM は、スナップショットされた状態から直接再開されるため、起動時間が短縮されます。各 MicroVM イメージを使用して、アカウントでの使用制限まで複数の MicroVM を実行できます。

コードをパッケージ化して最初の MicroVM イメージを作成するステップバイステップのウィークスルーについては、「最初の MicroVM を作成する」を参照してください。

MicroVM のサイズを設定する

Lambda MicroVMs は、ベースラインピークモデルを使用するため、ピークアクティビティに合わせて各コンピューティング環境を適切なサイズにする必要がなくなります。ユーザーは、MicroVM のベースラインコンピューティングリソースを設定します。ピーク時のアクティビティ中、MicroVM はベースラインの 4 倍まで垂直方向に自動的にスケールできます。ベースライン料金は MicroVM の実行中に発生し、ベースラインを超えてアクティブに使用した分に対してのみ 1 秒あたりの請求が行われます。

MicroVM イメージの作成時に memory パラメータを使用してベースラインを設定します。vCPU はメモリに比例してスケールします (2 GB = 1 vCPU)。デフォルトのベースラインは 2 GB あたり 1 つの vCPU です。

次の表では使用できるサイズの一覧を示します。

MicroVM ベースイメージ

MicroVM ベースイメージは、MicroVM イメージの基盤として機能します。Lambda は、MicroVM を実行するのに必要な Amazon Linux 2023 オペレーティングシステムとサービスコンポーネントを提供する MicroVM ベースイメージをパブリッシュします。MicroVM イメージを作成または更新すると、Lambda は、このベースイメージから新しい MicroVM を起動し、このオペレーティングシステム環境内で Dockerfile 命令を実行します。

Lambda は、サービスマネージド MicroVM ベースイメージの新しいバージョンを定期的 (セキュリティパッチの適用時など) にリリースして、オペレーティングシステムやサービスコンポーネントを更新します。デフォルトでは、独自の MicroVM イメージを作成/更新するときに、サービスマネージドベースイメージの最新バージョンが適用されます。トラブルシューティングまたはデバッグの目的で、base-image-version パラメータを使用して独自の MicroVM イメージを作成するときにサービスマネージドベースのイメージのバージョンを上書きできます (オプション)。

ベースイメージのバージョンは廃止ライフサイクルに従います。

最新の状態を維持するには、廃止通知をモニタリングし、新しいベースイメージバージョンがリリースされたときに MicroVM イメージを再構築します。

MicroVM ベースイメージは、Dockerfiles で指定されたコンテナベースイメージとは異なることに注意してください。前者は MicroVM のオペレーティングシステム環境を定義しますが、後者は Lambda MicroVMs で使用するアプリケーションをパッケージ化するときに使用するベースコンテナイメージを定義します。詳細については、「コンテナベースイメージ」セクションを参照してください。

次の API を使用して利用可能なマネージド MicroVM ベースイメージとそのバージョンを検出します。

# List all managed MicroVM base images
aws lambda-microvms list-managed-microvm-images

# List the versions of a specific managed MicroVM base image
aws lambda-microvms list-managed-microvm-image-versions \
  --image-identifier arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1

MicroVM イメージビルドフック

Lambda は、MicroVM イメージ作成中にアプリケーションの正確性の検証とパフォーマンスの最適化を行うための MicroVM イメージビルドフックを提供します。フックは、各 MicroVM の初期化に使用されるスナップショットを Lambda が取得する前に実行されます。各フックは、アプリケーションによって公開され、Lambda がビルド中に呼び出す HTTP エンドポイントです。これらのリクエストに応答することで、MicroVM イメージビルドプロセスを制御および検証できます。Lambda は HTTP ステータスコードを使用して、フックが正常に完了したかどうかを判断します。

MicroVM イメージを更新する

update-microvm-image API を呼び出すことで、既存の MicroVM イメージを更新できます。更新のたびに新しい MicroVM イメージバージョンが作成されます。通常、次の目的で MicroVM イメージを更新します。

次の CLI コマンドは、MicroVM イメージを更新する方法を示します。--base-image-arn パラメータと --build-role-arn パラメータは、(コードアーティファクトのみを変更する場合でも) 新しいビルドをトリガーするすべての update-microvm-image 呼び出しで必要です。これらのパラメータを省略すると、結果は ValidationException になります。

aws lambda-microvms update-microvm-image \
  --image-identifier arn:aws:lambda:us-east-1:123456789012:microvm-image:my-microvm-image \
  --code-artifact uri=s3://my-bucket/deployments/app-v2.zip \
  --base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1 \
  --build-role-arn arn:aws:iam::123456789012:role/MicrovmBuildRole \
  --description "Updated with v2 application code"

イメージの状態とビルドの状態

MicroVM イメージを作成または更新するたびに、Lambda はコードアーティファクトとベースイメージから構築された新しいバージョンを作成します。MicroVM イメージは時間の経過とともに多くのバージョンを持つことがあり、特定のバージョンから MicroVM を実行します。

3 つの独立した状態は、ライフサイクルのさまざまな側面を追跡します。

バージョンから MicroVM を実行するには、イメージの状態が CREATED または UPDATED であること、バージョンの状態が SUCCESSFUL であること、およびバージョンが ACTIVE であることが必要です。

# De-activate a version
aws lambda-microvms update-microvm-image-version \
  --image-identifier my-image \
  --image-version 1.0 \
  --state INACTIVE

環境変数

環境変数は、environmentVariables フィールドを介して MicroVM イメージのビルド時に設定されます (最大 50 の変数)。これらは、スナップショットのビルドプロセス中にコンテナに挿入されます。新しい MicroVM を実行するとき、動的に設定されたペイロードを渡すことができます。詳細については、MicroVM の実行に関するセクションを参照してください。

MicroVM イメージにパッチを適用する

使用可能な新しい MicroVM ベースイメージがある場合、update-microvm-image コールを行って最新のパッチを含む MicroVM イメージビルドをトリガーできます。base-image-version 引数を省略するか (最新の場合)、最新バージョンで引数を指定します。

コンテナベースイメージ

Lambda MicroVMs は、アプリケーションを MicroVM オペレーティングシステム環境内のコンテナとして実行します。そのコンテナを Dockerfile で定義し、Dockerfile の FROM 命令でアプリケーションのコンテナベースイメージを設定します。

Amazon Linux 2023 (public.ecr.aws/lambda/microvms:al2023-minimal) の Lambda ベースコンテナイメージから開始して、その上にDockerfile 命令を追加するか、独自のベースコンテナイメージを使用することができます。独自のコンテナイメージを使用する場合は、次の要件を検証します。

要件

スナップショット互換のベースイメージ

Lambda MicroVMs は事前に初期化済みのスナップショットから各 MicroVM を起動するので、ベースイメージはスナップショット互換である必要があります。Lambda MicroVMs で独自のベースイメージを使用する場合は、「互換性に関する考慮事項」のセクションを参照することをお勧めします。

プライベート ECR イメージを使用する

FROM の Dockerfile 命令でプライベート ECR コンテナベースイメージを参照します。

FROM 123456789012.dkr.ecr.us-east-1.amazonaws.com/my-base:latest
WORKDIR /app
COPY . .
CMD ["./my-app"]

ビルドロールに次のアクセス許可を追加します。

{
  "Effect": "Allow",
  "Action": [
    "ecr:GetAuthorizationToken",
    "ecr:BatchCheckLayerAvailability",
    "ecr:GetDownloadUrlForLayer",
    "ecr:BatchGetImage"
  ],
  "Resource": "*"
}

オペレーティングシステムの機能

デフォルトでは、Lambda MicroVMs は Linux 機能の標準セットで実行されます。MicroVM イメージを作成または更新するときに、additionalOsCapabilities フィールドを使用して、昇格された Linux 機能を付与できます。["ALL"] はサポートされる唯一の値です。昇格された機能により、ファイルシステムのマウント、ネットワーク名前空間の作成、eBPF プログラムの実行などのオペレーションが可能になります。この機能は VM 分離境界内で適用されるので、ホストや他の MicroVM には影響しません。

aws lambda-microvms create-microvm-image \
  --name my-network-tool \
  --code-artifact uri=s3://my-bucket/app.zip \
  --base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1 \
  --build-role-arn arn:aws:iam::123456789012:role/BuildRole \
  --additional-os-capabilities '["ALL"]'