Docker 環境の設定 - AWS Elastic Beanstalk
Docker 環境でのソフトウェアの設定コンテナ内の環境変数の参照拡張ヘルスレポート用のログの生成 (Docker Compose)Docker コンテナのカスタマイズされたログ記録 (Docker Compose)Docker イメージDocker ストレージ領域の再利用Docker 環境に対する管理された更新の設定Docker 設定の名前空間(Amazon Linux 2 より前の) Amazon Linux AMI での Docker 設定

Docker 環境の設定

Elastic Beanstalk Docker 環境の動作を設定するには、いくつかの方法があります。

注記

Elastic Beanstalk 環境で (Amazon Linux 2 より前の) Amazon Linux AMI Docker プラットフォームバージョンを使用している場合は、「(Amazon Linux 2 より前の) Amazon Linux AMI での Docker 設定」の追加情報を必ずお読みください。

Docker 環境でのソフトウェアの設定

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

Elastic Beanstalk コンソールで Docker 環境を設定するには

  1. Elastic Beanstalk コンソールを開き、[Regions] (リージョン) リストで AWS リージョンを選択します。

  2. ナビゲーションペインで、[環境] を選択し、リストから環境の名前を選択します。

    注記

    環境が多数ある場合は、検索バーを使用して環境リストをフィルタリングします。

  3. ナビゲーションペインで、[設定] を選択します。

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

  5. 必要な設定変更を行います。

  6. ページの一番下の [Apply] (適用) を選択します。

任意の環境でソフトウェア設定を定義する方法については、「環境プロパティとその他のソフトウェアの設定」を参照してください。以下のセクションでは、Docker 固有の情報を取り上げます。

コンテナオプション

[コンテナオプション] セクションには、プラットフォーム固有のオプションがあります。Docker 環境では、環境に NGINX プロキシサーバーを含めるかどうかを選択できます。

Docker Compose ありの環境

Docker Compose ありの Docker 環境を管理する場合、Elastic Beanstalk はプロキシサーバーをコンテナとして実行すると想定します。したがって、プロキシサーバー設定のデフォルトは [なし] に設定され、Elastic Beanstalk は NGINX 設定を提供しません。

注記

プロキシサーバーとして NGINX を選択しても、Docker Compose ありの環境ではこの設定は無視されます。プロキシサーバーのデフォルト設定は [なし] のままです。

Docker Compose ありの Amazon Linux 2 プラットフォーム上の Docker では、NGINX ウェブサーバープロキシが無効になっているため、拡張ヘルスレポート用のログを生成するための手順に従う必要があります。詳細については、「」を参照してください拡張ヘルスレポート用のログの生成 (Docker Compose)

環境プロパティと環境変数

[Environment Properties (環境プロパティ)] セクションでは、アプリケーションを実行している Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの環境設定を指定できます。環境プロパティは、キーと値のペアでアプリケーションに渡されます。Docker 環境では、Elastic Beanstalk は環境プロパティを環境変数としてコンテナに渡します。

コンテナで実行されるアプリケーションコードは、名前で環境変数を参照し、その値を読み取ることができます。これらの環境変数を読み取るソースコードは、プログラミング言語によって異なります。Elastic Beanstalk マネージドプラットフォームがサポートするプログラミング言語での環境変数値を読み取る手順は、それぞれのプラットフォームのトピックで見つかります。これらのトピックへのリンクのリストについては、「環境プロパティとその他のソフトウェアの設定」を参照してください。

Docker Compose ありの環境

Docker Compose ありの Docker 環境を管理する場合、コンテナ内の環境変数を取得するための追加設定を行う必要があります。コンテナで実行されている実行可能ファイルがこれらの環境変数にアクセスするには、docker-compose.yml でそれらを参照する必要があります。詳細については、「コンテナ内の環境変数の参照」を参照してください。

コンテナ内の環境変数の参照

Amazon Linux 2 Docker プラットフォームで Docker Compose ツールを使用している場合、アプリケーションプロジェクトのルートディレクトリに .env と呼ばれる Docker Compose 環境ファイルが Elastic Beanstalk により生成されます。このファイルには、Elastic Beanstalk に設定した環境変数が保存されます。

注記

アプリケーションバンドルに .env ファイルを含めると、Elastic Beanstalk は .env ファイルを生成しません。

