翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Beanstalk クラスター環境のコンテナイメージの構築
Beanstalk クラスター環境は、コンテナイメージからアプリケーションを実行します。Beanstalk Standard と同様に、*アプリケーションバージョン*が環境にデプロイされます。Beanstalk クラスター環境では、アプリケーションバージョンは、Elastic Beanstalk がそのまま実行するイメージ、または Elastic Beanstalk がイメージに構築するソースを提供します。このトピックでは、作成パス、処理ステータス、および Beanstalk クラスター環境に固有の削除動作の両方の前提条件について説明します。デプロイ、タグ付け、バージョンクォータは、一般的な作成および削除手順と同様に、両方のモードで同じように機能します。「[アプリケーションバージョンの管理](applications-versions.md)」および「[アプリケーションバージョンのタグ付け](applications-versions-tagging.md)」を参照してください。
Beanstalk クラスターのデプロイでは、2 つのメンバーのうちの 1 つだけ`ImageConfiguration`を保持する を使用してアプリケーションバージョンを作成します。 は、既に構築されているコンテナイメージ`Source`を識別し、Elastic Beanstalk がソースバンドルからイメージを構築する方法`Build`を指定します。Elastic Beanstalk は、 がメンバーの両方を提供するか、どちらも`ImageConfiguration`提供しない`CreateApplicationVersion`リクエスト、 `ImageConfiguration.Source` と の両方を提供するリクエスト`SourceBundle`、および Beanstalk Standard の s AWS CodeBuild アプリケーションバージョンを設定する `BuildConfiguration`パラメータ`ImageConfiguration`と組み合わせるリクエストを拒否します。以下のセクションでは、各パスについて説明します。
## 前提条件
このトピックの例では、 を使用します AWS CLI。コマンドを実行する前にインストールして設定します。 AWS CLI 設定でアカウントと AWS リージョンを使用します。「[[開始する前に]](beanstalk-cluster-getting-started.md#beanstalk-cluster-getting-started-prerequisites)」を参照してください。
以下のリソースとアクセスを準備します。
+ ソースビルドの場合、 が`CodeBuildServiceRole`必要とする `ImageConfiguration.Build`。これは、Elastic Beanstalk コンソールが として作成する環境の*イメージビルドロール*です`aws-elasticbeanstalk-eks-image-build-role`。信頼されたサービスとポリシー、およびロールの境界については、[指定したロール](beanstalk-cluster-permissions.md#beanstalk-cluster-permissions-customer-roles)「」および「」を参照してください[Beanstalk クラスターのアクセス許可](beanstalk-cluster-permissions.md)。
+ の場合`ImageConfiguration.Source`、既にレジストリにプッシュされているコンテナイメージ。環境で使用されるノードロールは、イメージをプルできる必要があります。「[指定したロール](beanstalk-cluster-permissions.md#beanstalk-cluster-permissions-customer-roles)」を参照してください。
+ ソースビルドの場合、`SourceBundle`、アプリケーションソースを含む Amazon S3 オブジェクト。の説明に従ってアーカイブを作成し[Elastic Beanstalk アプリケーションソースバンドルを作成する](applications-sourcebundle.md)、アカウントの Amazon S3 バケットにアップロードして、バケットとオブジェクトキーを `S3Bucket`および として渡します`S3Key`。ビルドを開始する`true`には `Process`に設定します。それ以外の場合、バージョンは のままです`UNPROCESSED`。
## コンテナイメージ入力
既に構築され`ImageConfiguration`、レジストリにプッシュされているコンテナイメージ`Source`のメンバーを に提供します。Elastic Beanstalk は、ビルドステップなしでイメージを実行します。`Source` には、イメージをポイント`Uri`する 1 つのフィールド があります。イメージは、Amazon Elastic Container Registry (Amazon ECR) 内、または認証されていないプルを許可する任意のレジストリ内に配置できます。プライベートイメージの場合は、Amazon ECR を使用します。環境のノードロールがそのイメージを認証します。提供されたイメージから作成されたアプリケーションバージョンはビルドを必要としないため、Elastic Beanstalk はそれを ステータスで記録`UNPROCESSED`し、Beanstalk クラスター環境にデプロイする準備が整います。
Elastic Beanstalk は、タグとダイジェストのどちらに名前を付けるかにかかわらず、指定したとおりに URI を記録します。Elastic Beanstalk が構築するイメージはダイジェストによって記録されます。
このシェイプは、別のパイプラインがイメージを構築する場合や、以前のアプリケーションバージョンによって生成されたイメージがデプロイされる場合に使用します。Elastic Beanstalk でイメージをビルドするには、次に示すように、ソースバンドルと`Build`メンバーを指定します。
## Elastic Beanstalk が構築するソースを提供する
Elastic Beanstalk `SourceBundle`がアプリケーションソースからコンテナイメージを構築する必要がある場合は、 を指定します。は、Amazon Simple Storage Service (Amazon S3) のソースアーカイブを `S3Bucket`と の 2 つのフィールドで`SourceBundle`識別します`S3Key`。ソースバンドルには、Elastic Beanstalk `ImageConfiguration`がソースをイメージに変換する方法を指定する `Build` メンバーを持つ も必要です。ビルドを開始するには、`CreateApplicationVersion`リクエスト`true`で を `Process`に設定します。 で AWS CLI、 を使用します`--process`。この設定を省略すると、ソースベースのアプリケーションバージョンは残り`UNPROCESSED`、ビルドは開始されません。処理が開始されると、Elastic Beanstalk はイメージを構築し、アカウントの Amazon Elastic Container Registry にプッシュします。Docker と buildpack のビルドタイプとその設定については、「」を参照してください[[ビルド設定]](#beanstalk-cluster-app-versions-buildconfig)。
**注記**
macOS で、ソースディレクトリ内`zip -X -r ../my-app.zip .`から を使用してソースアーカイブを作成します。Finder の **Compress** コマンドは`__MACOSX`メタデータエントリを追加し、buildpack ビルドは を使用してそれらのエントリの 1 つで失敗し`zip: not a valid zip file`、作成しなかったファイルに名前を付けます。
ビルドの実行中に、アプリケーションバージョンはステータス を報告します`BUILDING`。`PROCESSED` イメージがビルドされてプッシュされると に移動し、ビルドが成功しない場合は `FAILED` に移動します。
## [ビルド設定]
`Build` のメンバーはソースバンドルに`ImageConfiguration`付属し、Elastic Beanstalk がイメージを構築する方法を制御します。次に説明するビルドタイプとともに、次のフィールドが格納されます。
+ `CodeBuildServiceRole`、 AWS CodeBuild がアカウントでビルドを実行するために引き受ける IAM ロール。このフィールドはソースビルドに必要です。
+ `ComputeType`、ビルドコンピューティングのオプションサイズ: `BUILD_GENERAL1_SMALL`、`BUILD_GENERAL1_MEDIUM`、または `BUILD_GENERAL1_LARGE`。これを省略すると、Elastic Beanstalk は を使用します`BUILD_GENERAL1_MEDIUM`。
+ `TimeoutInMinutes`は、Elastic Beanstalk が終了していないビルドを停止するまでのオプション分数です。値は から `5`までです`480`。これを省略すると、Elastic Beanstalk は`60`分を使用します。
`Build` メンバーは、 `Type`フィールドから 2 つのビルドタイプのいずれかを選択します。これは必須です。
+ `docker`、Elastic Beanstalk はソースの Dockerfile からイメージを構築します。`DockerfileLocation` を Dockerfile のパスに設定します。これを省略すると、Elastic Beanstalk はソースのルート`Dockerfile`で を使用します。
+ `buildpack`、Elastic Beanstalk は Cloud Native Buildpacks を使用してイメージを構築します。ビルドで使用するビルダーイメージ`Buildpack`に設定します。たとえば、 `paketobuildpacks/builder-jammy-base`です。Elastic Beanstalk は値をビルドに逐語的に渡します。buildpack ビルドにはビルダーが必要です。Elastic Beanstalk では検出されず、ビルダーセットのない buildpack ビルドは失敗します。
`Architecture` フィールドは、イメージのターゲット CPU アーキテクチャを `amd64`または に設定します`arm64`。これを省略すると、Elastic Beanstalk は 用に構築されます`amd64`。環境`arch`の設定と同じアーキテクチャ用に構築します。このアーキテクチャもデフォルトで になります`amd64`。一方のアーキテクチャ用に構築されたイメージは、もう一方のアーキテクチャでは実行されません。`arch` の場合は、「[Beanstalk クラスター環境の設定オプション](command-options-general-eks.md)」を参照してください。
## 処理ステータスを検査およびモニタリングする
Elastic Beanstalk がイメージを構築`BUILDING`している間、ソースベースのバージョンがレポートされます。をレポートした後にのみデプロイします`PROCESSED`。ステータスが の場合、ビルドが成功せず、バージョンをデプロイできない`FAILED`ことを意味します。ステータスが の場合、`CreateApplicationVersion`リクエストが を省略した場合など、処理が開始されなかった`UNPROCESSED`ことを意味します`Process`。提供されたイメージから作成されたアプリケーションバージョンも をレポートしますが`UNPROCESSED`、そのイメージはビルドを必要としないため、デプロイする準備が整います。
アプリケーションバージョンの説明では、イメージの状態は と の 2 つのメンバーとしてレポート`ImageSource`されます`ImageBuildConfiguration`。ソースベースのバージョンの場合、 はビルド設定を`ImageBuildConfiguration`エコーし、バージョンが をレポートしている間`ImageSource`は存在しません`BUILDING`。ビルドが成功すると、 はビルドが生成およびプッシュしたイメージのダイジェストピン付き URI `ImageSource`を返します。
でソースベースのバージョンの処理ステータスを確認します`DescribeApplicationVersions`。`CreateApplicationVersion` リクエストの直前に記録されたタイムスタンプ`operation_start`に設定します。その後に続くイベントクエリはそれを使用して、ビルドにイベントをスコープします。
```
$ aws elasticbeanstalk describe-application-versions \
--application-name my-app \
--version-labels v1-build \
--query 'ApplicationVersions[0].Status' \
--output text
```
バージョンがターミナルステータスになるまで、このコマンドを繰り返します。 は、ビルドがまだ実行中である`BUILDING`ことを意味します。をレポートした後にのみバージョンをデプロイします`PROCESSED`。 `FAILED`または のステータスは、バージョンをデプロイできない`UNPROCESSED`ことを意味します。
ソースベースのバージョンの場合、`PROCESSED`ステータスとイメージビルド完了イベントにより、Elastic Beanstalk がイメージを構築して記録したことを確認します。特定のバージョンのイベントを取得して、ターミナル障害をまだ実行中のビルドと区別します。
```
$ aws elasticbeanstalk describe-events \
--application-name my-app \
--version-label v1-build \
--start-time "$operation_start" \
--max-items 20
```
バージョンが に達した場合は`FAILED`、 `--severity ERROR`を追加して失敗イベントを取得します。イベントは、ソースのダウンロード、ロールの引き受け、Amazon ECR 認証、イメージのビルドまたはプッシュの失敗などの失敗を区別します。
```
$ aws elasticbeanstalk describe-events \
--application-name my-app \
--version-label v1-build \
--severity ERROR \
--start-time "$operation_start" \
--max-items 20
```
イベントは、失敗したステージを識別します。ビルド自体が失敗した理由を確認するには、ソースベースのバージョン`BuildArn`が報告する を使用します。これにより、ビルドを実行した AWS CodeBuild の実行が識別されます。ビルドのステータスとそのログの場所を取得するには、次のコマンドに渡します。
```
$ aws codebuild batch-get-builds \
--ids {{build-arn}} \
--query 'builds[0].{status:buildStatus,logGroup:logs.groupName,logStream:logs.streamName}'
```
レスポンスには、Amazon CloudWatch コンソールでビルドのログストリーム`logs.deepLink`を開く も含まれます。
イベントによって識別されるソースの場所、ビルド設定、またはロール設定を修正します。新しいラベルで新しいアプリケーションバージョンを作成し、 を `Process`に設定して`true`、 にポーリングします`PROCESSED`。にバージョンをデプロイしないでください`FAILED`。処理が成功すると、イメージがアプリケーションバージョンで使用可能であることが証明されます。環境デプロイは検証されません。
## サンプルアプリケーション
Beanstalk クラスター環境を作成する場合、アプリケーションバージョンはオプションです。バージョンラベルなし (または空白) で `CreateEnvironment`が呼び出されると、Elastic Beanstalk はサンプルアプリケーションをデプロイして実行中の環境を提供します。Elastic Beanstalk はサンプルをビルド済みのコンテナイメージでバックアップするため、デプロイにビルドステップは必要ありません。サンプルアプリケーションをカスタマーアプリケーションとして選択または設定することはできません。バージョンラベルが指定されていない場合、Elastic Beanstalk はそれをデプロイします。アプリケーションをデプロイするには、このトピックの説明に従ってアプリケーションバージョンを作成し、そのバージョンラベルを に渡します`CreateEnvironment`。環境の作成については、「」を参照してください[Beanstalk クラスターの開始方法](beanstalk-cluster-getting-started.md)。
## 例
次の`CreateApplicationVersion`リクエストは、既存のコンテナイメージを提供します。Elastic Beanstalk は、ビルドなしでイメージをそのまま実行します。
```
aws elasticbeanstalk create-application-version \
--application-name my-app \
--version-label v1-image \
--image-configuration Source={Uri=111122223333.dkr.ecr.us-east-1.amazonaws.com/my-app:v1}
```
次のリクエストは、代わりに Amazon S3 のソースバンドルと、`arm64`アーキテクチャの Dockerfile からイメージを構築するビルド設定を提供します。このイメージを実行するには、環境`arch`のオプション`arm64`も に設定します。
```
operation_start=$(date -u +%Y-%m-%dT%H:%M:%SZ)
aws elasticbeanstalk create-application-version \
--application-name my-app \
--version-label v1-build \
--process \
--source-bundle S3Bucket=my-source-bucket,S3Key=my-app/v1.zip \
--image-configuration '{
"Build": {
"Type": "docker",
"DockerfileLocation": "Dockerfile",
"Architecture": "arm64",
"CodeBuildServiceRole": "arn:aws:iam::111122223333:role/my-build-role",
"ComputeType": "BUILD_GENERAL1_SMALL",
"TimeoutInMinutes": 30
}
}'
```
次のリクエストは、Dockerfile の代わりに Cloud Native Buildpacks を使用してイメージを構築します。ソースは Dockerfile を必要とせず、ビルダーはイメージのアセンブル方法を決定します。リクエストは を省略するため`Architecture`、Elastic Beanstalk は 用に構築されます`amd64`。
```
operation_start=$(date -u +%Y-%m-%dT%H:%M:%SZ)
aws elasticbeanstalk create-application-version \
--application-name my-app \
--version-label v1-buildpack \
--process \
--source-bundle S3Bucket=my-source-bucket,S3Key=my-app/v1.zip \
--image-configuration '{
"Build": {
"Type": "buildpack",
"Buildpack": "paketobuildpacks/builder-jammy-base",
"CodeBuildServiceRole": "arn:aws:iam::111122223333:role/my-build-role"
}
}'
```
ソースバンドルビルドが に達したら`PROCESSED`、これらのバージョンのいずれかを Beanstalk 標準アプリケーションバージョンと同様に`UpdateEnvironment`、バージョンラベルを `CreateEnvironment`または に渡して Beanstalk クラスター環境にデプロイします。それを実行する環境の設定については、「」を参照してください[Elastic Beanstalk 環境の設定](customize-containers.md)。
## アプリケーションバージョンを削除して復旧する
アプリケーションバージョンのライフサイクルポリシーは、Beanstalk クラスターアプリケーションバージョンを削除しません。アプリケーションバージョンレコードを削除するには`DeleteApplicationVersion`、 を使用します。Elastic Beanstalk は、バージョンが の間はリクエストを拒否します`BUILDING`。ターミナル処理ステータスを待ってから削除します。
Beanstalk クラスターアプリケーションバージョンの場合、 `DeleteSourceBundle`オプションは Amazon S3 からソースバンドルを削除しません。ソースオブジェクトの保持は個別に管理されます。
`DeleteApplicationVersion` は、Elastic Beanstalk アプリケーションバージョンレコードを削除します。を通じて提供されたイメージ`ImageConfiguration.Source`、ソースビルドによって生成されたイメージ、またはイメージを含む Amazon ECR リポジトリは削除されません。指定したイメージの保持を管理します。Elastic Beanstalk がソースビルド用の Amazon ECR リポジトリを作成すると、そのリポジトリにライフサイクルポリシーが適用されます。1 つのアプリケーションバージョンを削除しても、イメージやリポジトリの即時クリーンアップは実行されません。
`FAILED` 状態のソースベースのバージョンはデプロイできません。ソースまたはビルド設定を修正し、新しいバージョンラベル`CreateApplicationVersion`で を呼び出し、 を `Process`に設定します`true`。失敗したバージョンのラベルを再利用するには、 を離れてからバージョンレコードを削除し`BUILDING`、修正されたバージョンを作成します。