20個有效實踐提升Terraform工作流程|Part 1

Seal數澈發表於2023-09-18

Terraform 是管理基礎設施及程式碼(IaC)最常用的工具之一,它能使我們安全且可預測地對基礎設施應用更改。剛開始上手 Terraform 可能會感覺有些不容易,但很快就能對該工具有基本的瞭解,隨之可以開始執行命令、建立和重構 Terraform 程式碼。在此過程中,許多新使用者面臨著如何正確構建程式碼、使用有效功能、在 IaC 流程中應用軟體開發有效實踐等方面的細微差別和問題。
 

在本篇文章中,我們將討論使用 Terraform 管理 IaC 的 有效實踐,幫助您將 Terraform 技能提升到一個新的水平。 點選Seal部落格可閱讀更多關於 Terraform 的技術文章
 

如何構建 Terraform 專案

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

如果我們正在處理一個基礎設施元件有限的小型專案,那麼保持 Terraform 配置儘可能是比較合適的方式。在這類情況下,我們可以只配置根模組必需的檔案,即根目錄中存在的配置檔案。一個小專案可以只包含這些檔案 main.tfvariables.tfREADME.md。您可能會發現方便使用的其他一些檔案包括: outputs.tf(用於定義專案的輸出值)、 versions.tf(用於 收集配置的任何固定版本)以及providers.tf配置與您使用的提供商相關的選項,尤其是在有多個提供商的情況下。
 

我們的主要入口點是 main.tf,在簡單的用例中,我們可以在那裡新增所有資源。我們在 variables.tf中定義變數,並在 terraform.tfvars中為它們賦值。我們使用檔案 outputs.tf來宣告輸出值。
 


 

當處理較大的專案時,會更加複雜,我們需要找出適合專案的 有效結構。
 

首先 將 Terraform 程式碼分解為可重用的元件,不同的團隊可以相應地使用和定製。我們可以透過為基礎設施部分建立單獨的模組來實現這一點,這些模組應該在不同的環境、專案和團隊中重用。
 

常見的做法是根據所有權和責任、變更率和管理難易程度來分離模組。對於每個模組,我們需要定義其輸入和輸出並徹底記錄它們,以便使用者能夠有效地使用它們。然後,我們可以利用 outputsterraform_remote_state來跨模組甚至不同 Terraform 狀態引用值。
 

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

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

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

這裡您可以找到每個目錄的三個不同環境的示例結構: 生產staging 和 測試。每個環境都有自己的狀態,並在利用公共或共享模組的同時與其他環境分開管理。儘管這種方法會帶來一些程式碼重複,但我們獲得了更高的清晰度、環境隔離和可擴充套件性。
 


 

一般來說,我們希望為特定所有者定義具有有限範圍和爆炸半徑的 Terraform 配置。為了最大限度地降低風險,我們應該嘗試將專案分解為小型工作區/堆疊,並使用基於角色的訪問控制(RBAC)對它們進行分段訪問。
 

Terraform 有效實踐

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

使用遠端狀態

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

使用現有的共享和社群模組

檢查是否已經有合適的用例的模組,避免自己編寫所需模組重複造輪子,這樣就能節省許多時間。您可以檢查 Terraform Registry [2] 以獲取可用模組。Terraform 擁有龐大成熟的社群,使用者還可以藉助社群的力量解決問題。熱心的使用者也可以透過改進社群或報告問題來幫助社群。
 

匯入現有基礎設施

如果您接手了一個已有幾年歷史的專案,那麼其基礎設施的某些部分很可能是手動建立的。不用擔心,您可以將現有基礎設施匯入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 自動完成。
 

使用一致的命名規則

我們可以在網上找到許多有關 Terraform 程式碼命名規則的建議。最重要的不是規則本身,而是 找到您的團隊熟悉的規則,並共同努力使其保持一致。請參閱以下易於遵循的規則列表:

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

  • 資源名稱中儘量不要重複資源型別。

  • 對於單值變數和屬性,請使用單數名詞。對於列表或地圖,使用複數名詞來表明它代表多個值。

  • 始終對變數和輸出使用描述性名稱,並記住包含說明。
     

在下一部分,我們將繼續探討更多使用 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.

 


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70026925/viewspace-2984036/,如需轉載,請註明出處,否則將追究法律責任。

相關文章