翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Elastic Beanstalk Docker 環境の設定 この章では、ECS マネージド Docker プラットフォームブランチなど、サポートされているすべての Docker プラットフォームブランチのその他の設定情報について説明します。特定のプラットフォームブランチまたはプラットフォームブランチコンポーネントがセクションで特定されていない限り、サポートされている Docker および ECS 管理の Docker プラットフォームを実行しているすべての環境に適用されます。 **注記** Elastic Beanstalk 環境で (Amazon Linux 2 より前の) Amazon Linux AMI Docker プラットフォームバージョンを使用している場合は、「[(Amazon Linux 2 より前の) Amazon Linux AMI での Docker 設定](#docker-alami)」の追加情報を必ずお読みください。 **Topics** + [Docker 環境でのソフトウェアの設定](#docker-software-config) + [コンテナ内の環境変数の参照](#docker-env-cfg.env-variables) + [Docker Compose を使用した環境変数の補間機能の使用](#docker-env-cfg.env-variables-dc-interpolate) + [Docker Compose を使用した拡張ヘルスレポート用のログの生成](#docker-env-cfg.healthd-logging) + [Docker Compose を使用した Docker コンテナのカスタマイズされたログ記録](#docker-env-cfg.dc-customized-logging) + [Docker イメージ](#docker-images) + [Docker 環境に対する管理された更新の設定](#docker-managed-updates) + [Docker 設定の名前空間](#docker-namespaces) + [(Amazon Linux 2 より前の) Amazon Linux AMI での Docker 設定](#docker-alami) ## Docker 環境でのソフトウェアの設定 Elastic Beanstalk コンソールを使用して、お客様の環境のインスタンスで実行しているソフトウェアを設定できます。 **Elastic Beanstalk コンソールで Docker 環境を設定するには** 1. [Elastic Beanstalk コンソール](https://console.aws.amazon.com/elasticbeanstalk)を開き、**リージョン**リストで を選択します AWS リージョン。 1. ナビゲーションペインで、[**環境**] を選択し、リストから環境の名前を選択します。 1. ナビゲーションペインで、[**設定**] を選択します。 1. **[更新、モニタリング、ログ]** の設定カテゴリで、**[編集]** を選択します。 1. 必要な設定変更を行います。 1. ページの最下部で **[適用]** を選択し変更を保存します。 任意の環境でソフトウェア設定を定義する方法については、「[環境変数とその他のソフトウェアの設定](environments-cfg-softwaresettings.md)」を参照してください。以下のセクションでは、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 を使用した拡張ヘルスレポート用のログの生成](#docker-env-cfg.healthd-logging)」を参照してください。 ### 環境プロパティ (環境変数) [環境プロパティ] (環境変数とも呼ばれる) を使用して、エンドポイント、デバッグ設定、およびその他の情報などの値をアプリケーションに渡すことができます。コンソールの [**アプリケーション環境**] セクションでは、アプリケーションを実行している EC2 インスタンスの環境変数を指定できます。環境変数は、キーバリューのペアでアプリケーションに渡されます。 コンテナで実行されるアプリケーションコードは、名前で環境変数を参照し、その値を読み取ることができます。これらの環境変数を読み取るソースコードは、プログラミング言語によって異なります。Elastic Beanstalk マネージドプラットフォームがサポートするプログラミング言語での環境変数値を読み取る手順は、それぞれのプラットフォームのトピックで見つかります。これらのトピックへのリンクのリストについては、「[環境変数とその他のソフトウェアの設定](environments-cfg-softwaresettings.md)」を参照してください。 **Elastic Beanstalk 環境変数のシークレットとパラメータ** Elastic Beanstalk は、環境変数で AWS Secrets Manager および AWS Systems Manager Parameter Store データを参照する機能を提供します。これは、アプリケーションが API コールを管理することなく、これらのサービスに保存されているシークレットとパラメータにネイティブにアクセスする安全なオプションです。この機能をサポートするには、Elastic Beanstalk Docker および ECS マネージド Docker プラットフォームが [2025 年 3 月 26 日](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2025-03-26-windows.html)以降にリリースされたバージョンである必要があります。シークレットを参照するために環境変数を使用する方法の詳細については、「[Elastic Beanstalk 環境変数へのシークレットとパラメータのフェッチ](AWSHowTo.secrets.env-vars.md)」を参照してください。 **Docker Compose ありの環境** Docker Compose ありの Docker 環境を管理する場合、コンテナ内の環境変数を取得するための追加設定を行う必要があります。コンテナで実行されている実行可能ファイルがこれらの環境変数にアクセスするには、`docker-compose.yml` でそれらを参照する必要があります。詳細については、「[コンテナ内の環境変数の参照](#docker-env-cfg.env-variables)」を参照してください。 ## コンテナ内の環境変数の参照 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](https://docs.docker.com/compose/environment-variables/)」を参照してください ## Docker Compose を使用した環境変数の補間機能の使用 [2023 年 7 月 28 日](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2023-07-28-al2.html)のプラットフォームリリース以降、*Docker Amazon Linux 2* プラットフォームブランチには Docker Compose *補間*機能が提供されます。この機能により、Compose ファイルの値を変数で設定し、ランタイムに補間することができます。補間機能の詳細については、Docker ドキュメントウェブサイトの「[補間](https://docs.docker.com/compose/compose-file/12-interpolation/)」を参照してください。 **重要** この機能をアプリケーションで使用する場合は、プラットフォームフックを使用するアプローチを実装する必要があることに注意してください。 これが必要なのは、プラットフォームエンジンに実装した緩和策があるためです。この緩和策により、新しい補間機能を知らないお客様や、環境変数を `$` 文字を用いて利用している既存のアプリケーションに対しても、後方互換性を確保することができます。更新されたプラットフォームエンジンは、デフォルトで `$` 文字を `$$` 文字に置き換えることで補間をエスケープします。 次は、補間機能を使用できるように設定できるプラットフォームフックスクリプトの例です。 ``` #!/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 プラットフォームの拡張*」トピックにある [プラットフォームフック](platforms-linux-extend.hooks.md) を参照してください。 ## Docker Compose を使用した拡張ヘルスレポート用のログの生成 [Elastic Beanstalk ヘルスエージェント](health-enhanced.md#health-enhanced-agent)は、Elastic Beanstalk 環境のオペレーティングシステムとアプリケーションのヘルスメトリクスを提供します。これは、特定の形式で情報を中継するウェブサーバーのログ形式に依存します。 Elastic Beanstalk は、ウェブサーバープロキシをコンテナとして実行することを前提としています。その結果、Docker Composeを実行している Docker 環境では、NGINX ウェブサーバープロキシが無効になります。サーバーを構成して、Elastic Beanstalk ヘルスエージェントが使用する場所と形式でログを書き込む必要があります。これにより、ウェブサーバープロキシが無効になっていても、拡張ヘルスレポートを最大限に活用できます。 これを行う手順については、「[ウェブサーバーログ設定](health-enhanced-serverlogs.md#health-enhanced-serverlogs.configure)」を参照してください。 ## Docker Compose を使用した Docker コンテナのカスタマイズされたログ記録 問題を効率的にトラブルシューティングし、コンテナ化されたサービスをモニタリングするには、環境マネジメントコンソールまたは EB CLI を通じて Elastic Beanstalk から[インスタンスログをリクエスト](using-features.logging.md)します。インスタンスログは、バンドルログとテールログで構成され、組み合わされてパッケージ化されるため、ログと最近のイベントを効率的かつわかりやすい方法で表示できます。 Elastic Beanstalk は、コンテナインスタンス上の `docker-compose.yml` にログディレクトリを作成します (`/var/log/eb-docker/containers/` ファイルで定義されたサービスごとに1 つずつ)。Amazon Linux 2 Docker プラットフォームで Docker Compose 機能を使用している場合は、ログが書き込まれるコンテナファイル構造内の場所にこれらのディレクトリをマウントできます。ログデータを書き込むためのログディレクトリをマウントすると、Elastic Beanstalk はこれらのディレクトリからログデータを収集することができます。 **サービスのログファイルを取得可能なテールファイルとバンドルログとして設定するには** 1. `docker-compose.yml` ファイルを編集します。 1. サービスの `volumes` キーの下に、次のようにバインドマウントを追加します。 ` "${EB_LOG_BASE_DIR}/: ` 次のサンプル `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 の[リクエストインスタンスログ](using-features.logging.md)機能を通じてバンドルログおよびテールログとして取得できるようになりました。 **注意事項** *\$1\$1EB\$1LOG\$1BASE\$1DIR\$1* は、値 `/var/log/eb-docker/containers` を使用して Elastic Beanstalk により設定された環境変数です。 Elastic Beanstalk は、`/var/log/eb-docker/containers/` ファイル内の各サービスの `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 を使用したカスタムイメージの構築](single-container-docker-configuration.md#single-container-docker-configuration.dockerfile)」を参照してください。ECS マネージド Docker プラットフォームは、この機能をサポートしていません。 ## Docker 環境に対する管理された更新の設定 [管理されたプラットフォームの更新](environment-platform-update-managed.md)により、スケジュールに基づいて、環境を自動的に最新バージョンのプラットフォームに更新するように設定できます。 Docker 環境の場合、新しいプラットフォームバージョンに新しい Docker バージョンが含まれるときに、Docker バージョン間でプラットフォームの自動更新を実行するかどうか決定できます。2.9.0 以降の Docker プラットフォームバージョンを実行している環境から更新する場合、Elastic Beanstalk は、Docker バージョン間のマネージドプラットフォーム更新をサポートします。新しいプラットフォームバージョンに新しいバージョンの Docker が含まれている場合、Elastic Beanstalk はマイナーバージョン番号を増分します。したがって、Docker バージョン間で管理されたプラットフォームの更新を許可するには、マイナーおよびパッチバージョンの両方の更新について、管理されたプラットフォームの更新を有効にします。Docker バージョン間で管理されたプラットフォームの更新が行われないようにする場合は、パッチバージョンの更新のみを適用するように、管理されたプラットフォームの更新を有効にします。 たとえば、次の[設定ファイル](ebextensions.md)は、マイナーおよびパッチバージョンの両方の更新で、毎週火曜日の午前 9:00 UTC に管理されたプラットフォームの更新を有効にし、Docker バージョン間の管理された更新が行われるようにします。 **Example .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 設定の名前空間 [設定ファイル](ebextensions.md)を使用して、設定オプションを設定し、デプロイの間、他のインスタンス設定タスクを実行できます。設定オプションは、[プラットフォーム固有](command-options-specific.md)のものでも、Elastic Beanstalk サービス全体の[すべてのプラットフォーム](command-options-general.md)に適用できるものでもかまいません。設定オプションは、*名前空間*に整理されています。 **注記** この情報は、Docker Compose を実行していない Docker 環境にのみ適用されます。このオプションは、Docker Compose を実行する Docker 環境では動作が異なります。Docker Compose のあるプロキシサービスの詳細については、「[コンテナオプション](#docker-software-config.container)」を参照してください。 Docker プラットフォームでは、[すべての Elastic Beanstalk 環境でサポートされるオプション](command-options-general.md)に加えて、以下の名前空間でサポートされるオプションがあります。 + `aws:elasticbeanstalk:environment:proxy` – 環境のプロキシサーバーを選択します。Docker では、Nginx の実行ありまたはプロキシサーバーの実行なしがサポートされています。 以下の設定ファイルの例では、プロキシサーバーを実行しないように Docker 環境を設定しています。 **Example .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-configuration.remote-repo.md)している場合に該当します。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](command-options-general.md#command-options-general-autoscalinglaunchconfiguration) 名前空間の `BlockDeviceMapping` 設定オプションを使用してカスタマイズできます。 たとえば、次の[設定ファイル](ebextensions.md)は、ストレージボリュームサイズを 500 プロビジョンド IOPS を持つ 100 GB に増加します。 **Example .ebextensions/blockdevice-xvdcz.config** ``` option_settings: aws:autoscaling:launchconfiguration: BlockDeviceMappings: /dev/xvdcz=:100::io1:500 ``` アプリケーションの追加ボリュームの設定に `BlockDeviceMappings` オプションを使用する場合、確実に作成するために `xvdcz` のためのマッピングを含める必要があります。次の例では、デフォルト設定のイメージストレージボリューム `xvdcz` および追加の `sdh` という名前の 24 GB アプリケーションボリュームという 2 つのボリュームを設定しています。 **Example .ebextensions/blockdevice-sdh.config** ``` option_settings: aws:autoscaling:launchconfiguration: BlockDeviceMappings: /dev/xvdcz=:12:true:gp2,/dev/sdh=:24 ``` **注記** この名前空間の設定を変更する場合、Elastic Beanstalk は環境のすべてのインスタンスを新しい構成で実行しているインスタンスに置き換えます。詳細については、「[設定変更](environments-updating.md)」を参照してください。