Terraformで「構築」を卒業せよ：インフラをコードの海に沈めるためのプロの流儀
「TerraformでEC2を立ててみました」——それはまだスタートラインにすら立っていない。
インフラをコード化する目的は、単に構築を自動化することではない。「インフラの状態を宣言し、あるべき姿を維持し続けること」にある。
本稿では、Terraformの基本をなぞりつつ、現場で「こいつ、できるな」と一目置かれるためのプロフェッショナルな設計思想と、開発速度を10倍に引き上げる極限のテクニックを授ける。
—
1. 開発環境を「神速」にするための武器庫
Terraformを書く上で、VS Codeのデフォルト設定で戦うのは丸腰で戦場に行くに等しい。まずは足場を固める。
必須の神プラグイン
- HashiCorp Terraform (official): 必須。これがないとシンタックスハイライトも補完も効かない。
- TFLint: ただの構文チェックではない。AWSのインスタンスタイプが正しいか、非推奨の設定をしていないかなど、クラウドプロバイダーのベストプラクティスに基づいた静的解析を行う。これを通さないコードは、現場では「未完成」とみなす。
開発を加速させる「指先」の設定
`.vscode/settings.json` に以下を仕込み、保存と同時に完璧なフォーマットを適用させる。
{
“[terraform]”: {
“editor.formatOnSave”: true,
“editor.defaultFormatter”: “hashicorp.terraform”
},
“editor.codeActionsOnSave”: {
“source.fixAll”: “explicit”
}
}
—
2. 現場で「死なない」ためのディレクトリ構成
初心者は `main.tf` にすべてを詰め込むが、それは技術的負債の塊だ。チーム開発では、モジュール化と環境分離を前提に設計する。
.
├── modules/ # 再利用可能なリソース定義
│ └── ec2/
├── environments/ # 各環境ごとの設定
│ ├── dev/
│ │ ├── main.tf # モジュールの呼び出しのみ記述
│ │ └── backend.tf # State管理の設定
│ └── prod/
└── global/ # IAMやRoute53など共通リソース
チーム開発の鉄則：State管理の共有
Terraformの心臓部である `terraform.tfstate` をローカルに置くなど論外だ。S3 + DynamoDB (State Locking) を使用し、排他制御を徹底せよ。
backend.tf の基本形
terraform {
backend “s3” {
bucket = “my-terraform-state-bucket”
key = “dev/ec2.tfstate”
region = “ap-northeast-1”
dynamodb_table = “terraform-lock” # ここでデッドロックを防ぐ
encrypt = true
}
}
—
3. 実戦：EC2インスタンス構築の「正しい」作法
ただ起動するのではなく、「冪等性（べきとうせい）」を意識した構成にせよ。
main.tf: リソース定義のベストプラクティス
resource “aws_instance” “web_server” {
ami = “ami-0c3fd0f5d33134a76” # 東京リージョン Amazon Linux 2023
instance_type = “t3.micro”
# 変更時に再作成を防ぐタグ付けの徹底
tags = {
Name = “web-server-dev”
Environment = “dev”
ManagedBy = “Terraform”
}
# プロビジョニングはTerraformで完結させるな。
# 複雑な設定はAnsibleやUser Data、あるいはECS/EKSに逃がすのが現代の定石。
user_data = <<-EOF
#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
EOF
}
---
4. プロの隠しコマンド：作業効率を極限まで上げる
現場で使えるTerraformのコマンドライン・ハックだ。
- `terraform plan -out=tfplan`:
`plan` の結果をファイルに保存し、`apply` 時にそのファイルを指定して実行する。これにより、「計画」と「適用」の間にインフラが変更されるリスクを排除する。
- `terraform graph | dot -Tpng > graph.png`:
リソースの依存関係を可視化する。複雑なスタックを組む際、どこで循環参照が起きているか一目瞭然になる。
- `terraform console`:
関数や変数の挙動をテストするREPL環境。`lookup()` や `element()` の動作確認に必須。
—
最後に：なぜ我々はTerraformを書くのか
「IaCは自動化ツールではない。インフラの『意図』をコードとしてドキュメント化するコミュニケーションツールである」
コードレビューを通じ、チームメンバーと「この設定値はなぜ必要なのか？」「このセキュリティグループは広すぎないか？」という議論を尽くしてほしい。それができるチームだけが、複雑なクラウド環境を完全に制御下に置くことができる。
さあ、エディタを開け。君のインフラがコードとなって動き出すのを、その目で確かめるんだ。