IaCとは・宣言的構成｜クラウドインフラ

🎓 レベル：基礎　|　重要度：A（必須）

📎 前提：Kubernetesの全体像（宣言的・調整ループ）　|　関連：Terraformの基礎（HCL・state）・Docker Composeで複数コンテナ

要点（BLUF）

IaC＝インフラを手作業でなくコードで宣言し、再現すること。クリック操作の手順書を、git管理できるコードに置き換える。
核は 宣言的（望ましい状態を書く）＋冪等性（何度適用しても同じ結果）。命令の列でなくゴールを書き、ツールが差分だけ埋める。
利点は再現性・レビュー性・差分管理。手作業由来の「スノーフレークサーバ（誰も再現できない一点物）」と構成ドリフトを防ぐ。

概念 ── 手順書からコードへ

従来のインフラ構築は、管理画面のクリックやSSHでの手作業＋手順書（Word/Wiki）でした。問題は、(1) 同じ環境を再現できない、(2) 誰がいつ何を変えたか追えない、(3) 手作業はミスる。

IaC はこれをコードに置き換えます。「VMを1台・このネットワークに・このサイズで」をテキストで宣言し、ツールに実行させる。Docker Compose（Docker Composeで複数コンテナ）がコンテナ構成をファイルにしたのと同じことを、クラウド資源全体に広げたものです。

flowchart LR
    code["インフラのコード（宣言）"] --> tool["IaCツール（Terraform等）"]
    tool --> diff["現実との差分を計算"]
    diff --> apply["差分だけ適用"]
    apply --> infra["クラウド資源（VM・NW・DB）"]
    infra -->|"実状態を読み戻す"| diff

仕組み ── 宣言的・冪等性・ドリフト

宣言的（declarative）：「どうやるか（手順）」でなく「どうあってほしいか（状態）」を書く。これは K8s（Kubernetesの全体像（宣言的・調整ループ））と同じ思想。対義は手続き的（命令の列）。

冪等性（idempotency）：同じコードを何度適用しても結果は同じ。1回目で作り、2回目以降は「もうある」と認識して何もしない。だから「途中で失敗→もう一度実行」が安全。

再現性（reproducibility）：同じコードから同じ環境が起こせる。dev で確かめた構成を prod でそのまま再現（モジュール化と環境分離）。

ドリフト（drift）：コード（あるべき姿）と現実がズレること。誰かが管理画面で手で変えると発生。IaC は「コードを正」とし、plan で差分を可視化して現実をコードへ戻す。

flowchart TB
    desired["コード＝あるべき状態"] --> compare["plan で比較"]
    actual["現実の状態（手で変更されドリフト）"] --> compare
    compare -->|"差分を表示"| review["人がレビュー"]
    review -->|"apply で収束"| actual

動く例 ── 宣言の最小形

HCL（Terraform の言語）の雰囲気。「何を」を書くだけで、作る手順は書きません（疑似・要最新確認）。

# 「このネットワークに、このサイズのVMを1台」を宣言
resource "cloud_instance" "web" {
  name         = "web-01"
  machine_type = "small"
  zone         = "asia-northeast1-a"
  network      = cloud_network.main.id
}

terraform plan     # 現実との差分を表示（何が作られ・変わり・消えるか）
terraform apply    # 差分だけ適用。もう一度 apply しても変化なし（冪等）

plan で適用前に影響を確認できるのがIaCの安全装置。手作業には無い「実行前プレビュー」です。

なぜ IaC なのか

再現とロールバックのため：環境がコードなので、消えても起こし直せる。変更も git 履歴で前へ戻せる。災害復旧（DR）の現実味が増す。
レビューと監査のため：インフラ変更が Pull Request になる。人が事前にレビューでき、誰がいつ何を変えたか git が記録する。
ドリフトを潰すため：手作業を排し「コードが正」とすることで、一点物サーバを無くし、環境差由来の障害を減らす。

⚠️ よくある誤解・落とし穴

「IaC を入れたのに管理画面でも手で変える」→ ドリフトの温床。変更は必ずコード経由に統一しないと意味が半減。
「apply をいきなり叩く」→ まず plan で差分確認。特に削除（destroy）を含む差分は要注意。
「冪等だから何回でも安全」→ ツールは冪等でも、外部の手変更があると差分が出る。plan で必ず確認。
「IaC＝Terraform だけ」→ 構成管理（Ansible）・イメージ作成（Packer）・K8s manifest も広義のIaC。役割で使い分ける（構成管理とImmutable Infrastructure）。
「コードにすれば設計も自動で良くなる」→ コード化は再現性を与えるだけ。良い構成（冗長化・最小権限）は別途設計が要る。

対応ラボ

なし（概念トピック）。実際に plan/apply を回す手は次の Terraformの基礎（HCL・state）のローカル Terraform ラボで。