Terraform 是管理基礎設施及代碼（IaC）最常用的工具之一，它能使我們安全且可預測地對基礎設施應用更改。剛開始上手 Terraform 可能會感覺有些不容易，但很快就能對該工具有基本的了解，隨之可以開始運行命令、創(chuàng)建和重構 Terraform 代碼。在此過程中，許多新用戶面臨著如何正確構建代碼、使用高級功能、在 IaC 流程中應用軟件開發(fā)最佳實踐等方面的細微差別和問題。
?

在本篇文章中，我們將討論使用 Terraform 管理 IaC 的最佳實踐，幫助您將 Terraform 技能提升到一個新的水平。點擊Seal博客可閱讀更多關于 Terraform 的技術文章。
?

如何構建 Terraform 項目

在開始討論 Terraform 的一些最佳實踐之前，我們先來看看構建 Terraform 項目的一些策略。在 Terraform 的世界中，構建配置的方式沒有正確或錯誤之分，而且您在網上找到的大多數建議結構都帶有很大的主觀色彩。在決定如何設置 Terraform 配置時，最重要的是了解您的基礎設施需求和用例，并制定適合您的團隊和項目的解決方案。
?

如果我們正在處理一個基礎設施組件有限的小型項目，那么保持 Terraform 配置盡可能是比較合適的方式。在這類情況下，我們可以只配置根模塊必需的文件，即根目錄中存在的配置文件。一個小項目可以只包含這些文件main.tf、variables.tf、README.md。您可能會發(fā)現方便使用的其他一些文件包括：outputs.tf（用于定義項目的輸出值）、versions.tf（用于收集配置的任何固定版本）以及providers.tf配置與您使用的提供商相關的選項，尤其是在有多個提供商的情況下。
?

我們的主要入口點是main.tf，在簡單的用例中，我們可以在那里添加所有資源。我們在variables.tf中定義變量，并在terraform.tfvars中為它們賦值。我們使用文件outputs.tf來聲明輸出值。

當處理較大的項目時，會更加復雜，我們需要找出適合項目的最佳結構。
?

首先將 Terraform 代碼分解為可重用的組件，不同的團隊可以相應地使用和定制。我們可以通過為基礎設施部分創(chuàng)建單獨的模塊來實現這一點，這些模塊應該在不同的環(huán)境、項目和團隊中重用。
?

常見的做法是根據所有權和責任、變更率和管理難易程度來分離模塊。對于每個模塊，我們需要定義其輸入和輸出并徹底記錄它們，以便使用者能夠有效地使用它們。然后，我們可以利用outputs和terraform_remote_state來跨模塊甚至不同 Terraform 狀態(tài)引用值。
?

請注意，使用terraform_remote_state數據源意味著訪問整個狀態(tài)快照，這可能會引發(fā)安全問題。在不同狀態(tài)之間共享參數的另一種選擇是利用外部工具 [1] 來發(fā)布和使用數據，例如 Amazon SSM Parameter Store 或 HashiCorp Consul。
?

接下來需要決定將所有 Terraform 代碼保留在單個存儲庫 ( monorepo ) 中，或是將 Terraform 配置分離到多個代碼存儲庫中。這兩種方法都有缺點和優(yōu)點。目前有一種趨勢，即避免巨大的單一存儲庫并使用單獨的配置來實現更快的模塊開發(fā)和靈活性。
?

通常，我們必須處理大量不同的基礎設施環(huán)境，而 Terraform 中有多種方法可以處理這個問題。一個合適且容易遵循的做法是為不同的環(huán)境單獨配置 Terraform。這樣不同的環(huán)境就有自己的狀態(tài)，可以單獨測試和管理，而共享行為則通過共享或遠程模塊實現。一種選擇是每個環(huán)境使用單獨的目錄，并為每個目錄保留單獨的狀態(tài)。另一種選擇是將所有 Terraform 配置保留在同一目錄中，并為每個環(huán)境傳遞不同的環(huán)境變量以相應地參數化配置。
?

