Terraform 1.16：Actions 補上銷毀生命週期，import 進駐子模組
HashiCorp Blog · 2026-09-28
在 Terraform 1.16 之前，一個資源被砍掉的那一刻，Actions 完全插不上手——生命週期只掛在建立與更新兩個階段，銷毀永遠是個空洞。HashiCorp 在這個版本補上這塊缺口，同時讓 import 區塊第一次可以直接寫進子模組，不必再由根模組代勞。
背景：銷毀階段的空白，以及 import 的位址依賴
Terraform Actions 讓使用者在資源生命週期的特定時間點觸發自訂動作，但問題出在銷毀路徑完全沒有掛勾：resource 被刪除前後，沒有辦法通知外部系統，也做不了收尾工作，例如把伺服器從盤點系統移除、清空 CMDB 紀錄、或釋放固定 IP。同一時間，import 區塊雖然能把子模組內的資源匯入既有基礎設施，但規則要求 import 區塊必須寫在根模組，等於呼叫模組的人得先知道模組內部的資源位址，把模組的實作細節洩漏給了使用者。
核心改動：before_destroy／after_destroy 與模組內 import
Terraform 1.16 新增兩個生命週期事件：before_destroy（資源刪除前執行）與after_destroy（資源刪除後執行），搭配既有的 action_trigger 語法，就能在 lifecycle 區塊內指定觸發時機。失敗處理提供三種模式：預設的 halt 會中止整個 plan，taint 把資源標記為待重建，continue 則忽略錯誤繼續往下跑。HashiCorp 特別註明，觸發條件必須在 plan 階段就「fully known at plan time」，而且規劃銷毀操作時，trigger 設定仍得留在設定檔裡才會生效。
action "example_cleanup" "archive" {
config {
resource_id = caller.id
}
}
resource "example_service" "payments" {
name = "payments"
lifecycle {
action_trigger {
events = [before_destroy]
actions = [action.example_cleanup.archive]
}
}
}import 這邊的改動更直接：import 區塊現在可以直接寫在子模組內部，緊挨著它要匯入的 resource 定義。下面這個範例裡，modules/log-bucket 子模組自己宣告了要匯入哪個 S3 bucket，呼叫端只需要傳一個 bucket 名稱變數，完全不用知道模組內部用的資源型別或本地位址。
variable "existing_bucket_name" {
type = string
}
resource "aws_s3_bucket" "this" {
bucket = var.existing_bucket_name
}
import {
to = aws_s3_bucket.this
id = var.existing_bucket_name
}呼叫端因此只剩極簡的模組呼叫：
module "logs" {
source = "./modules/log-bucket"
existing_bucket_name = "platform-audit-logs"
}這個寫法消除了呼叫端重複模組內部位址的麻煩，也代表模組作者可以把「匯入既有資源」包成模組本身的能力，而不是留給每個使用者各自組出正確的 import target。
影響範圍：誰要動、動什麼
對用 Actions 做外部系統整合的團隊來說，資源刪除終於可以被自動通知到——不用再靠額外的 CI 步驟或人工把 DNS 記錄、防火牆規則、CMDB 條目清乾淨，把清理邏輯寫進 before_destroy 或 after_destroy 的 action_trigger 就好，但要先確認觸發條件在 plan 時就已知，否則銷毀計畫仍可能算不出動作。對維護內部模組庫、要把既有雲端資源收編進 Terraform 管理的團隊，可以重新設計模組介面：把 import 邏輯搬進模組定義，讓呼叫者不用碰觸內部資源位址，大型遷移專案尤其省事。
這個版本也附帶幾個 CLI 端的小改動：terraform state show -json 與 terraform workspace list -json 提供機器可讀輸出，terraform graph -format=mermaid 可以直接產生 Mermaid 圖，HCP Terraform 的 policy evaluation 結果現在也會顯示在 CLI 裡，另外新增了 Linux s390x 的預編譯二進位檔支援。這些屬於周邊工具鏈改善，不影響核心語法，但會影響寫自動化腳本、串 CI 產出圖表的團隊。
值得留意的是失敗模式的選擇本身就是一個維運決策：選 halt 還是 taint 會改變一次銷毀失敗後的復原路徑。用 halt 保守但會卡住整條 pipeline，等於逼團隊人工排查 Action 為什麼失敗；用 taint 則讓 Terraform 把資源標成待重建，下一次 apply 會自動嘗試修復，適合非關鍵性的清理動作；continue 最寬鬆，但也代表清理失敗會被悄悄吞掉，用在真正影響資料一致性的收尾工作（例如資料庫最終備份）上就要特別小心，最好搭配額外的告警而不是單靠 Terraform 自身的錯誤處理。
原始來源：HashiCorp Blog：Terraform 1.16 completes Actions lifecycles and brings imports into child modules