terraform 提供者中 map 全球資源的最佳方法

Question

我正在為軟件編寫 terraform 提供程序，該軟件具有大量特定於實例的全局配置。 使用提供程序時，您定義端點和憑證，然后在此實例中操作。 我正在努力決定的是如何准確地管理這個配置。 它不是創建或銷毀的資源，所以我不確定創建global_config資源是否是最好的方法。 由於所有值在系統設置期間都已經初始化並且只能被覆蓋； 配置不能被破壞； 您不能擁有兩個以上的配置資源。 由於您應該能夠覆蓋所有條目，因此它也不能是數據源。

到目前為止，我還沒有找到任何相關的文檔（甚至類似的例子），所以如果有人能指出任何相關的東西，或者建議如何最好地實現這一點，我將不勝感激。 謝謝。

Answer 1

Terraform 的提供者 model 主要設計用於 Terraform 本身可以創建或銷毀的對象。 There is no built-in support for automatically "adopting" an existing object to be under Terraform's management, because Terraform generally assumes that each object is managed by exactly one declared resource instance and Terraform aims to preserve that assumption by being the one to have created object。

但是，這種“單例”object 的其他系統中存在一些現有示例，它是隱式創建的，但可以更改其設置。 研究的關鍵示例是默認 VPC 的資源類型及其在 AWS 中的默認公有子網。

目前在 Terraform 中有兩種廣泛的方式來表示這種情況，這兩種方式都不是完美的，因此每種方式都有一些優點和缺點需要考慮：

• 強制terraform import ：您可以潛在地構建您的資源類型，以便其“創建”操作總是立即失敗，告訴用戶導入現有的 object，然后實施“導入”操作以允許用戶顯式地將他們現有的 ZA8CFDE6331BD59EB2AC96F8 綁定到他們的Terraform 資源實例使用terraform import命令。

  這是兩個選項中更明確的一個，因為它要求用戶有意聲明現有 object 應由此 Terraform 配置管理，就像用戶通常在 Z303E96F80576360D0C7B07AE7 中執行該操作一樣。 這意味着用戶仍然可以控制並且可以（正如他們在導入時必須始終做的那樣）小心地將 object 導入到一個 Terraform 配置中的一個資源實例中，從而保留 Terraform 的唯一性假設。

  但是，它還向使用此資源類型的任何 Terraform 配置添加了一個強制性的額外設置步驟。 這個額外的步驟不太適合Terraform 周圍的典型自動化，因此通常需要以團隊正常工作流程之外的特殊方式采取該步驟。

• 將“創建”視為“采用” ：由於預期提供者為資源類型實施的操作只是一個事項約定，因此您的“創建”操作不能僅驗證配置的 object 存在並且沒有技術原因在不創建任何內容的情況下返回成功。 我在這里稱其為“采用”是為了表示 Terraform 將假設這個現有的 object 現在處於聲稱創建它的任何資源實例的獨家管理之下，但“采用”實際上並不是 Terraform 工作流程的正式部分。

  這樣做的好處是可以很好地適應現有的 Terraform 工作流程，操作員不需要額外的異常步驟。

  然而，這也意味着更容易將相同的 object 意外地采用到兩個不同的資源實例中，無論是在相同的配置中還是在不同的配置中。 這樣做的后果會因 object 所代表的內容而異，但至少它可能會導致不同的資源實例相互“爭斗”，不斷撤消彼此在每個新的 Terraform 運行上的工作，因此永遠不會收斂到一個穩定的期望state。

其中第二個是兩者中更方便的一個，現有提供商通常選擇的一個也是如此，只要不正確的多次采用的后果只是非融合系統的風險：這種情況令人困惑且有點煩人，但也往往不是超級有害的。

第一個是兩者中更安全的一個，因為它可以防止意外的多次采用問題。 如果兩個配置爭奪控制單個 object 可能會產生更嚴重的后果，例如一個配置通過以對另一個用例無效的方式更改其設置來破壞另一個配置，這可能是合適的。