メニュー
AWS Elastic Beanstalk
開発者ガイド (API Version 2010-12-01)

Docker 環境の設定

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

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

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

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

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

  4. [Software Configuration] セクションで、設定アイコン (  を編集します。 ) を選択します。

[Log Options] セクションには、2 つの設定があります。

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

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 EC2 コンテナレジストリ(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" : "auth_token",
      "email" : "email"
    }
  }
}

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

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

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

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

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

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

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

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

パフォーマンスを向上させるため、Elastic Beanstalk は 2 つの Amazon EBS ストレージボリュームを Docker 環境の EC2 インスタンスに設定します。すべての Elastic Beanstalk 環境用にプロビジョニングされたルートボリュームに加え、xvdcz という名前の 2 つ目の 12 GB ボリュームが、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 つのソリューションは、前のセクションで説明したように、アプリケーションストレージ容量のサイズを増やすことです。他のオプションはパフォーマンスが落ちます。cron を使用するなど、コンテナの空き容量に対してホスト OS で定期的に fstrim を実行し、未使用コンテナのデータブロックを再利用します。

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