應如何組織Terraform增量更改？

Question

你能幫助我瞭解

比如我有基礎設施的增量變化，像[A] -> [B] -> [C]，其中[A]分別可命名爲i一臺服務器，[B]分別可以被命名j秒服務器，[C]分別可第三臺服務器命名爲k。總共應該有3臺服務器。每個州可以描述爲[A] = x, x + [B] = y, y + [C] = z其中x, y, z是中間的州。

我的問題是

• 如何組織在Terraform多個模塊增量結構的變化，而不會影響前面的模塊？
• 是否有可能回滾鏈中間的變化，例如： [B]並得到x-狀態或者我們應該從最後一個模塊[C]到中間[B]所需的鏈？

Answer 1

此時Terraform只考慮兩種狀態^[1]：「當前狀態」（與在平均時間的任何「漂移」沿着先前Terraform運行的結果）和「期望的狀態」 （在配置中描述）。 Terraform的任務是確定這兩種狀態之間的差異，並確定將資源從當前狀態轉移到所需狀態所需的API動作。

這意味着任何多步轉換都不能在Terraform中單獨編排。在您的示例中，要添加服務器j，您可以將其單獨添加到Terraform配置中，然後運行Terraform來創建該服務器。然後，您可以將服務器k添加到配置中，然後再次運行Terraform。爲了自動執行此操作，需要一個外部過程來生成這些漸進式配置更改。

另一種方法 - 儘管不推薦用於日常使用，因爲它可能導致在其他人無法輕易看到這種狀態如何達到的協作環境中產生混淆 - 是使用-target參數來指定一個或多個具體資源進行操作。原則上，這允許將兩個服務器j和k添加到配置，但是然後使用-target僅具有代表j的資源。

在Terraform中沒有對回滾的正式支持。 Terraform認爲這是另一個國家轉型，「向前滾動」。例如，如果在創建服務器k後，希望恢復到狀態[A]，則可以刪除服務器k的配置（可能通過在版本控制中恢復）並重新應用。 Terraform並沒有意識到這是一個「回滾」的事實，但它可以看到該配置不再包含服務器k，因此知道它需要被銷燬以達到所需的狀態。

你的問題之一是關於「影響以前的模塊」。一般來說，如果您的配置中沒有對資源進行任何更改（配置發生變化，或資源本身在Terraform的權限範圍之外更改），則Terraform不應嘗試更新它。如果確實如此，那將被認爲是一個錯誤。但是，對於較大的系統，可以將基礎架構跨多個分別單獨應用的頂級Terraform配置進行分割。如果遠程後端正在使用（建議用於協作環境），則可以使用the terraform_remote_state data source從另一個配置中訪問一個配置的輸出值，從而允許創建Terraform配置的樹或DAG。這增加了複雜性，因此應該仔細權衡，但是通過完全不考慮不相關的資源而具有降低特定變化的「爆炸半徑」的優點。

---

[1]我使用「狀態」在這裏你使用它的一般意義上，這是從「狀態」 Terraform的物理思想，包含其中存在的資源記錄一個數據文件中的不同在最後一次運行。