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

IaC には大きく2つの書き方があります。

• 宣言的 — 「こうあってほしい」という 最終状態 を書く。どう作るかはツールに任せる
• 手続き的 — 「まずこれ、次にこれ」と 手順 を1つずつ書き並べる

主流は宣言的です。ツールが 現状 と コード（望む状態） を比べ、足りない物を作り・余分を消して、望む状態へ収束 させます。

この「現状に合わせて必要な分だけ動く」性質から、べき等性（※1）が生まれます。何度実行しても、既に望む状態なら何もせず、ずれていれば直すだけ。だから 安全に繰り返せます。

登場人物メモ:

• ※1 べき等性 — 何度実行しても同じ結果に収束する性質。途中失敗しても再実行で復旧できる
• ※2 プロビジョニング — サーバやネットワークなど、資源そのものを用意すること
• ※3 構成管理 — 用意した資源の中身（設定・パッケージ等）をあるべき状態に保つこと

1. 望む構成を コードで宣言 する（クラウドやVPCまで丸ごと）
2. ツールが 現状との差分 を計算する（何が足りず・何が余分か）
3. 差分だけを 適用 して、実状態を望む状態へ寄せる
4. コードを履歴管理に置き、変更はレビューを経て反映する

• 宣言的を基本に — 手順ではなく状態を書く。差分の計算はツールに任せ、人はゴールに集中
• べき等に保つ — 何度流しても壊れない設計にすると、失敗時の再実行が怖くなくなる
• プロビジョニングと構成管理（※2※3）— 資源を「用意する」層と、中身を「あるべきに保つ」層を分けて考える
• 履歴管理との相性 — 構成をコードにすると変更履歴が残り、いつ誰が何を変えたか追える。壊れたら前の版へ戻せる

さらに CI/CD と組み合わせると、構成の変更も 自動でテストして適用 できます。アプリだけでなくインフラも、同じ流れ作業に乗せられるわけです。

• 手動変更でのずれ（ドリフト） — 画面で直すとコードと現実が食い違い、次の適用で上書きされる
• 削除の巻き添え — 宣言から外した資源が消える。消してよい物か確認が要る
• 状態の取り違え — ツールが持つ「今の状態」の記録が壊れると、差分計算を誤る
• 秘密情報の混入 — 鍵やパスワードをコードに直書きすると、履歴に残って漏れる

このうちドリフトは、コード（望む状態）と実際のクラウド（実状態）を突き合わせれば見つかります。plan が差分（追加／変更／削除）を洗い出し、apply で望む状態へ戻します。