翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Elastic Beanstalk Docker 環境の設定
この章では、ECSマネージド Docker プラットフォームブランチを含む、サポートされているすべての Docker プラットフォームブランチに関する追加の設定情報について説明します。特定のプラットフォームブランチまたはプラットフォームブランチコンポーネントがセクションで特定されていない限り、サポートされている Docker プラットフォームとECS管理された Docker プラットフォームを実行しているすべての環境に適用されます。
注記
Elastic Beanstalk 環境で Amazon Linux Docker AMI プラットフォームバージョン (Amazon Linux 2 より前) を使用している場合は、「」の追加情報を必ずお読みくださいAmazon Linux での Docker 設定 AMI (Amazon Linux 2 より前)。
セクション
Docker 環境でのソフトウェアの設定
Elastic Beanstalk コンソールを使用して、お客様の環境のインスタンスで実行しているソフトウェアを設定できます。
Elastic Beanstalk コンソールで Docker 環境を設定するには
Elastic Beanstalk コンソール
を開き、リージョンリストで を選択します。 AWS リージョン. -
ナビゲーションペインで、[環境] を選択し、リストから環境の名前を選択します。
注記
環境が多数ある場合は、検索バーを使用して環境リストをフィルタリングします。
ナビゲーションペインで、[設定] を選択します。
-
[更新、モニタリング、ログ] の設定カテゴリで、[編集] を選択します。
-
必要な設定変更を行います。
-
ページの最下部で [適用] を選択し変更を保存します。
任意の環境でソフトウェア設定を定義する方法については、「環境プロパティとその他のソフトウェアの設定」を参照してください。以下のセクションでは、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 を使用した拡張ヘルスレポートのログの生成」を参照してください。
環境プロパティと環境変数
環境プロパティセクションでは、アプリケーションを実行している 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 での環境変数の補間機能の使用
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}"
プラットフォームフックを次の両方のディレクトリに配置します。
-
.platform/confighooks/predeploy/
-
.platform/hooks/predeploy/
詳細については、このガイドの「Linux プラットフォームの拡張」トピックにある プラットフォームフック を参照してください。
Docker Compose を使用した拡張ヘルスレポートのログの生成
Elastic Beanstalk ヘルスエージェントは、Elastic Beanstalk 環境のオペレーティングシステムとアプリケーションのヘルスメトリクスを提供します。これは、特定の形式で情報を中継するウェブサーバーのログ形式に依存します。
Elastic Beanstalk は、ウェブサーバープロキシをコンテナとして実行することを前提としています。その結果、Docker Compose を実行している Docker 環境ではNGINXウェブサーバープロキシが無効になります。サーバーを構成して、Elastic Beanstalk ヘルスエージェントが使用する場所と形式でログを書き込む必要があります。これにより、ウェブサーバープロキシが無効になっていても、拡張ヘルスレポートを最大限に活用できます。
これを行う手順については、「ウェブサーバーログ設定」を参照してください。
Docker Compose を使用した Docker コンテナのカスタマイズされたログ記録
問題を効率的にトラブルシューティングし、コンテナ化されたサービスをモニタリングするために、環境マネジメントコンソールまたは EB を使用して Elastic Beanstalk からインスタンスログをリクエストできますCLI。インスタンスログは、バンドルログとテールログで構成され、組み合わされてパッケージ化されるため、ログと最近のイベントを効率的かつわかりやすい方法で表示できます。
Elastic Beanstalk は、コンテナインスタンス上の docker-compose.yml
にログディレクトリを作成します (/var/log/eb-docker/containers/
ファイルで定義されたサービスごとに1 つずつ)。Amazon Linux 2 Docker プラットフォームで Docker Compose 機能を使用している場合は、ログが書き込まれるコンテナファイル構造内の場所にこれらのディレクトリをマウントできます。ログデータを書き込むためのログディレクトリをマウントすると、Elastic Beanstalk はこれらのディレクトリからログデータを収集することができます。<service
name>
アプリケーションが Docker Compose を使用していない Docker プラットフォーム上にある場合、「Docker Compose を使用した Docker コンテナのカスタマイズされたログ記録」で説明されている標準的な手順に従うことができます。
サービスのログファイルを取得可能なテールファイルとバンドルログとして設定するには
-
docker-compose.yml
ファイルを編集します。 -
サービスの
volumes
キーの下に、次のようにバインドマウントを追加します。"${EB_LOG_BASE_DIR}/
<service name>
:<log directory inside container>
次のサンプル
docker-compose.yml
ファイルで、以下の操作を行います。-
nginx-proxy
は<service name>
-
/var/log/nginx
は<log directory inside container>
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_LOGBASE_DIR} は、Elastic Beanstalk によって値 で設定された環境変数です
/var/log/eb-docker/containers
。 -
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 を使用したカスタムイメージの構築」を参照してください。ECS マネージド Docker プラットフォームプラットフォームは、この機能をサポートしていません。
Docker 環境に対する管理された更新の設定
管理されたプラットフォームの更新により、スケジュールに基づいて、環境を自動的に最新バージョンのプラットフォームに更新するように設定できます。
Docker 環境の場合、新しいプラットフォームバージョンに新しい Docker バージョンが含まれるときに、Docker バージョン間でプラットフォームの自動更新を実行するかどうか決定できます。2.9.0 以降の Docker プラットフォームバージョンを実行している環境から更新する場合、Elastic Beanstalk は、Docker バージョン間のマネージドプラットフォーム更新をサポートします。新しいプラットフォームバージョンに新しいバージョンの Docker が含まれている場合、Elastic Beanstalk はマイナーバージョン番号を増分します。したがって、Docker バージョン間で管理されたプラットフォームの更新を許可するには、マイナーおよびパッチバージョンの両方の更新について、管理されたプラットフォームの更新を有効にします。Docker バージョン間で管理されたプラットフォームの更新が行われないようにする場合は、パッチバージョンの更新のみを適用するように、管理されたプラットフォームの更新を有効にします。
例えば、次の設定ファイルでは、マイナーバージョンとパッチバージョンの両方の更新についてUTC、毎週火曜日の午前 9 時にマネージドプラットフォームの更新を有効にし、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 での Docker 設定 AMI (Amazon Linux 2 より前)
Elastic Beanstalk Docker 環境で Amazon Linux AMIプラットフォームバージョン (Amazon Linux 2 より前) を使用している場合は、このセクションの追加情報をお読みください。
この情報は、プライベートリポジトリからイメージを使用している場合に該当します。Docker のバージョン 1.7 以降で、docker login コマンドによって作成される認証ファイルの名前と形式が変更されました。Amazon Linux AMI Docker プラットフォームバージョン (Amazon Linux 2 より前) には、古い~/.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
の設定オプションを使用してイメージストレージボリュームをカスタマイズできます。
例えば、次の設定ファイルでは、ストレージボリュームのサイズを 100 GB に増やし、プロビジョニングされた は 500 ですIOPS。
例 .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 は環境のすべてのインスタンスを新しい構成で実行しているインスタンスに置き換えます。詳細については、「設定変更」を参照してください。