AWS Elastic Beanstalk
開発者ガイド

Docker 環境の設定

Elastic Beanstalk コンソールを使用して、環境の EC2 インスタンスで実行しているソフトウェアを設定することができます。

Elastic Beanstalk 環境のソフトウェア設定にアクセスするには

  1. Elastic Beanstalk コンソール を開きます。

  2. お客様の環境の管理ページに移動します。

  3. [Configuration] を選択します。

  4. [ソフトウェア] 設定カテゴリで、[変更] を選択します。

[Log Options (ログオプション)] セクションには、2 つの設定があります。

  • インスタンスプロファイル – 環境のインスタンスプロファイル。ログをアップロードするためには、環境の Amazon S3 ストレージバケットへの書き込みアクセスを持っていなければなりません。

  • Amazon S3 へのログファイルのローテーションを有効にする – 環境内のインスタンスを、ローテーションされたログをアップロードするように設定します。

環境プロパティ セクションで、アプリケーションコードから読み取ることができる環境変数を指定できます。

Docker イメージ

Elastic Beanstalk の単一コンテナとマルチコンテナ Docker のプラットフォームは、オンラインイメージのパブリックやプライベートリポジトリに格納した Docker イメージの使用をサポートします。

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

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

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

  • 他のオンラインリポジトリのイメージは、さらにドメイン名で修飾されます (例: quay.io/assemblyline/ubuntu または account-id.dkr.ecr.us-east-2.amazonaws.com/ubuntu:trusty)。

単一コンテナ環境においてのみ、Dockerfile で環境を作成する際に独自のイメージを構築できます。詳細については、「Dockerfile を使用したカスタムイメージの構築」を参照してください。

Amazon ECR リポジトリからのイメージを使用する

Amazon Elastic Container Registry (Amazon ECR) を使用して、AWS にカスタム Docker イメージを保存できます。Amazon ECR に Docker イメージを保存すると、Elastic Beanstalk は環境のインスタンスプロファイルを使用して自動的に Amazon ECR レジストリを認証するため、認証ファイルを生成して、Amazon Simple Storage Service (Amazon S3) にアップロードする必要がありません。

ただし、環境のインスタンスプロファイルにアクセス権限を付与することによって、Amazon ECR リポジトリのイメージにアクセスする権限をインスタンスに付与する必要があります。AmazonEC2ContainerRegistryReadOnly 管理ポリシーをインスタンスプロファイルにアタッチして、アカウントのすべての Amazon ECR リポジトリに対する読み取り専用アクセスを付与するか、以下のテンプレートを使用してカスタムポリシーを作成し、単一のリポジトリに対するアクセスを付与できます。

{ "Version": "2008-10-17", "Statement": [ { "Sid": "AllowEbAuth", "Effect": "Allow", "Action": [ "ecr:GetAuthorizationToken" ], "Resource": [ "*" ] }, { "Sid": "AllowPull", "Effect": "Allow", "Resource": [ "arn:aws:ecr:us-east-2:account-id:repository/repository-name" ], "Action": [ "ecr:GetAuthorizationToken", "ecr:BatchCheckLayerAvailability", "ecr:GetDownloadUrlForLayer", "ecr:GetRepositoryPolicy", "ecr:DescribeRepositories", "ecr:ListImages", "ecr:BatchGetImage" ] } ] }

上記のポリシーの Amazon リソースネーム(ARN)をリポジトリの ARN に置き換えます。

Dockerrun.aws.json ファイルで、その URL でイメージを参照します。単一コンテナプラットフォームについては、URL が Image 定義に入ります。

"Image": { "Name": "account-id.dkr.ecr.us-east-2.amazonaws.com/repository-name:latest", "Update": "true" },

マルチコンテナプラットフォームについては、コンテナ定義オブジェクトで image キーを使用します。

