環境昇格(dev→stg→prod) — インフラ変更をどう前に進めるか

「環境ごとにコードが違う」状態は、いずれprodだけ動かない事故を生みます。同じコードを差分だけ変えて前へ進める昇格の設計を、変数分離・状態分離・承認・ロールバックまで一気通貫で整理します。

「stgでは通ったのにprodだけ落ちる」。この事故のほとんどは、環境ごとにコードを分けて育ててしまった結果です。本稿では、同じコードをdev→stg→prodへ昇格(promote)させるという発想を軸に、変数の分離、状態(state)の分離、prod適用の承認、ロールバック、環境ドリフトの防止までを、実務の粒度で整理します。Terraform/OpenTofuを前提に書きますが、考え方はどのIaCでも同じです。

01昇格とは「同じコードを進める」こと

環境昇格の基本原則は一つです。環境間で変えてよいのは「値」だけで、「コード」は変えない。dev用のコードとprod用のコードが枝分かれした瞬間、stgでの検証はprodの保証になりません。理想は、devで動いたのと寸分違わぬコードを、変数だけ差し替えてstg、prodへ順に流していく形です。

HashiCorpのworkspace解説でも、環境をworkspaceで分ける狙いは「環境同士をできる限り似せたまま、同じコードで異なるstateを持つ」ことだと明記されています(Terraform: State Workspaces)。似せることそのものが目的、という視点が出発点です。

02差分は変数/tfvarsに追い出す

環境差は.tfvarsファイルに閉じ込めます。コード(.tf)は共通、値は環境ごとのファイルという分担です。

• terraform apply -var-file=envs/dev.tfvars のように、環境名のtfvarsを明示的に指定する。
• tfvarsに書くのは、インスタンスタイプ、Multi-AZの有無、スケール数、ログ保持日数、コスト系のフラグなど「環境で変わってよい値」だけ。
• 環境をまたいで同じであるべき値(命名規則、タグ規約、モジュールのバージョン)はtfvarsに置かず、コードやlocalsで固定する。

ここで効くのが変数のバリデーションです。variableブロックのvalidationで「prodではインスタンスタイプにt系を許さない」といった制約をコード側に持たせておくと、tfvarsの取り違えを適用前に弾けます。値を外に出しつつ、危険な値の範囲はコードで守る、という二段構えです。

02状態(state)の分離 — workspace vs ディレクトリ

コードを共通化しても、stateは環境ごとに完全に分けます。ここで方式選択が発生します。

• CLI workspace方式：1つの作業ディレクトリの中に複数のstateを持ち、terraform workspace select prodで切り替える。コードの重複はゼロ。
• ディレクトリ分割方式：envs/dev/ envs/prod/ のように環境ごとにディレクトリ(とbackend)を分ける。

選択の決め手は認証情報とアクセス制御を分けたいかです。HashiCorpの公式ドキュメントは、CLI workspaceについて「システム分解や、個別の認証情報・アクセス制御を要する構成には適さない(Workspaces are not appropriate for system decomposition or deployments requiring separate credentials and access controls.)」と明言しています(Terraform: State Workspaces)。理由は、CLI workspace群は同一backendを共有するため、prodとdevで別々のクレデンシャルやアクセス境界を張れないからです。