Terraformを「枯れた技術」にするな。Makefileで構築する最強のIaCワークフロー戦略
Terraformを触り始めて数年、多くのチームが同じ罠に陥る。「誰がどの環境に何を適用したか分からない」「コマンドの打ち間違いで本番環境のPlanが飛ぶ」「そもそもCI/CDとの乖離が激しい」。
これらはツールが悪いのではない。「人間」という最も信頼性の低いインターフェースに、複雑なオペレーションを委ねているからだ。
真のSREは、Terraformを単なるCLIとして扱わない。コマンドを抽象化し、チーム全員が「思考停止しても事故らない」ワークフローを構築する。今日は、現場の生産性を極限まで高めるためのMakefile駆動型ワークフローの真髄を伝授する。
—
1. なぜ「Makefile」でラップするのか？
TerraformのCLIは高機能だが、オプションが多すぎる。`-var-file`, `-backend-config`, `-workspace` を毎回手打ちするエンジニアは、いずれ必ず致命的なミスを犯す。
Makefileは、単なるタスクランナーではない。「チームのオペレーション標準化」というドキュメントを、実行可能なコードとして強制する境界線だ。
実践的なMakefile構成
環境変数とワークスペースを動的にバインドし、ヒューマンエラーの余地をゼロにする。
変数定義: 環境名(env)を引数として受け取ることを強制
ENV ?= dev
WORKSPACE_FILE := .terraform/environment
.PHONY: init plan apply
ワークスペースとバックエンドの整合性を維持するガードレール
init:
@echo “==> Initializing for $(ENV)…”
terraform init \
-backend-config=config/$(ENV).hcl \
-reconfigure
terraform workspace select $(ENV) || terraform workspace new $(ENV)
plan: init
@echo “==> Planning for $(ENV)…”
terraform plan -var-file=vars/$(ENV).tfvars -out=tfplan
apply:
@echo “==> Applying for $(ENV)…”
terraform apply tfplan
ポイント:
- `init` に環境切り替えを内包させることで、誤ったコンテキストでの実行を防ぐ。
- `plan` の出力を `tfplan` ファイルに固定し、`apply` はそのファイル以外受け付けないようにする。これが「PlanとApplyの乖離」を防ぐ唯一の解だ。
—
2. 開発スピードを劇的に高める「神ツール」と設定
ターミナルで `terraform plan` を打って出力結果を眺めている時間は、現代のエンジニアにとって無駄でしかない。
必須プラグイン・ツール
1. [tflint](https://github.com/terraform-linters/tflint): 静的解析の神。AWS/GCP/Azureのプロバイダー固有のルールをチェックし、「壊れる前に止める」。
2. [tfsec](https://github.com/aquasecurity/tfsec): セキュリティ設定の静的解析。S3バケットの公開設定ミスなどをCIで即座に検知する。
3. [Terraform Visual](https://github.com/hishigami/terraform-visual): `terraform plan -json` をグラフィカルに可視化する。複雑な依存関係をコードレビューする際、これほど強力なツールはない。
エディタ設定（VS Code推奨）
`.vscode/settings.json` で自動フォーマットを強制せよ。
{
“editor.formatOnSave”: true,
“terraform.languageServer.enabled”: true,
“editor.codeActionsOnSave”: {
“source.fixAll.terraform”: “explicit”
}
}
—
3. チーム開発における「絶対ルール」
コードの品質は、書き方よりも「制約」によって決まる。
① ディレクトリ構造のベストプラクティス
「環境ごとのディレクトリ」は、DRYを過度に意識して複雑怪奇なモジュール地獄を生む。現場で最もスケーラブルなのは Terragrunt的アプローチ、あるいはシンプルに環境ごとに変数を分離する構成だ。
├── modules/ # 再利用可能なモジュール
├── vars/ # 環境ごとのtfvars
│ ├── dev.tfvars
│ └── prod.tfvars
├── config/ # バックエンド設定
│ ├── dev.hcl
│ └── prod.hcl
└── main.tf # ルートモジュール
② CI/CDとの親和性
MakefileをCI環境（GitHub Actions等）から呼び出す際、以下のように実行する。
- name: Terraform Plan
run: make plan ENV=prod
ローカル環境とCIで同じコマンドが動くこと。これが「再現性」の正体だ。環境差分による「ローカルでは動いたのに」という言い訳を、システム的に封殺する。
—
4. 伝説のエンジニアからの「極限の知見」
最後に、一つだけ。「Terraformのコードを完璧にしようとするな」。
Terraformは、APIのラッパーに過ぎない。コードが複雑になりすぎたなら、それは「Terraformでやるべきではない」というシグナルだ。Lambdaでの自動化や、Kubernetesカスタムコントローラーへの移行を検討すべきタイミングかもしれない。
最高のインフラ構成管理とは、コードを書くことではなく、書かなくて済む仕組みを作ることにある。
Makefileは、そのための最もシンプルで、最も強力な武器だ。今日から、手動でコマンドを叩くのはやめよう。コードに意思を込め、Makefileに実行を委ねるのだ。それが、世界最高峰のエンジニアへの第一歩となる。
さあ、ターミナルを開き、君のワークフローをリファクタリングしろ。