ECSで動くアプリケーションは、環境変数とシークレットを必ず持つ。 その値を誰が変え、変えた値がいつ反映されるのかを決めておかないと、設定値を1つ変えるたびにインフラ担当への依頼が発生するか、機密値がインフラの管理情報に紛れ込む。
本稿では、ECSのタスク定義とTerraformの性質から、設定値を3つの系統に分けて管理する考え方を整理する。
1. タスク定義の値の指定方式は2つある
ECSでは、コンテナの環境変数はタスク定義に含まれる。タスク定義を変えるには、新しいリビジョンを作る。 値の指定方式には次の2つがある。
参照指定の値は、コンテナの起動時に注入される。値を更新しても、動いているコンテナには自動で反映されない。 反映するには、新しいタスクを起動するか、サービスを強制的に新規デプロイする必要がある。
したがって参照指定の利点は「値を変えても再デプロイが要らない」ことではない。 値を変えるたびにタスク定義のリビジョンを増やさずに済むことである。
2. Terraformで値を管理するときの注意
インフラ管理にTerraformを使う場合、もう一つの性質が加わる。
設定に直接書いた秘密値は、Terraformのstateとplanファイルに保存される。
変数を sensitive に指定するとCLIの表示では伏せられるが、保存そのものは防げない。
APIキーやパスワードの実値をTerraformで管理すると、stateやplanファイルを参照できる人と経路がすべて機密値へ到達できることになる。
一方、Terraformには「リソースは作るが、特定の属性の変更は追わない」という指定がある（lifecycle の ignore_changes）。
これを使うと、入れ物だけをTerraformで作り、値の変更はTerraformの外に置くことができる。
3. 3系統の分類
1章と2章の性質を組み合わせると、設定値は次の3系統に分けられる。
運用設定値と機密値の保管先には、当社ではSecrets Managerを使っている。 キーと値の組をコンソールで確認・編集できるため、運用担当がブラウザから扱いやすいことを理由にした判断である。
4. 責務分離の成立
3系統に分けると、次の責任分担が成り立つ。
- 運用担当は、インフラ管理の変更を待たずに設定値とシークレットを更新できる。
- 機密値の実値はTerraformのstateとplanに入らない。
- 値の反映はデプロイ（新しいタスクの起動）で行う、という1つの規則にそろう。「値を変えたのに反映されない」という状況を、仕組みとして説明できる。
この分け方はデプロイの方式に依存しない。Blue/Greenでもローリング更新でも同じ考え方を使える。 デプロイ方式の選び方はECS Blue/Greenデプロイの2つの方式で扱う。
5. まとめ
設定値の管理で決めるべきことは、どこに保存するかよりも、誰が変え、いつ反映されるかである。 3系統に分けると、その答えが値の種類ごとに1つに定まる。