Elastic Beanstalk Docker 環境の設定

この章では、ECS マネージド Docker プラットフォームブランチなど、サポートされているすべての Docker プラットフォームブランチのその他の設定情報について説明します。特定のプラットフォームブランチまたはプラットフォームブランチコンポーネントがセクションで特定されていない限り、サポートされている Docker および ECS 管理の Docker プラットフォームを実行しているすべての環境に適用されます。

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

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

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

コンテナオプション

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

Docker Compose ありの環境

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

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 に設定した環境変数が保存されます。

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

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

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

Docker Compose を使用した環境変数の補間機能の使用

2023 年 7 月 28 日のプラットフォームリリース以降、Docker Amazon Linux 2 プラットフォームブランチには Docker Compose 補間機能が提供されます。この機能により、Compose ファイルの値を変数で設定し、ランタイムに補間することができます。補間機能の詳細については、Docker ドキュメントウェブサイトの「補間」を参照してください。

次は、補間機能を使用できるように設定できるプラットフォームフックスクリプトの例です。

#!/bin/bash

: '
example data format in .env file
key1=value1
key2=value2
'
envfile="/var/app/staging/.env"
tempfile=$(mktemp)

while IFS= read -r line; do
  # split each env var string at '='
  split_str=(${line//=/ })
  if [ ${#split_str[@]} -eq 2 ]; then
    # replace '$$' with '$'
    replaced_str=${split_str[1]//\$\$/\$}
    # update the value of env var using ${replaced_str}
    line="${split_str[0]}=${replaced_str}"
  fi
  # append the updated env var to the tempfile
  echo "${line}" ≫"${tempfile}"
done < "${envfile}"
# replace the original .env file with the tempfile
mv "${tempfile}" "${envfile}"

プラットフォームフックを次の両方のディレクトリに配置します。

詳細については、このガイドの「Linux プラットフォームの拡張」トピックにある プラットフォームフック を参照してください。

Docker Compose を使用した拡張ヘルスレポート用のログの生成

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

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

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

Docker Compose を使用した Docker コンテナのカスタマイズされたログ記録

問題を効率的にトラブルシューティングし、コンテナ化されたサービスをモニタリングするには、環境マネジメントコンソールまたは 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 Compose を使用した Docker コンテナのカスタマイズされたログ記録」で説明されている標準的な手順に従うことができます。

Docker イメージ

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

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

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

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

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

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

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

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

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

option_settings:
  aws:elasticbeanstalk:environment:proxy:
    ProxyServer: none

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

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

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

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

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

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