這里您可以找到每個目錄的三個不同環(huán)境的示例結構：生產、staging?和測試。每個環(huán)境都有自己的狀態(tài)，并在利用公共或共享模塊的同時與其他環(huán)境分開管理。盡管這種方法會帶來一些代碼重復，但我們獲得了更高的清晰度、環(huán)境隔離和可擴展性。
?

一般來說，我們希望為特定所有者定義具有有限范圍和爆炸半徑的 Terraform 配置。為了最大限度地降低風險，我們應該嘗試將項目分解為小型工作區(qū)/堆棧，并使用基于角色的訪問控制（RBAC）對它們進行分段訪問。
?

Terraform 最佳實踐

在前面的部分中，我們討論了一些通用的 IaC 最佳實踐。我們根據組織結構和需求探索了一些優(yōu)化 Terraform 代碼的選項。這里我們將深入研究將 Terraform 代碼提升到新水平的具體要點，希望能夠為你和你的團隊提供有關實驗、研究和實施對您的用例有意義的實踐的提示和指導。
?

使用遠程狀態(tài)

在去做一些嘗試和試驗的時候使用本地狀態(tài)是可以的，高于此情況的內容都可以使用遠程共享狀態(tài)位置。為狀態(tài)使用遠程后端是您在團隊中工作時應該采用的首要最佳實踐之一。選擇一個支持狀態(tài)鎖定的選項，以避免多人同時更改狀態(tài)。將狀態(tài)視為不可變，避免手動狀態(tài)更改。確保有狀態(tài)備份，以便在發(fā)生災難時可以使用。對于某些后端（例如 AWS S3），可以啟用版本控制以實現快速輕松的狀態(tài)恢復。
?

使用現有的共享和社區(qū)模塊

檢查是否已經有合適的用例的模塊，避免自己編寫所需模塊重復造輪子，這樣就能節(jié)省許多時間。您可以檢查 Terraform Registry [2] 以獲取可用模塊。Terraform 擁有龐大成熟的社區(qū)，用戶還可以借助社區(qū)的力量解決問題。熱心的用戶也可以通過改進社區(qū)或報告問題來幫助社區(qū)。
?

導入現有基礎設施

如果您接手了一個已有幾年歷史的項目，那么其基礎設施的某些部分很可能是手動創(chuàng)建的。不用擔心，您可以將現有基礎設施導入Terraform 并避免從多個端點管理基礎設施。
?

避免變量硬編碼

請盡量避免對變量進行硬編碼。想一想，將您直接分配的值定義為變量對將來的更改是否更有意義。更重要的是，確認是否可以在不進行顯式設置的情況下通過數據源獲取屬性值。例如，不要從控制臺查找 AWS 賬戶 ID 并將其在terraform.tfvars中設置為：

aws_account_id=”99999999999”

?

我們可以從數據源中獲取賬戶 ID。

data "aws_caller_identity" "current" {}locals { ? ?account_id = data.aws_caller_identity.current.account_id}

?

始終格式化并驗證

在 IaC 中長期一致性至關重要，Terraform 為我們提供了一些工具來幫助我們實現這一目標。請記住運行用terraform fmt和 用terraform validate以正確格式化代碼并捕獲錯過的任何問題。理想情況下應該通過 CI/CD 流水線或 pre-commit hook 自動完成。
?

使用一致的命名規(guī)則

我們可以在網上找到許多有關 Terraform 代碼命名規(guī)則的建議。最重要的不是規(guī)則本身，而是找到您的團隊熟悉的規(guī)則，并共同努力使其保持一致。請參閱以下易于遵循的規(guī)則列表：

• 在名稱中使用下劃線_作為分隔符并使用小寫字母。

• 資源名稱中盡量不要重復資源類型。

• 對于單值變量和屬性，請使用單數名詞。對于列表或地圖，使用復數名詞來表明它代表多個值。

• 始終對變量和輸出使用描述性名稱，并記住包含說明。
  ?

在下一部分，我們將繼續(xù)探討更多使用 Terraform 管理 IaC 的最佳實踐。
?

原文鏈接：
https://spacelift.io/blog/terraform-best-practices

參考鏈接：
1.https://developer.hashicorp.com/terraform/language/state/remote-state-data#alternative-ways-to-share-data-between-configurations

2.https://registry.terraform.io/browse/modules

?