大多數(shù)運(yùn)維工程師運(yùn)行過成千上萬次terraform plan，但幾乎沒人看過加上-json標(biāo)志后輸出的內(nèi)容。我在開發(fā)開源漂移檢測工具tfdrift時(shí)，花了兩周時(shí)間鉆進(jìn)這份JSON輸出。結(jié)果發(fā)現(xiàn)它結(jié)構(gòu)清晰得令人意外，但也藏著幾處文檔里找不到的陷阱。

如果你正在基于Terraform構(gòu)建任何工具——漂移檢測、策略執(zhí)行、成本估算、變更分析——這篇技術(shù)深潛就是我當(dāng)時(shí)希望有人寫給我的指南。

獲取JSON輸出的正確姿勢

首先，基礎(chǔ)操作。你不能直接管道terraform plan得到JSON。文本輸出和JSON輸出是完全不同的代碼路徑，必須分兩步走：

# 第一步：生成計(jì)劃文件terraform plan -out=tfplan -input=false -no-color# 第二步：轉(zhuǎn)換為JSONterraform show -json tfplan

-out標(biāo)志把計(jì)劃保存為二進(jìn)制文件（人類不可讀），terraform show -json再把它轉(zhuǎn)成結(jié)構(gòu)化JSON。第一步不能跳過——沒有terraform plan -json這種直接輸出JSON到stdout的標(biāo)志。這點(diǎn)最初讓我栽了跟頭。

Python里這樣實(shí)現(xiàn)：

import subprocessimport jsondef get_plan_json(workspace_path: str) -> dict:# 生成計(jì)劃文件subprocess.run(["terraform", "plan", "-out=tfplan","-input=false", "-no-color"],cwd=workspace_path,capture_output=True,text=True,timeout=600,# 轉(zhuǎn)換為JSONresult = subprocess.run(["terraform", "show", "-json", "tfplan"],cwd=workspace_path,capture_output=True,text=True,timeout=120,return json.loads(result.stdout)

注意幾個(gè)細(xì)節(jié)。plan的超時(shí)設(shè)為10分鐘——大型工作空間資源多，plan需要刷新狀態(tài)并調(diào)用云廠商API，耗時(shí)可能很長。show的超時(shí)更短，因?yàn)樗皇亲x取本地文件。另外必須加-input=false，因?yàn)槲覀円苑墙换ツＪ竭\(yùn)行——不加的話，Terraform可能掛起等待用戶輸入。

plan JSON的結(jié)構(gòu)

JSON輸出字段很多，但對漂移檢測來說，真正重要的只有一個(gè)：resource_changes。簡化版長這樣：

{"format_version": "1.2","terraform_version": "1.7.0","resource_changes": ["address": "aws_security_group.api_sg","mode": "managed","type": "aws_security_group","name": "api_sg","provider_name": "registry.terraform.io/hashicorp/aws","change": {"actions": ["update"],"before": {"ingress": ["from_port": 443,"to_port": 443,"cidr_blocks": ["10.0.0.0/8"]],"tags": {"Name": "api-sg"}},"after": {"ingress": ["from_port": 443,"to_port": 443,"cidr_blocks": ["10.0.0.0/8"]},"from_port": 22,"to_port": 22,"cidr_blocks": ["0.0.0.0/0"]],"tags": {"Name": "api-sg"}},"after_sensitive": {},"after_unknown": {}}

resource_changes里的每個(gè)條目代表Terraform想要修改的一個(gè)資源。change對象包含四個(gè)關(guān)鍵部分：

actions：一個(gè)數(shù)組，描述Terraform要對資源做什么?？赡艿闹蛋?code>["no-op"]（無變更）、["create"]、["update"]、["delete"]，以及組合如["delete", "create"]（銷毀后重建）。

before：資源的當(dāng)前狀態(tài)，直接從狀態(tài)文件讀取。

after：資源執(zhí)行計(jì)劃后的預(yù)期狀態(tài)。

after_unknown：執(zhí)行后才能確定的值，比如新創(chuàng)建資源的ID。

那些文檔沒寫的坑

第一，敏感值的處理。after_sensitive標(biāo)記哪些字段包含敏感數(shù)據(jù)，但它只告訴你字段名，不告訴你值在哪里。實(shí)際值被替換成true，你得自己遞歸遍歷after對象來定位。更麻煩的是，敏感標(biāo)記可能出現(xiàn)在嵌套結(jié)構(gòu)的任意層級(jí)。

第二，after_unknown的結(jié)構(gòu)與after不完全一致。有時(shí)候after里有個(gè)字段，after_unknown里對應(yīng)位置卻是true，表示整個(gè)字段未知；有時(shí)候是部分未知，比如列表里的某些元素。解析時(shí)必須同時(shí)處理布爾值和嵌套對象兩種情況。

第三，資源地址的解析。address字段看起來簡單，比如aws_security_group.api_sg，但模塊嵌套時(shí)變成module.vpc.aws_security_group.api_sg，甚至module.vpc.module.subnet.aws_security_group.api_sg。沒有內(nèi)置的分隔方法，只能按點(diǎn)號(hào)分割后手動(dòng)識(shí)別哪些是模塊前綴、哪些是實(shí)際資源。

第四，no-op動(dòng)作的噪音。即使資源沒有任何變更，只要被引用或依賴，也可能出現(xiàn)在resource_changes里，actions為["no-op"]。過濾掉這些條目能顯著減少后續(xù)處理的負(fù)擔(dān)。

從JSON到漂移檢測

tfdrift的核心邏輯其實(shí)不復(fù)雜：定期運(yùn)行上述流程，把resource_changes持久化，對比歷史記錄識(shí)別意外變更。真正的工程挑戰(zhàn)在于：

1. 大規(guī)模工作空間的性能——超時(shí)策略、并發(fā)控制、狀態(tài)緩存

2. 變更的語義理解——同樣是update，改標(biāo)簽和改安全組規(guī)則的風(fēng)險(xiǎn)等級(jí)完全不同

3. 噪聲過濾——自動(dòng)識(shí)別由正常部署引起的預(yù)期變更，只告警真正的漂移

JSON解析只是起點(diǎn)。但如果沒有吃透這份輸出的結(jié)構(gòu)和邊界情況，后續(xù)所有功能都建在沙地上。