Terraformコードの「手動リファクタリング」は死に値する：AST解析によるコード自動変換の極意
Terraformのコードベースが肥大化し、モジュールの分割やリソースの統合が必要になったとき、君たちはどうしている？まさか、`find`と`sed`を組み合わせて正規表現と格闘し、結局手動で修正してCIで事故を起こす……なんてことはしていないだろうな。
大規模なインフラを扱うSREとして、「コードの書き換え」は「コードを書くこと」と同等以上に厳格に自動化されるべきだ。今回は、正規表現の呪縛を解き放ち、AST（抽象構文木）をハックしてTerraformコードを安全かつ高速に変換する、プロの技を授ける。
—
1. なぜ「正規表現」は地獄への入り口なのか
TerraformのHCL（HashiCorp Configuration Language）は、単純なテキストではない。ブロックのネスト、型定義、関数呼び出し、これらを正規表現で処理しようとすれば、必ずエッジケースで詰む。
真のエンジニアは、コードを「構造」として捉える。`hcl2json` でJSONに変換し、パース可能な状態にしてから処理し、またHCLに戻す。あるいは、Goの `hclwrite` パッケージを用いて、プログラム的にASTを操作する。これが、大規模変更を数分で終わらせるための唯一の「安全な」道だ。
2. 実践：ASTを活用した自動リファクタリングのパイプライン
ここでは、特定のAWSリソースの引数を一括で置き換えるための、Pythonを用いたAST変換パイプラインの設計思想を示す。
ステップ1: `hcl2json` による正規化
まず、コードをJSONに変換することで、構文チェックをパスした「論理構造」に落とし込む。
HCLをJSONに変換し、解析可能な状態にする
hcl2json < main.tf > main.json
ステップ2: PythonによるAST変換スクリプト
次に、JSON構造を再帰的に巡回し、リソース定義を書き換える。
import json
def transform_resource(data):
# 特定のリソースブロックを再帰的に探索
for resource_type, resources in data.get(‘resource’, {}).items():
if resource_type == ‘aws_instance’:
for name, config in resources.items():
# ここでキーの変更や値の注入を安全に行う
if ‘instance_type’ in config:
config[‘instance_type’] = ‘t3.medium’ # 標準化を強制
return data
with open(‘main.json’, ‘r’) as f:
data = json.load(f)
transformed = transform_resource(data)
with open(‘main_new.json’, ‘w’) as f:
json.dump(transformed, f, indent=2)
ステップ3: 変換後のHCL化とフォーマット
最後に `terraform fmt` を通すことで、人間が読みやすい形式に整形する。これが「プログラムによる完全自動化」の基本だ。
—
3. 開発スピードを加速させる「SREの道具箱」
道具にこだわらないエンジニアに、最高の結果は出せない。チーム全体の生産性を底上げする「神セット」を共有する。
必須のVSCodeプラグイン
- Terraform (by HashiCorp): 言わずもがな。LSP（Language Server Protocol）の恩恵を最大限に受けろ。
- TFLint: `terraform plan` を打つ前に、AWSの推奨値違反や非推奨属性を検知する。CIに組み込むのは当然として、IDE上でリアルタイムに警告が出るように設定せよ。
.vscode/settings.json の鉄則
チーム全員の環境を統一し、「環境依存のバグ」を撲滅する。
{
“[terraform]”: {
“editor.formatOnSave”: true,
“editor.defaultFormatter”: “hashicorp.terraform”
},
“tflint.enable”: true,
“terraform.languageServer.args”: [“–enable-logs”]
}
チーム開発における「絶対ルール」
1. tfvarsの型定義を厳格化せよ: `variable` ブロックには必ず `type` と `description` を含めること。
2. `terraform-docs` をCIに組み込め: READMEの更新を手動でやるな。`provider` や `module` の構成図は常に最新であるべきだ。
3. `terragrunt` の採用検討: 大規模なDRY（Don’t Repeat Yourself）が必要なら、Terraform単体で頑張らず、Terragruntによる抽象化を検討せよ。
—
4. 最後に：インフラエンジニアのプライド
大規模なリファクタリングを前にしたとき、「面倒だからこのままでいいか」と自分に言い聞かせていないか？その妥協が、半年後の君自身を苦しめる技術的負債となる。
AST解析や自動化スクリプトを書くことは、一見遠回りに見えるかもしれない。しかし、「コードをプログラムで制御する」という意識を持つことこそが、インフラを「管理する」のではなく「支配する」ための第一歩だ。
ツールは使うものではない。手足にするものだ。さあ、今すぐそのレガシーなコードベースを、プログラムの力で美しく再構築してこい。健闘を祈る。