對於許多使用 Infrastructure as Code (IaC) 的工程師來說，Terraform 的模組管理一直存在一些令人沮喪的限制。最新的 Terraform 1.15 版本針對這些長期被社群詬病的痛點進行了修正，特別是在模組來源的靈活性以及 API 變更的溝通機制上。
這次更新最核心的變動在於引入了動態模組來源。在過去的版本中，module 區塊中的 source 與 version 屬性必須是靜態字串，不能使用變數。這意味著如果你需要根據不同環境（如開發、測試、正式環境）指向不同的模組版本或不同的 Registry 倉庫，你必須為每個環境重複撰寫一整套模組定義，導致程式碼冗餘且難以維護。
為了達成動態化，Terraform 1.15 引入了 const 屬性。當你在定義變數時將 const 設為 true，Terraform 會將其標記為常數，使其能在 terraform init 階段（即正式評估配置之前）就被解析。這樣一來，工程師就能在 module source 中使用插值語法引用這些變數，大幅提升了配置的彈性。
除了動態來源，另一個對模組維護者極其重要的功能是正式的棄用機制（Deprecation Mechanism）。以往當模組作者想要更改變數名稱或移除某個輸出（Output）時，只能在 Release Note 中告知使用者，使用者除非在執行時報錯，否則很難察覺自己使用了過時的介面。現在，作者可以直接在變數或輸出區塊中添加 deprecation 訊息。當使用者調用這些被標記為棄用的項目時，Terraform 會在驗證階段發出警告，讓使用者有緩衝期進行遷移，而不需要直接面對系統崩潰。
在類型系統方面，1.15 引入了 convert 函數來處理行內類型轉換。在 HCL 語言中，Terraform 的自動類型推斷有時會產生非預期的結果。例如，空的大括號 {} 會被推斷為空物件（Object）而非空映射（Map），空中括號 [] 則被視為元組（Tuple）而非列表（List）。當你在使用條件表達式且兩個分支推斷出不同類型時，常會觸發類型不匹配的錯誤。新的 convert 函數允許工程師明確指定想要的類型，消除這種模糊性。
此外，輸出區塊（Output blocks）現在也支援 type 屬性，這讓輸出端也能像輸入變數一樣擁有嚴格的類型檢查與文件化能力。
從產業脈絡來看，這次更新也被視為 HashiCorp 在面對開源分叉版本 OpenTofu 競爭下的回應。OpenTofu 在 1.8.0 版本就已經實作了類似的早期變數評估功能。雖然兩者在實作細節上有所不同，但方向一致，都是為了讓平台工程師能更高效地管理大規模、多環境的基礎設施。
其他實務上的小幅改進還包括： Windows ARM64 原生支援，提升開發環境相容性。 S3 Backend 現在支援 AWS CLI v2.32.0 的臨時認證，減少對長期 Access Key 的依賴，提升安全性。 terraform validate 命令現在會檢查 Backend 區塊。這對 CI/CD 流程很有幫助，因為以前 Backend 配置錯誤要等到 init 階段才會發現，現在可以在更早的驗證階段攔截錯誤，節省 pipeline 執行時間。 測試框架強化，現在可以在 mock_data 等區塊中使用函數（如 uuid()），讓測試數據的生成更具動態性。
總結來說，Terraform 1.15 並沒有追求華麗的新功能，而是選擇修補那些讓工程師在日常維運中感到痛苦的細節。對於需要管理大量模組版本與複雜環境的團隊而言，這次更新將顯著降低維護成本。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。