Terraformの基礎（HCL・state）｜クラウドインフラ

🎓 レベル：標準　|　重要度：A（必須）

📎 前提：IaCとは・宣言的構成　|　関連：モジュール化と環境分離・構成管理とImmutable Infrastructure

要点（BLUF）

Terraform は、資源を HCL（HashiCorp Configuration Language）で宣言し、plan（差分計算）→ apply（適用） で現実を寄せる代表的IaCツール。プロバイダ経由で各クラウドを操作する。
state が肝。Terraform は「コードと現実の対応表」を terraform.tfstate に持ち、これを基準に差分を計算する。stateの破損・共有ミスが事故の中心。
ライセンス変更後の**オープンソースfork「OpenTofu」**が HCL/state 互換で広く使われる（要最新確認）。

概念 ── HCL・プロバイダ・state

Terraform の登場人物は3つ。

HCL：宣言を書く言語。resource "種類" "名前" { ... } で資源を定義。
プロバイダ（provider）：クラウドごとの「ドライバ」。AWS・Azure・Google Cloud などのAPIを Terraform から叩けるようにする（資源の品揃え＝主要サービスの地図（計算・保存・ネットワーク・DB））。
state：コードの資源と実在する資源のIDを結びつける対応表。これがあるから「次に apply したとき、何が既にあって何が無いか」を判断できる。

flowchart LR
    hcl["HCL（宣言）"] --> tf["Terraform Core"]
    state["state（コードと現実の対応表）"] --> tf
    tf -->|"差分を計算"| plan["plan（作成/変更/削除の一覧）"]
    plan -->|"apply"| provider["プロバイダ"]
    provider --> cloud["クラウドAPI → 実資源"]
    cloud -->|"refresh でstate更新"| state

仕組み ── plan/apply のサイクル

# main.tf
terraform {
  required_providers {
    local = { source = "hashicorp/local" }   # デモ用ローカルプロバイダ
  }
}

resource "local_file" "hello" {
  filename = "${path.module}/out/hello.txt"
  content  = "managed by terraform\n"
}

output "path" {
  value = local_file.hello.filename
}

terraform init      # プロバイダを取得（最初の1回）
terraform plan      # 差分: + create local_file.hello
terraform apply     # 実際に作る → state に記録
terraform apply     # 2回目: No changes（冪等）
terraform destroy   # 宣言した資源を消す

plan の出力は +（作成）・~（変更）・-（削除） の記号で差分を示します。特に -（削除） が意図せず出ていないか、apply 前に必ず確認します。

仕組み ── state の扱い（最重要）

state は機密を含みうる（接続情報・生成パスワード等）うえ、チームで共有・ロックしないと壊れます。2人が同時に apply すると state が競合し、現実とズレます。だから本番は リモートstate（クラウドのオブジェクトストレージ＋ロック）に置きます（モジュール化と環境分離）。

# 本番のリモートstate（疑似・プロバイダ依存・要最新確認）
terraform {
  backend "s3" {
    bucket = "my-tf-state"
    key    = "prod/terraform.tfstate"
    # ロック機構を併用して同時apply事故を防ぐ
  }
}

なぜ state を持つのか

差分計算の基準にするため：「コードにある」だけでは「実在するか」が分からない。state が対応表となり、作る/変える/消すを正しく判断できる。
削除を扱うため：コードから resource を消したとき、state があるから「これは消すべき実資源」と特定できる。state が無ければ孤児資源（誰も管理しない課金）になる。
だからこそ守る：state はクラスタにおける etcd（Kubernetesの全体像（宣言的・調整ループ））に相当する「真実の源」。破損・流出は致命的。

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

「state を git にコミット」→ 機密が漏れ、ロックも効かない。リモートstate＋暗号化＋ロックが定石。.gitignore に *.tfstate。
「plan を見ずに apply」→ 意図しない削除・再作成（destroy/recreate）を見逃す。必ず差分確認。
「state を手で編集」→ 整合性が壊れる。やむを得ない時は terraform state サブコマンドで慎重に。
「プロバイダ/モジュールのバージョン未固定」→ ある日 init で別バージョンが入り挙動が変わる。required_providers でバージョン固定。
「OpenTofu と Terraform を混同して情報を鵜呑み」→ ライセンス・機能差は動きが速い。要最新確認。

対応ラボ

cloud-infra-study/labs/05-02_terraform/（local プロバイダで local_file を作る最小構成。クラウド資格情報なしで init→plan→apply→apply(冪等)→destroy を体験）。