Amazon ECS プラットフォームブランチの使用 - AWS Elastic Beanstalk

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

Amazon ECS プラットフォームブランチの使用

このトピックでは、Amazon Linux 2 上のAmazon ECS プラットフォームブランチとそれに置き換えられるプラットフォームブランチ AL1 上のマルチコンテナ Docker (ECS マネージド) の両方を取り上げます。特に明記されていない限り、このトピックのすべての情報は、両方のプラットフォームブランチに適用されます。

注記

2022 年 7 月 18 日、Elastic Beanstalk では Amazon Linux AMI (AL1) に基づくプラットフォームブランチのステータスがすべて廃止されます。

AL1 上のマルチコンテナ Docker からの移行

現在、廃止された AL1 上で動作するマルチコンテナ Docker プラットフォームブランチを使用している場合は、最新の AL2023 上で動作する ECS プラットフォームブランチに移行できます。最新のプラットフォームブランチでは、廃止されたプラットフォームブランチのすべての機能がサポートされています。ソースコードを変更する必要はありません。詳細については、「Amazon Linux 上で動作するマルチコンテナ Docker の Amazon Linux 2023 上の ECS への移行」を参照してください。

ECS マネージド Docker プラットフォーム

Elastic Beanstalk は、Amazon Elastic Container Service (Amazon ECS) を使用して、ECS マネージド Docker 環境へのコンテナのデプロイを調整します。Amazon ECS は、Docker コンテナを実行するインスタンスのクラスターを管理するためのツールを供給します。Elastic Beanstalk は、クラスター作成、タスクの定義と実行のような Amazon ECS のタスクを処理します。環境内のインスタンスはそれぞれ、Dockerrun.aws.json v2 ファイルで定義される同じセットのコンテナを実行します。Docker を最大限に活用するため、Elastic Beanstalk では、Amazon EC2 インスタンスが複数の Docker コンテナを並行して実行できる環境を作成することができます。

次の図は、Auto Scaling グループの各 Amazon EC2 インスタンスで実行される 3 つの Docker コンテナで設定された Elastic Beanstalk 環境の例を示しています。

注記

Elastic Beanstalk は、すべてのプラットフォームに対して、アプリケーションのデプロイと実行をカスタマイズするために使用できる拡張機能を提供します。Amazon Linux 2 上で動作する ECS プラットフォームブランチでは、これらの機能のインスタンスデプロイワークフローの実装が他のプラットフォームとは異なります。詳細については、「Amazon Linux 2 以降で動作する ECS のインスタンスデプロイのワークフロー」を参照してください。

Dockerrun.aws.json file

コンテナインスタンス (Elastic Beanstalk 環境で ECS マネージド Docker を実行する Amazon EC2 インスタンス) には、Dockerrun.aws.json という名前の設定ファイルが必要です。このファイルは Elastic Beanstalk に固有であり、単独で、またはソースバンドルでソースコードやコンテンツと組み合わせて使用して、Docker プラットフォーム上に環境を作成することができます。

注記

バージョン 1 の Dockerrun.aws.json 形式は、Amazon Linux AMI (Amazon Linux 2 より前のバージョン) で実行されている Elastic Beanstalk 環境に対して 1 つの Docker コンテナを起動するために使用されます。この環境は、64 ビット版 Amazon Linux 上で動作する Docker プラットホームブランチをベースにしており、2022 年 7 月 18 日に使用停止になる予定です。Dockerrun.aws.json v1 形式の詳細については、Docker プラットフォームの設定 - Docker Compose なし を参照してください。

Dockerrun.aws.json のバージョン 2 では、Amazon EC2 インスタンスごとに複数のコンテナのサポートが追加され、ECS マネージド Docker プラットフォームとの組み合わせでのみ使用できます。この形式は、以前のバージョンとは大きく異なります

更新された形式とサンプルファイルの詳細については、「Dockerrun.aws.json v2」を参照してください。

Docker イメージ

Elastic Beanstalk の ECS マネージド Docker プラットフォームでは、イメージを事前に作成し、パブリックまたはプライベートのオンラインイメージリポジトリに保存する必要があります。

注記

デプロイ時の Dockerfile を使用したカスタムイメージの構築は、Elastic Beanstalk 上の ECS マネージド Docker プラットフォームではサポートされていません。イメージを構築して、Elastic Beanstalk 環境を作成する前にオンラインレポジトリにデプロイします。

Dockerrun.aws.json v2 で、イメージを名前で指定します。次の規則があります。

  • Docker ハブの公式リポジトリのイメージでは、1 つの名前 (例: ubuntumongo) を使用します。

  • Docker ハブの他のリポジトリのイメージは、組織名で修飾されます (例: amazon/amazon-ecs-agent)。

  • 他のオンラインレジストリのイメージは、ドメイン名でさらに修飾されます(例: quay.io/assemblyline/ubuntu)。

プライベートレポジトリを認証するように Elastic Beanstalk を設定するには、Dockerrun.aws.json v2 ファイルに authentication パラメータを含めます。

コンテナインスタンスのロール

Elastic Beanstalk は、Docker コンテナ内で実行される Amazon ECS コンテナエージェントを含んだ Amazon ECS 最適化 AMI を使用します。エージェントは、Amazon ECS と通信してコンテナのデプロイを調整します。Amazon ECS と通信するためには、各 Amazon EC2 インスタンスには IAM に対応するアクセス権限が必要です。これらの許可は、Elastic Beanstalk コンソールで環境を作成すると、デフォルトのインスタンスプロファイルにアタッチされます。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "ECSAccess", "Effect": "Allow", "Action": [ "ecs:Poll", "ecs:StartTask", "ecs:StopTask", "ecs:DiscoverPollEndpoint", "ecs:StartTelemetrySession", "ecs:RegisterContainerInstance", "ecs:DeregisterContainerInstance", "ecs:DescribeContainerInstances", "ecs:Submit*" ], "Resource": "*" } ] }

