IaC — インフラをコードで書いて自動構築する

宣言的IaCの心臓は、望む状態へ現実を寄せる調整（reconciliation）です。人は「どうあってほしいか」だけを書き、ツールが差を埋めます。

• plan — コード（望む状態）と現況の記録を突き合わせ、「何を作り・変え・消すか」の差分を先に見せる。適用前に影響を確認できる
• apply — その差分だけを実行し、実状態を望む状態へ寄せる。全部を作り直さない
• この「差分だけ動く」性質がべき等性の正体。既に望む状態なら何もせず、ずれていれば直すだけ

登場人物メモ:

• ※1 state（状態ファイル） — ツールが把握する「今の構成」の台帳。差分計算の基準
• ※2 ドリフト — コードを通さない手動変更で、コードと現実がずれること
• ※3 プロバイダ — 各サービスのAPIを、宣言的な操作へ翻訳するアダプタ

「差分だけ動く」には、今どうなっているかをツールが覚えている必要があります。それがstateです。

• stateは「このリソースは実在し、こういう設定のはず」という現況の台帳。planはコードとstateを比べて差分を出す
• ドリフト — 誰かが管理画面から手で設定を変えると、実体はstateと食い違う。ツールは「変えたはず」と思っていないので、次のplanで予期せぬ差分として現れる
• リフレッシュ／検出 — 実体を読み直してstateを最新化し、ドリフトを洗い出す。放置すると次のapplyが手動変更を意図せず上書きする

肝は、stateはコードではないこと。コードは「望む姿」、stateは「今の姿の記録」。この2つと実体の三者を突き合わせるのが差分適用の本質です。

なぜ同じIaCツールでクラウドもVPCもDNSも書けるのか。答えがプロバイダです。

• プロバイダは、各サービスのAPIを「作る・読む・更新する・消す」という共通の型へ翻訳するアダプタ
• ツール本体は差分計算に徹し、実際の操作はプロバイダに委ねる。だから新しいサービスもプロバイダを足すだけで扱える
• 各リソースには一意の識別子があり、プロバイダはそれを頼りに「作成」と「更新」を区別する。ここがぶれると同じ物を二重に作ってしまう

規模が大きくなると、部品化と作り直す発想が効いてきます。

• モジュール化 — VPC一式やサーバ群など、まとまった構成を再利用できる部品にする。同じ部品から開発用・本番用を差分パラメータだけ変えて量産できる
• 合成 — 小さなモジュールを組み合わせて大きな構成を作る。重複を減らし、変更を1か所に集約できる
• イミュータブルインフラ — 動いているサーバを手で直さず、新しい版を丸ごと作って古い版と入れ替える。Dockerイメージの差し替えと同じ発想で、ドリフトが起きにくく、戻すのも入れ替えるだけ

IaCで特有の罠が、stateに秘密が平文で残ることです。

• データベースのパスワードなどを構成に含めると、生成されたstateにその値が書き込まれる。stateを共有すると秘密も一緒に漏れる
• コードに直書きしない — 鍵やパスワードは専用の金庫に置き、IaCからは参照だけする
• stateを守る — 保管先を暗号化し、アクセスを絞る。stateはただの記録ではなく秘密を含みうる資産として扱う

さらにCI/CDと組み合わせれば、構成変更もplanをレビューしてから自動適用でき、アプリと同じ流れ作業にインフラを乗せられます。

• 手動変更によるドリフト — 画面で直すとstateと食い違い、次のapplyで意図せず上書きされる
• stateの破損・取り違え — 現況の台帳が壊れると差分計算を誤り、実在する物を作り直したり二重化する
• 削除の巻き添え — 宣言から外した資源が消える。planで消える対象を必ず確認する
• 秘密のstate流出 — 平文の秘密を含んだstateを不用意に共有・コミットして漏らす