Elastic Beanstalk で定義した環境変数をコンテナで参照するには、これらの設定方法のいずれかまたは両方に従う必要があります。

  • Elastic Beanstalk によって生成された .env ファイルを、env_file ファイルの docker-compose.yml 設定オプションに追加します。

  • docker-compose.yml ファイルで環境変数を直接定義します。

次のファイルはその例を示しています。サンプル docker-compose.yml ファイルは、両方のアプローチを示しています。

  • 環境プロパティ DEBUG_LEVEL=1 および LOG_LEVEL=error を定義すると、Elastic Beanstalk によって次の .env ファイルが自動的に生成されます。

    DEBUG_LEVEL=1
LOG_LEVEL=error

  • この docker-compose.yml ファイルでは、env_file 設定オプションは .env ファイルを指し、DEBUG=1 ファイル内で環境変数 docker-compose.yml を直接定義します。

    services:
  web:
    build: .
    environment:
      - DEBUG=1
    env_file:
      - .env
メモ

  • 両方のファイルで同じ環境変数を設定した場合、docker-compose.yml ファイルで定義された変数の優先順位は、.env ファイルで定義された変数よりも高くなります。

  • 文字列にスペースが追加されないように、等号 (=) と変数に割り当てられた値の間にスペースを残さないように注意してください。

Docker Compose の環境変数について詳しくは、「Environment variables in Compose」を参照してください

拡張ヘルスレポート用のログの生成 (Docker Compose)

Elastic Beanstalk ヘルスエージェントは、Elastic Beanstalk 環境のオペレーティングシステムとアプリケーションのヘルスメトリクスを提供します。これは、特定の形式で情報を中継するウェブサーバーのログ形式に依存します。

Elastic Beanstalk は、ウェブサーバープロキシをコンテナとして実行することを前提としています。その結果、Docker Composeを実行している Docker 環境では、NGINX ウェブサーバープロキシが無効になります。サーバーを構成して、Elastic Beanstalk ヘルスエージェントが使用する場所と形式でログを書き込む必要があります。これにより、ウェブサーバープロキシが無効になっていても、拡張ヘルスレポートを最大限に活用できます。

これを行う手順については、「ウェブサーバーログ設定」を参照してください。

Docker コンテナのカスタマイズされたログ記録 (Docker Compose)

問題を効率的にトラブルシューティングし、コンテナ化されたサービスをモニタリングするには、環境マネジメントコンソールまたは EB CLI を通じて Elastic Beanstalk からインスタンスログをリクエストします。インスタンスログは、バンドルログとテールログで構成され、組み合わされてパッケージ化されるため、ログと最近のイベントを効率的かつわかりやすい方法で表示できます。

Elastic Beanstalk は、コンテナインスタンス上の docker-compose.yml にログディレクトリを作成します (/var/log/eb-docker/containers/<service name> ファイルで定義されたサービスごとに1 つずつ)。Amazon Linux 2 Docker プラットフォームで Docker Compose 機能を使用している場合は、ログが書き込まれるコンテナファイル構造内の場所にこれらのディレクトリをマウントできます。ログデータを書き込むためのログディレクトリをマウントすると、Elastic Beanstalk はこれらのディレクトリからログデータを収集することができます。

アプリケーションが Docker Compose を使用していない Docker プラットフォーム上にある場合、「Docker コンテナのカスタマイズされたログ記録 (Docker Compose)」で説明されている標準的な手順に従うことができます。

サービスのログファイルを取得可能なテールファイルとバンドルログとして設定するには

  1. docker-compose.yml ファイルを編集します。

  2. サービスの volumes キーの下に、次のようにバインドマウントを追加します。

    "${EB_LOG_BASE_DIR}/<service name>:<log directory inside container>

    次のサンプル docker-compose.yml ファイルで、以下の操作を行います。

    • nginx-proxy は <サービス名> です

    • /var/log/nginx は <コンテナ内のログディレクトリ> 

    services:
  nginx-proxy:
    image: "nginx"
    volumes:
      - "${EB_LOG_BASE_DIR}/nginx-proxy:/var/log/nginx"

  • var/log/nginx ディレクトリには、コンテナ内の nginx-proxy サービスのログが含まれており、ホスト上の /var/log/eb-docker/containers/nginx-proxy ディレクトリにマップされます。

  • このディレクトリ内のすべてのログが、Elastic Beanstalk のリクエストインスタンスログ機能を通じてバンドルログおよびテールログとして取得できるようになりました。