独自のインスタンスプロファイルを作成する場合は、AWSElasticBeanstalkMulticontainerDocker 管理ポリシーをアタッチして、アクセス許可が最新であることを確認することができます。IAM でのポリシーとロールの作成手順については、IAM ユーザーガイドの「IAM ロールの作成」を参照してください。

Elastic Beanstalk によって作成された Amazon ECS リソース

ECS マネージド Docker プラットフォームを使用して環境を作成する場合、環境の構築中に Elastic Beanstalk によって自動的に複数の Amazon Elastic Container Service リソースが作成および設定されます。これにより、各 Amazon EC2 インスタンスに必要なコンテナが作成されます。

  • Amazon ECS クラスター – Amazon ECS のコンテナインスタンスはクラスターに整理されます。Elastic Beanstalk とともに使用すると、ECS マネージド Docker 環境ごとに必ず 1 つのクラスターが作成されます。

  • Amazon ECS タスク定義 – Elastic Beanstalk は、プロジェクト内の Dockerrun.aws.json v2 ファイルを使用して、環境内のコンテナインスタンスの設定に使用される Amazon ECS タスク定義を生成します。

  • Amazon ECS タスク – Elastic Beanstalk は Amazon ECS と通信して、環境の各インスタンスでタスクを実行し、コンテナのデプロイを調整します。スケーラブルな環境では、Elastic Beanstalk はインスタンスがクラスターに追加されるたびに新しいタスクを開始します。まれに、コンテナとイメージ用に予約した容量を増やす必要が生じることがあります。詳細については、「Docker 環境の設定」セクションを参照してください。

  • Amazon ECS コンテナエージェント – エージェントは環境のインスタンスの Docker コンテナで実行されます。エージェントは Amazon ECS サービスをポーリングし、タスクの実行を待ちます。

  • Amazon ECS データボリューム – Elastic Beanstalk はログ収集を容易にするため、(Dockerrun.aws.json v2 に定義するボリュームに加えて) ボリューム定義をタスク定義に挿入します。

    Elastic Beanstalk はコンテナインスタンスにログボリュームを作成します。コンテナごとに 1 つ、場所は /var/log/containers/containername です。これらのボリュームの名前は awseb-logs-containername で、マウントするコンテナごとに指定されます。このマウント方法の詳細については、「コンテナの定義形式」を参照してください。

複数の Elastic Load Balancing リスナーの使用

デフォルトの HTTP ポートで実行されないプロキシまたは他のサービス用の受信トラフィックをサポートするため、ECS マネージド Docker 環境で、複数の Elastic Load Balancing リスナーを設定できます。

ソースバンドルで .ebextensions フォルダを作成し、ファイル拡張子が .config のファイルを追加します。次の例では、ポート 8080 で Elastic Load Balancing リスナーを作成する設定ファイルを示します。

.ebextensions/elb-listener.config

option_settings: aws:elb:listener:8080: ListenerProtocol: HTTP InstanceProtocol: HTTP InstancePort: 8080

作成したカスタム Amazon Virtual Private Cloud (Amazon VPC) が環境で実行されている場合、残りはElastic Beanstalk が処理します。デフォルトの VPC では、インスタンスのセキュリティグループを設定して、ロードバランサーからの着信を許可する必要があります。進入ルールを追加する第 2 の設定ファイルをセキュリティグループに追加します。

.ebextensions/elb-ingress.config

Resources: port8080SecurityGroupIngress: Type: AWS::EC2::SecurityGroupIngress Properties: GroupId: {"Fn::GetAtt" : ["AWSEBSecurityGroup", "GroupId"]} IpProtocol: tcp ToPort: 8080 FromPort: 8080 SourceSecurityGroupName: { "Fn::GetAtt": ["AWSEBLoadBalancer", "SourceSecurityGroup.GroupName"] }

設定ファイルの形式の詳細については、「Elastic Beanstalk 環境リソースの追加とカスタマイズ」および「オプション設定」を参照してください。

Elastic Load Balancing 設定にリスナーを追加し、セキュリティグループでポートを開くことに加えて、Dockerrun.aws.json v2 ファイルの containerDefinitions セクションで、Docker コンテナのポートにホストインスタンスのポートをマッピングする必要があります。例を以下に示します。

"portMappings": [ { "hostPort": 8080, "containerPort": 8080 } ]

Dockerrun.aws.json v2 ファイル形式の詳細については、「Dockerrun.aws.json v2」を参照してください。

失敗したコンテナのデプロイ

Amazon ECS タスクが失敗した場合、Elastic Beanstalk 環境の 1 つ以上のコンテナが開始されません。Elastic Beanstalk は、Amazon ECS タスクが失敗したことで、マルチコンテナ環境をロールバックすることはありません。環境でコンテナの開始が失敗した場合は、Elastic Beanstalk コンソールから現在のバージョンまたは以前の機能するバージョンを再デプロイします。

既存のバージョンをデプロイするには
  1. 環境のリージョンで Elastic Beanstalk コンソールを開きます。

  2. アプリケーション名の右側の アクション をクリックし、アプリケーションバージョンの表示 をクリックします。

  3. アプリケーションのバージョンを選択し、デプロイ をクリックします。