Terraform vs Ansible：その「境界線」を越えろ。IaCの真髄を極めるアーキテクチャ設計
「TerraformとAnsible、結局どっちを使えばいいのか？」
この問いは、インフラエンジニアが一度は通る道だ。しかし、この問い自体がすでに古い。「どちらかを選ぶ」のではなく、「どちらをどのフェーズで殺し、生かすか」を設計するのが、真のテックリードの仕事だ。
今日は、表面的な比較論を卒業し、モダンなクラウドネイティブ開発における両者の「分水嶺」と、現場の生産性を極限まで高めるための技術的最適解を授ける。
—
1. 「プロビジョニング」と「構成管理」の哲学的な境界線
多くのエンジニアが陥る罠は、TerraformでOS内の設定をいじり、AnsibleでクラウドのAPIを叩こうとすることだ。これは「地獄への道」だ。
- Terraform（プロビジョニングの王）:
- 役割: クラウド上のリソースの「状態（State）」を定義する。
- 設計思想: 宣言的（Declarative）。「あるべき姿」を記述し、APIリクエストの冪等性を担保する。
- Ansible（構成管理の将）:
- 役割: インスタンス内部の「状態（State）」を制御する。
- 設計思想: 手続き型（Procedural）。OSのパッケージ、ファイル、サービス起動順序といった「動的な変化」に強い。
結論: Terraformで箱（VPC, RDS, EC2）を作り、Ansibleで中身（Middleware, App runtime）を仕立てる。この分業こそが、複雑性を最小化する唯一の解だ。
—
2. Terraform開発を「秒速」にする極限環境設定
Terraformのコードレビューで時間を溶かしているチームに未来はない。開発体験（DX）を最大化するセットアップを導入せよ。
【絶対入れるべき神プラグイン：VS Code編】
- HashiCorp Terraform: 公式プラグイン。`terraform fmt` と `terraform validate` を保存時に自動実行させるのが鉄則。
- tflint: 「動くけど間違ったコード」を検知する。クラウドのProviderごとのベストプラクティスを強制する。
- Terraform Graph: 依存関係が複雑化した際、視覚的に構造を把握するために必須。
【生産性を3倍にするショートカット】
- `Ctrl + Space`: リソースの引数補完（これでドキュメントを行き来する時間がゼロになる）。
- `F12`: リソース定義へのジャンプ（モジュール化された巨大なコードベースの歩き方）。
—
3. 実践：AnsibleとTerraformのベストプラクティス構成
TerraformがEC2を立ち上げた直後にAnsibleを自動実行させる。この「つなぎ」をスマートに行うのがプロのやり方だ。
Ansibleのベストプラクティス：ディレクトリ構成
モジュール化と再利用性を極限まで高めるための構造例。
ansible-project/
├── group_vars/
│ ├── all.yml # 全体共通変数
│ └── webservers.yml # Web層特有の設定
├── roles/
│ └── nginx/ # 再利用可能なロール
│ ├── tasks/main.yml
│ └── templates/nginx.conf.j2
├── site.yml # エントリーポイント
└── inventory.ini # Terraformから動的インベントリで生成
TerraformからAnsibleをトリガーする「魔法のコード」
`null_resource` を使い、プロビジョニング完了後にAnsibleをキックする。
resource “aws_instance” “web” {
ami = “ami-xxxxxx”
instance_type = “t3.medium”
# … 省略
}
インスタンス生成後にAnsibleを実行するトリガー
resource “null_resource” “ansible_provisioner” {
triggers = {
instance_id = aws_instance.web.id
}
provisioner “local-exec” {
# 出来上がったIPをAnsibleに渡す
command = “ansible-playbook -i ${aws_instance.web.public_ip}, site.yml”
}
}
—
4. チーム開発における「絶対ルール」
コードの品質はツールの選定ではなく、「制約」によって決まる。
1. Stateファイルの管理: TerraformのStateファイルは必ずS3 + DynamoDB（State Lock）で管理せよ。ローカルのStateファイルは「ゴミ」だ。
2. モジュール化の限界: 3回以上同じリソース構成を書いたら迷わずモジュール化しろ。ただし、過度な抽象化はデバッグを困難にする。「再利用性」より「可読性」を優先せよ。
3. CI/CDでの自動実行: `terraform plan` の結果をPRのコメント欄に自動投稿させろ。人間が手元で実行する回数を極限まで減らすのが、ヒューマンエラーを防ぐ唯一の方法だ。
最後に：エンジニアとしての矜持
TerraformもAnsibleも、ただの「ツール」に過ぎない。重要なのは、「インフラをコード化することによって、人間が本来やるべきクリエイティブな仕事にどれだけ時間を使えるか」だ。
ツールに振り回されるな。ツールを支配し、インフラを「自動で生成され、自己修復する生命体」へと昇華させろ。それが、我々SREに課せられた使命だ。
さあ、コードを開け。今すぐTerraformの`plan`を叩き、Ansibleの`playbook`を洗練させろ。現場は、君のその一行のコードを待っている。