翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Beanstalk クラスター環境のコンテナイメージの構築

Beanstalk クラスター環境は、コンテナイメージからアプリケーションを実行します。Beanstalk Standard と同様に、アプリケーションバージョンが環境にデプロイされます。Beanstalk クラスター環境では、アプリケーションバージョンは、Elastic Beanstalk がそのまま実行するイメージ、または Elastic Beanstalk がイメージに構築するソースを提供します。このトピックでは、作成パス、処理ステータス、および Beanstalk クラスター環境に固有の削除動作の両方の前提条件について説明します。デプロイ、タグ付け、バージョンクォータは、一般的な作成および削除手順と同様に、両方のモードで同じように機能します。「アプリケーションバージョンの管理」および「アプリケーションバージョンのタグ付け」を参照してください。

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 リージョンを使用します。「[開始する前に]」を参照してください。

以下のリソースとアクセスを準備します。

コンテナイメージ入力

既に構築され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 のビルドタイプとその設定については、「」を参照してください[ビルド設定]。

ビルドの実行中に、アプリケーションバージョンはステータス を報告しますBUILDING。PROCESSED イメージがビルドされてプッシュされると に移動し、ビルドが成功しない場合は FAILED に移動します。

[ビルド設定]

Build のメンバーはソースバンドルにImageConfiguration付属し、Elastic Beanstalk がイメージを構築する方法を制御します。次に説明するビルドタイプとともに、次のフィールドが格納されます。

Build メンバーは、 Typeフィールドから 2 つのビルドタイプのいずれかを選択します。これは必須です。

Architecture フィールドは、イメージのターゲット CPU アーキテクチャを amd64または に設定しますarm64。これを省略すると、Elastic Beanstalk は 用に構築されますamd64。環境archの設定と同じアーキテクチャ用に構築します。このアーキテクチャもデフォルトで になりますamd64。一方のアーキテクチャ用に構築されたイメージは、もう一方のアーキテクチャでは実行されません。arch の場合は、「Beanstalk クラスター環境の設定オプション」を参照してください。

処理ステータスを検査およびモニタリングする

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 クラスターの開始方法。

例

次の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 環境の設定。

アプリケーションバージョンを削除して復旧する

アプリケーションバージョンのライフサイクルポリシーは、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、修正されたバージョンを作成します。