Terraformデータ駆動型設計の深淵：`templatefile`と`yamldecode`が生み出す「真の自動化」
インフラをコード化する（IaC）ことと、インフラをデータから生成することの間には、深い溝がある。
多くのエンジニアは、`main.tf`にリソースをべた書きし、`variables.tf`に環境ごとの値を列挙するだけで満足している。だが、それは単なる「静的な設定のテンプレート化」に過ぎない。真のSREが目指すのは、インフラ構成そのものを一つの「データセット」として扱い、Terraformをその解釈器（インタプリタ）として駆動させるアーキテクチャだ。
本稿では、`yamldecode`と`templatefile`を極限まで使い倒し、静的コードから脱却した「データ駆動型インフラ」の深淵を解説する。
—
1. なぜ「データ駆動」なのか：DRY原則の先の次元へ
大規模なマルチ環境管理において、リソース定義の複製は「悪」だ。環境が増えるたびに`terraform.tfvars`が増殖し、モジュールの呼び出しコードが肥大化する。
データ駆動設計の目的は、「リソースの定義」と「リソースの構造」を完全に分離することにある。Terraformの役割は「どう作るか（ロジック）」に特化させ、YAMLは「何を作るか（データ）」に特化させる。この疎結合こそが、CI/CDパイプラインを簡潔にし、ヒューマンエラーを物理的に排除する鍵となる。
—
2. yamldecodeによるコンフィグの構造化
`yamldecode`は、単なる文字列読み込みではない。YAMLの階層構造をTerraformの複雑なオブジェクト型（`map`, `list`, `object`）に変換する強力なコンパイラだ。
実践：動的リソース生成の極意
例えば、複数のネットワーク・セキュリティグループを定義する場合、Terraformの`for_each`と組み合わせることで、YAMLの変更だけでインフラが自動的に再構成される仕組みを構築できる。
locals.tf
locals {
# YAMLを読み込み、型を明示的に検証することでスキーマの整合性を担保する
security_groups = yamldecode(file(“${path.module}/config/sg_rules.yaml”))
}
main.tf
resource “aws_security_group” “dynamic_sg” {
for_each = local.security_groups.rules
name = each.key
description = each.value.description
vpc_id = var.vpc_id
dynamic “ingress” {
for_each = each.value.ingress_rules
content {
from_port = ingress.value.from
to_port = ingress.value.to
protocol = ingress.value.protocol
cidr_blocks = ingress.value.cidrs
}
}
}
エキスパートの知見:
`yamldecode`の結果を`try()`関数や`coalesce()`と組み合わせることで、YAML内に未定義のキーが存在してもデフォルト値を適用する「防御的な構成管理」が可能になる。Terraformの実行時エラーを最小化し、パイプラインの堅牢性を高める定石だ。
—
3. templatefileによる「コードのインジェクション」
`templatefile`は単なる文字列置換ではない。HCLのロジックをテンプレート内に持ち込める最強のプリプロセッサだ。特にUser Dataスクリプトや、複雑なIAMポリシーの生成において、その真価を発揮する。
高度な連携：ポリシードキュメントの動的生成
IAMポリシーをJSONで書くのは苦行だ。`templatefile`を使えば、HCLの条件分岐を埋め込んだ「賢いテンプレート」を作成できる。
templates/iam_policy.json.tftpl
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: [${join(“,”, [for a in actions : “\”${a}\””])}],
“Resource”: “${resource_arn}”
}
]
}
main.tf
resource “aws_iam_policy” “dynamic_policy” {
policy = templatefile(“${path.module}/templates/iam_policy.json.tftpl”, {
actions = [“s3:GetObject”, “s3:ListBucket”]
resource_arn = “arn:aws:s3:::my-bucket”
})
}
パフォーマンスへの配慮:
`templatefile`はメモリ上で文字列を展開する。巨大なテンプレートや過度なループ処理は、`terraform plan`時のメモリ消費を増大させる。大規模な構成では、テンプレートを細分化し、階層的に読み込む設計を推奨する。
—
4. 完全自動化への道：API/CLIによるデータ生成
究極の自動化とは、Terraformを実行する前に「Terraform用のYAML」を外部スクリプトで生成することだ。
私は現場で、「Cloudの稼働状況を監視し、その結果からリソースのスケール設定をYAMLとして書き出すPythonスクリプト」をパイプラインに組み込んでいる。
1. Discovery: AWS API/CLIで現在の負荷状況を取得。
2. Analysis: 最適なインスタンス数やスペックを算出。
3. Generation: `config/auto_scale.yaml`を上書き生成。
4. Execution: `terraform apply`を実行。
このサイクルを回すことで、人間は「ポリシー」を定義するだけで、インフラは自律的に最適化を続ける。
—
5. まとめ：SREが守るべき「境界線」
データ駆動型設計における唯一の注意点は、「複雑さの転嫁」だ。YAMLが複雑になりすぎると、それはもはやコードではなく、デバッグ不可能なブラックボックスになる。
- スキーマの管理: YAMLのバリデーションには`JSON Schema`を導入せよ。
- 可視化: `terraform plan`の出力だけではデータ駆動の挙動は見えない。CI上で`yq`コマンドを使い、適用される設定をdiffとして出力するフローを構築せよ。
Terraformは単なるツールではない。それはクラウドという巨大なAPIを抽象化し、意のままに操るための「言語」だ。`yamldecode`と`templatefile`を使いこなし、インフラという複雑系を「計算可能な状態」へと昇華させてほしい。
我々の仕事は、インフラを構築することではない。「インフラが自ら最適化される仕組みを設計すること」なのだから。