メモ

  • ${EB_LOG_BASE_DIR} は、値 /var/log/eb-docker/containers を使用して Elastic Beanstalk により設定された環境変数です。

  • Elastic Beanstalk は、/var/log/eb-docker/containers/<service name> ファイル内の各サービスの docker-compose.yml ディレクトリを自動的に作成します。

Docker イメージ

Elastic Beanstalk 用の Docker および ECS マネージドの Docker プラットフォームブランチでは、パブリック/プライベートのオンラインイメージリポジトリに保存された Docker イメージの使用がサポートされています。

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

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

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

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

Docker プラットフォームのみを使用する環境では、Dockerfile を使用して環境の作成中に独自のイメージを作成することもできます。詳細については、「Dockerfile を使用したカスタムイメージの構築」を参照してください。マルチコンテナ Docker プラットフォームでは、この機能はサポートされていません。

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": "2012-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 でイメージを参照します。Docker プラットフォームでは、Uこの URL を Image 定義に含めます:

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

マルチコンテナ Docker プラットフォームでは、コンテナの定義オブジェクトで 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
注記

Elastic Beanstalk 環境で (Amazon Linux 2 より前の) Amazon Linux AMI Docker プラットフォームバージョンを使用している場合は、「(Amazon Linux 2 より前の) Amazon Linux AMI での Docker 設定」の追加情報をお読みください。

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

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

Docker 環境の Dockerrun.aws.json 形式の詳細については、「Docker の設定」を参照してください。マルチコンテナ環境については、「ECS マネージド Docker の設定」を参照してください。

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

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 バージョン間でプラットフォームの自動更新を実行するかどうか決定できます。2.9.0 以降の Docker プラットフォームバージョンを実行している環境から更新する場合、Elastic Beanstalk は、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 がマネージドプラットフォームの更新を実行することはありません。

Docker 設定の名前空間

設定ファイルを使用して、設定オプションを設定し、デプロイの間、他のインスタンス設定タスクを実行できます。設定オプションは、Elastic Beanstalk サービスまたは使用できるプラットフォームで定義し、名前空間に整理できます。

注記

この情報は、Docker Compose を実行していない Docker 環境にのみ適用されます。このオプションは、Docker Compose を実行する Docker 環境では動作が異なります。Docker Compose のあるプロキシサービスの詳細については、「コンテナオプション」を参照してください。

Docker プラットフォームでは、すべての Elastic Beanstalk 環境でサポートされるオプションに加えて、以下の名前空間でサポートされるオプションがあります。

  • aws:elasticbeanstalk:environment:proxy – 環境のプロキシサーバーを選択します。Docker では、Nginx の実行ありまたはプロキシサーバーの実行なしがサポートされています。

以下の設定ファイルの例では、プロキシサーバーを実行しないように Docker 環境を設定しています。

例 .ebextensions/docker-settings.config
option_settings:
  aws:elasticbeanstalk:environment:proxy:
    ProxyServer: none

(Amazon Linux 2 より前の) Amazon Linux AMI での Docker 設定

Elastic Beanstalk Docker 環境で (Amazon Linux 2 より前の) Amazon Linux AMI プラットフォームバージョンを使用している場合は、このセクションの追加情報を読んでください。

この情報は、プライベートリポジトリからイメージを使用している場合に該当します。Docker のバージョン 1.7 以降で、docker login コマンドによって作成される認証ファイルの名前と形式が変更されました。(Amazon Linux 2 より前の) Amazon Linux AMI Docker プラットフォームバージョンには、古い ~/.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 Linux 2 Docker プラットフォームバージョンでは、Elastic Beanstalk によって新しい認証ファイル名と形式が使用されます。Amazon Linux 2 Docker プラットフォームバージョンを使用している場合は、docker login コマンドによって作成される認証ファイルを変換せずに使用できます。

Amazon Linux AMI のパフォーマンスを向上させるために、Elastic Beanstalk は、Docker 環境の Amazon EC2 インスタンス用に 2 つの Amazon EBS ストレージボリュームを設定します。すべての 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 は環境のすべてのインスタンスを新しい構成で実行しているインスタンスに置き換えます。詳細については、「設定変更」を参照してください。