"containerDefinitions": [ { "name": "my-image", "image": "account-id.dkr.ecr.us-east-2.amazonaws.com/repository-name:latest",

プライベートリポジトリからイメージを使用する

オンラインレジストリによってホストされているプライベートリポジトリの Docker イメージを使用するには、レジストリでの認証に必要な情報が含まれている認証ファイルを提供する必要があります。

docker login コマンドを使用して認証ファイルを生成します。Docker Hub のリポジトリでは、docker login を実行します。

$ docker login

他のレジストリでは、レジストリサーバーの URL を入力します。

$ docker login registry-server-url

重要

Docker バージョン 1.7 から、docker login コマンドによって作成される認証ファイルの名前と形式が変更されました。Elastic Beanstalk は古い ~/.dockercfg 形式の設定ファイルを必要とします。

Docker バージョン 1.7 以降では、docker login コマンドによって ~/.docker/config.json に以下の形式の認証ファイルが作成されます。

{ "auths":{ "server":{ "auth":"key" } } }

Docker バージョン 1.6.2 以前では、docker login コマンドは ~/.dockercfg に以下の形式の認証ファイルを作成します。

{ "server" : { "auth" : "auth_token", "email" : "email" } }

config.json ファイルを変換するには、外側の auths キーを削除し、email キーを追加し、古い形式と一致するように JSON ドキュメントをフラット化します。

セキュアな Amazon S3 バケットに、認証ファイルの .dockercfg という名前のコピーをアップロードします。Amazon S3 バケットは、バケットを使用している環境と同じリージョンでホストする必要があります。Elastic Beanstalk は、他のリージョンでホストされている Amazon S3 バケットからファイルをダウンロードすることはできません。インスタンスプロファイル内の IAM ロールに s3:GetObject オペレーションを許可します。詳細については、「Elastic Beanstalk インスタンスプロファイルを管理する」を参照してください。

Amazon S3 バケット情報を Dockerrun.aws.json ファイルの Authentication (v1) または authentication (v2) に含めます。

単一コンテナ環境における Dockerrun.aws.json 形式の詳細については、単一コンテナの Docker の設定を参照してください。マルチコンテナ環境については、複数コンテナの Docker 設定を参照してください。

認証ファイルの詳細については、Docker ウェブサイトのDocker ハブにイメージを保存するおよびdocker ログインを参照してください.

追加ストレージボリュームの設定

パフォーマンスを向上させるため、Elastic Beanstalk は 2 つの Amazon EBS ストレージボリュームを Docker 環境の EC2 インスタンスに設定します。すべての Elastic Beanstalk 環境用にプロビジョニングされたルートボリュームに加え、xvdcz という名前の 2 つ目の 12GB ボリュームが、Docker 環境のイメージ保管用にプロビジョニングされます。

Docker イメージ用にさらなるストレージスペースや IOPS が必要な場合は、イメージストレージボリュームを aws:autoscaling:launchconfiguration 名前空間の BlockDeviceMapping 設定オプションを使用してカスタマイズできます。

たとえば、次の設定ファイルは、ストレージボリュームサイズを 500 プロビジョンド IOPS を持つ 100 GB に増加します。

例 .ebextensions/blockdevice-xvdcz.config

option_settings: aws:autoscaling:launchconfiguration: BlockDeviceMappings: /dev/xvdcz=:100::io1:500

アプリケーションの追加ボリュームの設定に BlockDeviceMappings オプションを使用する場合、確実に作成するために xvdcz のためのマッピングを含める必要があります。次の例では、デフォルト設定のイメージストレージボリューム xvdcz および追加の sdh という名前の 24 GB アプリケーションボリュームという 2 つのボリュームを設定しています。

例 .ebextensions/blockdevice-sdh.config

option_settings: aws:autoscaling:launchconfiguration: BlockDeviceMappings: /dev/xvdcz=:12:true:gp2,/dev/sdh=:24

この名前空間の設定を変更する場合、Elastic Beanstalk は環境のすべてのインスタンスを新しい構成で実行しているインスタンスに置き換えます。詳細については、「設定変更」を参照してください。

Docker ストレージ領域の再利用

Docker は、ファイルが作成され、実行中のコンテナ内で削除されたときに使用された領域をクリーンアップ (削除) しません。領域は、コンテナが削除されるとプールに返されるのみです。これにより、定期的にデータベースバックアップをダンプするなど、コンテナプロセスが多くのファイルを作成および削除する場合に、アプリケーションのストレージ領域がいっぱいになる問題が発生します。

1 つのソリューションは、前のセクションで説明したように、アプリケーションストレージ容量のサイズを増やすことです。他のオプションはパフォーマンスが落ちます。fstrim を使用するなど、コンテナの空き容量に対してホスト OS で定期的に cron を実行し、未使用コンテナのデータブロックを再利用します。

docker ps -q | xargs docker inspect --format='{{ .State.Pid }}' | xargs -IZ sudo fstrim /proc/Z/root/

Docker 環境に対する管理された更新の設定

管理されたプラットフォームの更新により、スケジュールに基づいて、環境を自動的に最新バージョンのプラットフォームに更新するように設定できます。

Docker 環境の場合、Docker バージョン間で — 新しいプラットフォームのバージョンに新しい Docker バージョンが含まれるときに、プラットフォームの自動更新を実行するかどうかを決定できます。Elastic Beanstalk は、2.9.0 より新しい Docker プラットフォームバージョンを実行する環境から更新するときに、Docker バージョン間での管理されたプラットフォームの更新をサポートします。新しいプラットフォームバージョンに新しいバージョンの Docker が含まれている場合、Elastic Beanstalk はマイナーバージョン番号を増分します。したがって、Docker バージョン間で管理されたプラットフォームの更新を許可するには、マイナーおよびパッチバージョンの両方の更新について、管理されたプラットフォームの更新を有効にします。Docker バージョン間で管理されたプラットフォームの更新が行われないようにする場合は、パッチバージョンの更新のみを適用するように、管理されたプラットフォームの更新を有効にします。

たとえば、次の設定ファイルは、マイナーおよびパッチバージョンの両方の更新で、毎週火曜日の午前 9:00 UTC に管理されたプラットフォームの更新を有効にし、Docker バージョン間の管理された更新が行われるようにします。

例 .ebextensions/managed-platform-update.config

option_settings: aws:elasticbeanstalk:managedactions: ManagedActionsEnabled: true PreferredStartTime: "Tue:09:00" aws:elasticbeanstalk:managedactions:platformupdate: UpdateLevel: minor

Docker バージョン 2.9.0 以前を実行している環境では、新しいプラットフォームバージョンに新しい Docker バージョンが含まれている場合、Elastic Beanstalk が管理されたプラットフォームの更新を実行することはありません。