構成管理とImmutable Infrastructure｜クラウドインフラ

🎓 レベル：発展　|　重要度：B（推奨）

📎 前提：Terraformの基礎（HCL・state）　|　関連：コンテナとは（名前空間・cgroups）・デプロイ戦略（ローリング・ブルーグリーン・カナリア）

要点（BLUF）

IaC には2つの役割がある。プロビジョニング＝資源を作る（Terraform）、構成管理＝作った資源の中身（パッケージ・設定）を整える（Ansible 等）。標準パターンは「Terraform が作り、Ansible が仕上げる」。
Immutable Infrastructure（不変インフラ）＝稼働中のサーバを変更せず、作り直して置き換える運用。「直す」でなく「捨てて新しく」。
不変運用の鍵がゴールデンイメージ：構成済みのイメージを一度焼き（Ansible/Packer）、それを Terraform で並べる。コンテナ（コンテナとは（名前空間・cgroups））はこの思想を最初から体現している。

概念 ── プロビジョニング vs 構成管理

両者は層が違います。Terraform は「箱（VM・NW・LB）を作る」のが得意で、箱の中の「OS設定・パッケージ・アプリ配置」は構成管理ツール（Ansible・Chef・Puppet 等）の領分です。

flowchart LR
    tf["Terraform：プロビジョニング（VM・NW・LBを作る）"] --> out["出力: IP・認証情報"]
    out --> ans["Ansible：構成管理（中にパッケージ・設定・アプリを入れる）"]
    ans --> ready["稼働可能なサーバ"]

標準的な連携は「Terraform が資源を作って IP 等を出力 → Ansible がその IP に対して構成を流す」。役割を混ぜず、適材適所で使います（要最新確認の各ツール仕様）。

仕組み ── Mutable と Immutable

	Mutable（可変）運用	Immutable（不変）運用
変更方法	稼働中サーバにSSHして変更	新イメージを焼いて入れ替え
状態	サーバごとに差が出やすい	全台が同一（ドリフトしない）
ロールバック	手で巻き戻す（難しい）	前のイメージに戻すだけ
例	apt upgrade を本番で直接	ゴールデンイメージ＋作り直し

可変運用は、サーバを長生きさせ手で直し続けるので、いつしか「誰も再現できない一点物（スノーフレーク）」になりドリフト（IaCとは・宣言的構成）が溜まります。不変運用は、変更のたびにまっさらなイメージを焼いて丸ごと置き換える。全台が同一で、戻すのも前のイメージに切り替えるだけ。

flowchart LR
    code["設定の変更（コード）"] --> bake["イメージを焼く（Ansible/Packer）"]
    bake --> img["ゴールデンイメージ v2"]
    img --> deploy["Terraform で新イメージのVM群を作成"]
    deploy --> swap["LBを新群へ切替（旧群は破棄）"]

動く例 ── Ansible playbook の最小形

Ansible は冪等な構成を YAML（playbook）で宣言します。SSH（パッケージとユーザー・SSH）でターゲットに接続し、状態を収束させます。

# playbook.yml ── nginx を入れて起動する（冪等）
- hosts: web
  become: true
  tasks:
    - name: nginx を導入
      ansible.builtin.apt:
        name: nginx
        state: present          # あれば何もしない（冪等）
    - name: nginx を起動・自動起動
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true

ansible-playbook -i inventory.ini playbook.yml
# 2回目以降は「changed=0」＝すでに望ましい状態（冪等性）

ゴールデンイメージ運用では、この playbook を起動中サーバでなくイメージビルド時に流し、焼けたイメージを Terraform で並べます。

なぜ Immutable なのか

ドリフトを構造的に消すため：作り直すので、稼働中サーバへの手変更が積み重ならない。全台が常に同一。
ロールバックを簡単にするため：問題が出たら前のイメージに切り替えるだけ。手で巻き戻す運用より速く確実（デプロイ戦略（ローリング・ブルーグリーン・カナリア）のブルーグリーンと相性が良い）。
コンテナへの自然な接続：コンテナは「イメージを焼いて使い捨て」そのもの（Dockerイメージとレイヤ）。Immutable の考え方を最初から内蔵している。だから現代は構成管理の比重がコンテナ＋イメージへ移りつつある（要最新確認）。

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

「Terraform で OS 内のパッケージまで全部やる」→ 不向き。中身は構成管理（Ansible）かイメージ焼きへ。役割分担を守る。
「不変と言いつつ本番サーバにSSHして手直し」→ それは可変運用。手で触った瞬間にドリフトが始まる。直したいならイメージを焼き直す。
「Ansible は冪等だから何でも安全」→ command/shell タスクは冪等でないことが多い。状態を表すモジュール（apt・service 等）を優先。
「ゴールデンイメージは作りっぱなしでよい」→ 中のソフトが古び脆弱性が溜まる。定期的に焼き直す運用が前提。
「ステートフルなデータも作り直しで消す」→ データは不変対象外。永続化（ConfigMap・Secret・ボリュームのPV・外部DB）へ分離してから作り直す。

対応ラボ

cloud-infra-study/labs/05-04_playbook.yml ＋ 05-04_inventory.ini（nginx を入れる最小 Ansible playbook。--check で冪等性のドライランを観察。実行には Ansible とターゲットhost）。