Terraformの「バージョン地獄」を回避せよ：依存関係管理の奥義と鉄壁のプロバイダ戦略
クラウドインフラをコードで定義する我々にとって、`terraform init` は単なる初期化コマンドではない。それは、外部の巨大なエコシステムと我々の環境を同期させる「契約」だ。
しかし、多くのチームがこの契約を疎かにしている。`version = “~> 3.0″` と書き、思考停止して放置した結果、ある日突然CIが燃え上がる。「昨日は動いていたのに」という悲鳴は、あなたのコードのせいではない。固定されていない依存関係が招いた「破壊的変更（Breaking Changes）」という名の必然だ。
本稿では、Terraformのプロバイダ管理を極め、インフラを「壊れない資産」に変えるための生存戦略を授ける。
—
1. なぜ「甘い固定」が惨劇を招くのか
Terraformのプロバイダは日々進化している。`hashicorp/aws` のようなメジャーなものでさえ、非推奨リソースの削除や、デフォルト挙動の変更（例：タグ付けの強制化やAPIの挙動変更）が容赦なく行われる。
特にサードパーティ製のプロバイダは注意が必要だ。開発者の熱量に依存し、CI/CDパイプラインを破壊する更新がパッチバージョンで混入することも珍しくない。
惨劇のメカニズム
- 暗黙のアップグレード: `version` を曖昧にすると、`terraform init` がその瞬間の最新を取得する。CIの環境ごとにバージョンが乖離し、「ローカルでは動くが本番では死ぬ」というSREにとって最悪のデバッグ地獄が完成する。
- Stateの乖離: 古いプロバイダで作成されたリソースが、新しいプロバイダのスキーマと衝突し、`terraform plan` が通らなくなる事態。
—
2. 依存関係管理の絶対原則：「`.terraform.lock.hcl` を聖域とせよ」
`.terraform.lock.hcl` は単なるログではない。それは、「この環境で正しく動くことが証明されたハッシュ値のリスト」である。
プロフェッショナルの運用ルール
1. Gitコミットは必須: `.terraform.lock.hcl` を `.gitignore` しているチームは今すぐやめろ。これはコードの一部だ。
2. `terraform providers lock` を活用せよ: マルチプラットフォーム（開発者のMacとCIのLinuxなど）で開発する場合、全てのアーキテクチャのハッシュを記録しなければならない。
# 全プラットフォームのハッシュをロックファイルに含める
terraform providers lock -platform=linux_amd64 -platform=darwin_arm64
—
3. ベストプラクティス：厳密なバージョン制約
`~> 4.0` は甘えだ。本番環境では、極限まで制約を絞るのがSREの流儀。
terraform {
required_version = “>= 1.5.0” # Terraform自体のバージョンも固定する
required_providers {
aws = {
source = “hashicorp/aws”
# パッチバージョンまで固定し、レビューを経て上げるのが鉄則
version = “5.31.0”
}
datadog = {
source = “DataDog/datadog”
version = “3.35.0”
}
}
}
—
4. 現場で震えるほど役立つ「プロのツールボックス」
① 神プラグイン：`Terraform Visual Studio Code Extension`
単なる補完ではない。`HashiCorp` 公式は必須だが、「Terraform Doc Gen」を併用せよ。READMEにリソースの引数を自動生成するだけで、チームの生産性は跳ね上がる。
② 隠れたキーボードショートカット (VS Code)
- `Alt + Shift + F`: Terraformのフォーマット（`terraform fmt` 相当）。これを保存時に走らせる設定は基本中の基本。
- `Ctrl + Shift + P` -> `Terraform: Init`: コンテキストメニューから脱却し、キーボードで初期化せよ。
③ チーム開発を加速させる `tflint`
静的解析ツール `tflint` は、もはや空気だ。プロバイダ固有のルールチェックを有効にし、CIで必ず弾く設定にすること。
.tflint.hcl の構成例
plugin “aws” {
enabled = true
version = “0.27.0”
source = “github.com/terraform-linters/tflint-ruleset-aws”
}
rule “aws_instance_invalid_type” {
enabled = true
}
—
5. 安全な追従のためのワークフロー
バージョンを上げる際は、以下のフローを徹底せよ。
1. Renovate/Dependabotの導入: プロバイダの更新を検知し、Pull Requestを自動生成させる。
2. Planの視覚化: PRのコメントに `terraform plan` の結果を自動出力する（`tfcmt` 等を使用）。
3. 破壊的変更の確認: Terraform Registryの `Changelog` を必ず読み、`terraform plan` でリソースの `destroy` が発生しないか細心の注意を払う。
—
最後に：コードは「対話」である
インフラの構成管理において「楽をする」とは、「思考を放棄すること」ではない。「将来の自分が苦しまないための仕組みを、今のうちに構築しておくこと」だ。
プロバイダのバージョンを固定し、ロックファイルを厳格に管理する。一見地味なこの作業こそが、深夜の障害対応を未然に防ぐ、最強のインフラエンジニアの嗜みである。
さあ、今すぐ `terraform providers lock` を実行し、あなたのインフラを「予測可能な状態」に取り戻せ。