# MicroVM イメージ
<a name="microvms-images"></a>

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

MicroVM イメージは、MicroVM のファイルシステムとアプリケーション環境を定義するリソースです。MicroVM イメージには、ランタイム環境、アプリケーションコード、サポートプログラム (バックグラウンドプロセスやオブザーバビリティエージェントなど) が含まれます。MicroVM イメージを作成するには、`Dockerfile` とアプリケーションアーティファクトを含む zip パッケージを Amazon S3 にアップロードします。

`Dockerfile` は、アプリケーションをパッケージ化する方法を定義します。Lambda は、Lambda が管理する MicroVM ベースイメージによって提供されるオペレーティングシステム環境上で `Dockerfile` を実行して、アプリケーションコンテナイメージを構築します。MicroVM ベースイメージについては、以下の「[MicroVM ベースイメージ](#microvms-images-base-images)」セクションで説明します。

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

## Lambda が MicroVM イメージを構築する方法
<a name="microvms-images-creating"></a>

MicroVM イメージを作成すると、Lambda は次の処理を行います。
+ パッケージ化されたアーティファクトを Amazon S3 から取得します。
+ Lambda マネージドベースイメージから新しい MicroVM を起動します。
+ `Dockerfile` 内の命令を実行します
+ `ENTRYPOINT` 命令または `CMD` 命令を使用してアプリケーションを起動します。
+ 初期化が完了するまで待機します (ライフサイクルフックから通知されます)。
+ ディスクとメモリ状態のスナップショットをキャプチャします。

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

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

## MicroVM のサイズを設定する
<a name="microvms-images-sizing"></a>

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

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

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


| ベースライン | Peak | 最大ディスク容量 | 
| --- | --- | --- | 
| 0.5 GB のメモリ、0.25 vCPU | 2 GB のメモリ、1 vCPU | 8 GB | 
| 1 GB のメモリ、0.5 vCPU | 4 GB のメモリ、2 vCPU | 8 GB | 
| 2 GB のメモリ、1 vCPU (デフォルト) | 8 GB のメモリ、4 vCPU | 8 GB | 
| 4 GB のメモリ、2 vCPU | 16 GB のメモリ、8 vCPU | 16 GB | 
| 8 GB のメモリ、4 vCPU | 32 GB のメモリ、16 vCPU | 32 GB | 

## MicroVM ベースイメージ
<a name="microvms-images-base-images"></a>

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

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

ベースイメージのバージョンは廃止ライフサイクルに従います。
+ **`AVAILABLE`** – 最新、使用に推奨されます。
+ **`DEPRECATED`** (60 日) – 新しいバージョンが存在します。引き続きビルドして実行できます。
+ **`EXPIRING`** (30 日) – 新しいイメージは作成できません。既存のイメージは引き続き実行できます。
+ **`EXPIRED`** – ビルドおよび実行できません。サポートされているバージョンにイメージを再構築します。
+ **`RECALLED`** – 重大なセキュリティ上の問題が原因で直ちに使用できなくなります (まれに発生します)。

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

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

次の 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 イメージビルドフック
<a name="microvms-images-build-hooks"></a>

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

**重要**  
フックを設定する場合は、アプリケーションがフックリクエストをリッスンするポートを指定する必要があります。


| フック | パス | 詳細 | HTTP ステータスコード | タイムアウト | 
| --- | --- | --- | --- | --- | 
| /ready | /aws/lambda-microvms/runtime/v1/ready | MicroVM イメージビルド中、アプリケーションが ENTRYPOINT または CMD から起動された後に呼び出されます。アプリケーションのスナップショットを取得する準備が整ったことを通知します。 | HTTP 503: まだ準備ができていません。Lambda はタイムアウトまで再試行します。HTTP 200: 初期化が完了しました。Lambda はスナップショットを取得します。 | 1～3,600 秒 (readyTimeoutInSeconds) | 
| /validate | /aws/lambda-microvms/runtime/v1/validate | ビルドが完了した後、作成されたイメージから開始された新しい MicroVM で呼び出されます。再開時にアプリケーションが正しく動作することを確認します。 | HTTP 503: 検証の完了までさらに時間がかかります。Lambda はタイムアウトまで再試行します。HTTP 200: 検証に合格しました。 | 1～3,600 秒 (validateTimeoutInSeconds) | 

**重要**  
HTTP 503 返す場合、待機中にリクエストを開いたままにするのではなく、HTTP 503 を直ちに返します。リクエストが開いたままになっている間にタイムアウトが経過すると、Lambda はビルドを終了します。

**注記**  
/validate フックを使用して起動時間を最適化することもできます。そのためには、検証中にモックペイロードを実行します。これにより、Lambda はスナップショットのアクセス済みリージョンを追跡し、MicroVM の起動中に取得を最適化できます。

## MicroVM イメージを更新する
<a name="microvms-images-updating"></a>

`update-microvm-image` API を呼び出すことで、既存の MicroVM イメージを更新できます。更新のたびに新しい MicroVM イメージバージョンが作成されます。通常、次の目的で MicroVM イメージを更新します。
+ **新しいアプリケーションコードをデプロイする** – 新しいコードアーティファクト (Amazon S3 にアップロードされた新しい zip) をポイントして、アプリケーションの新しいバージョンを配信します。
+ **新しい MicroVM ベースイメージに移動する** – MicroVM ベースイメージ ARN を変更して、Lambda MicroVM ベースイメージの新しいバージョンにアップグレードします。詳細については、[MicroVM イメージにパッチを適用する](#microvms-images-patching) および [MicroVM ベースイメージ](#microvms-images-base-images) を参照してください。
+ **ビルドロールを変更する** – コードアーティファクトが別の Amazon S3 バケットに移動する場合やプライベート ECR リポジトリからのプルを開始する場合など、ビルド変更中に Lambda でアクセス許可が必要になるときにビルドロール ARN を更新します。
+ **ランタイム設定を調整する** – フック、環境変数、または機能を変更して、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"
```

## イメージの状態とビルドの状態
<a name="microvms-images-states"></a>

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

3 つの独立した状態は、ライフサイクルのさまざまな側面を追跡します。
+ **イメージの状態** – MicroVM イメージリソースのライフサイクル全体 (作成中、使用準備完了、更新中、失敗、または削除中)。
+ **バージョンの状態** – 特定のバージョンのビルドの進行状況 (保留中、ビルド中、成功、または失敗)。`stateReason` または CloudWatch ログ (`/aws/lambda-microvms/<image-name>`) で失敗の詳細を確認します。
+ **バージョンアクティベーション** – 正常に構築されたバージョンが MicroVM の実行を許可されているかどうか。Lambda は、新しいバージョンを自動的に `ACTIVE` に設定します。バージョンを `INACTIVE` に設定すると、削除せずに無効化できます。


| State | 使用できる値 | 遷移の制御 | 
| --- | --- | --- | 
| イメージの状態 | CREATING, CREATED, CREATION\_FAILED, UPDATING, UPDATED, UPDATE\_FAILED, DELETING, DELETED, DELETION\_FAILED | Lambda (自動) | 
| バージョンの状態 | PENDING, IN\_PROGRESS, SUCCESSFUL, FAILED | Lambda (自動) | 
| バージョンアクティベーション | ACTIVE, INACTIVE | ユーザー (update-microvm-image-version --state) | 

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

**注記**  
これらの状態はそれぞれ独立しています。`CREATED` 状態のイメージには、`FAILED` 状態のバージョンが含まれることがあります。

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

## 環境変数
<a name="microvms-images-env-vars"></a>

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

## MicroVM イメージにパッチを適用する
<a name="microvms-images-patching"></a>

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

## コンテナベースイメージ
<a name="microvms-images-container-base"></a>

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

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

### 要件
<a name="microvms-images-container-base-requirements"></a>
+ コンテナベースイメージは、ターゲット CPU アーキテクチャと互換性がある必要があります。
+ プライベート AWS ECR リポジトリのコンテナベースイメージには、ビルドロールに `ecr:GetAuthorizationToken` アクセス許可と `ecr:BatchGetImage` アクセス許可が必要です。
+ コンテナベースイメージは Linux オペレーティングシステムに基づく必要があります。
+ コンテナベースイメージは、Lambda ビルドインフラストラクチャ (パブリックインターネット、または同じ AWS アカウントの ECR リポジトリ) からアクセス可能である必要があります。
+ コンテナベースイメージはスナップショットと互換性がある必要があります。以下の説明を参照してください。

### スナップショット互換のベースイメージ
<a name="microvms-images-container-base-snapshot-compat"></a>

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

### プライベート ECR イメージを使用する
<a name="microvms-images-container-base-private"></a>

`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": "*"
}
```

## オペレーティングシステムの機能
<a name="microvms-images-os-capabilities"></a>

デフォルトでは、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"]'
```