本番環境で稼働するサービスの .env
に破壊的変更を加えるケースはあまりないと思うが、下記の場合どのような挙動になるのか気になって調べた。
想定するケース
- .envを利用し環境変数を読み込むRailsアプリケーションを想定する。
- ECSタスク定義のenvironmentFilesオプションを利用し、S3のバケットに
.env
ファイルを配置する。
- ECSタスク定義のenvironmentFilesオプションを利用し、S3のバケットに
- S3バケット内の
.env
ファイル内の環境変数に破壊的変更を加える。 - 新しい環境変数に対応したアプリケーションのタスク定義をデプロイする前に、古いタスク定義のままコンテナ(タスク)を起動する。
- 具体的には、変更を加えている最中にオートスケールした場合を想定した。
結論
.envに加えた変更は、新しいタスク定義を作成したタイミングで読み込まれる。 このため古いタスク定義のままコンテナ(タスク)を起動しても挙動は変わらない。
Amazon ECS タスクに環境変数を渡す際の問題をトラブルシューティングするにはどうすればよいですか?|環境変数が自動的に更新されない
調査前に予想した挙動
- 起動中のコンテナが停止する。
- 古いタスク定義を元に、コンテナ(タスク)が起動する。
- 起動時に破壊的変更が加えられた
.env
ファイルを読み込む。 - Railsのエラーが発生してコンテナ(タスク)が停止する。
- コンテナ(タスク)の起動と失敗を繰り返す。
- コンテナを1つだけデプロイする設定にしていた場合、ECSコンテナ上にデプロイしているアプリケーションが完全に停止する。
実際の挙動
- 起動中のコンテナが停止する。
- 古いタスク定義を元に、コンテナ(タスク)が起動する。
.env
ファイルは、タスク定義を更新した際に読み込まれる。- ECSコンテナ上にデプロイしているアプリケーションの挙動は、
.env
ファイルに破壊的変更を加える前と変わらない。
S3に配置した .env
ファイル内の環境変数が読み込まれるタイミングについてよく理解していなかったが、調べて理解が深まった。