保護 Terraform 狀態：遠端後端與 CI/CD 自動化整合

– 7 分鐘閱讀

在企業級基礎設施即代碼（IaC）實踐中，狀態文件的一致性與安全性是自動化部署的基石。本地儲存不僅阻礙團隊協作，更帶來敏感資訊洩露的風險，因此採用遠端後端成為必然選擇。本文闡述遠端後端如何透過集中式儲存機制解決這些挑戰，並以 Azure 為例，展示從建立儲存資源到整合 Terraform 配置的完整流程，為團隊提供一套安全、可擴展的狀態管理方案，實現高效的 CI/CD 整合。

Terraform 狀態管理：遠端後端保護與 CI/CD 自動化

本章節將深入探討 Terraform 的狀態文件 (.tfstate) 的重要性及其在企業級應用中的挑戰。內容將重點介紹為何不應將狀態文件儲存在本地，以及如何透過配置遠端後端（Remote Backend）來解決這些問題，確保狀態文件的安全性、可訪問性和一致性。同時，我們也將回顧 Terraform 在 CI/CD 流程中的自動化執行選項，包括如何使用 --auto-approve 和輸出文件來實現無人值守的部署。

Terraform 狀態文件的挑戰與遠端後端解決方案

Terraform 的狀態文件（terraform.tfstate）是其核心組件之一，它記錄了 Terraform 管理的基礎設施的當前狀態，包括資源的映射關係、屬性以及元數據。這個文件對於 Terraform 的正常運行至關重要。

本地狀態文件的局限性

在本地開發環境中，Terraform 默認將狀態文件保存在工作目錄下。然而，這種本地存儲方式在企業級應用中存在顯著的局限性：

  • 不可刪除性: 狀態文件一旦被創建，就不應被刪除或損壞。若狀態文件丟失，Terraform 將無法準確追蹤和管理現有基礎設施，可能導致意外的資源創建或修改。
  • 協作訪問限制: 在團隊協作環境中，多個開發人員需要同時訪問和更新狀態文件。本地存儲無法滿足這種並發訪問的需求，容易導致狀態衝突。
  • 安全性風險: 狀態文件可能包含敏感信息，如資源的訪問憑證或私有 IP 地址。本地存儲增加了這些敏感信息洩露的風險。
  • 多環境管理複雜性: 當需要管理多個獨立的環境（如開發、測試、生產）時，本地存儲多個狀態文件變得複雜且容易混淆。
配置遠端後端 (Remote Backend)

為了克服本地狀態文件的種種弊端，Terraform 提供了「遠端後端」的機制。遠端後端允許將狀態文件存儲在一個集中的、共享的、安全的儲存位置，例如雲端儲存服務。

Terraform 支持多種類型的遠端後端，包括但不限於：

  • AWS S3
  • Azure Blob Storage
  • Google Cloud Storage
  • Terraform Cloud

在本次探討的 Azure 環境中，我們將使用 Azure Blob Storage 作為遠端後端，將狀態文件儲存在一個指定的儲存帳戶和容器中。

配置遠端後端通常涉及以下三個步驟：

  1. 創建儲存資源: 在 Azure 中創建一個儲存帳戶 (Storage Account) 和一個 Blob 容器 (Blob Container)，用於存放 Terraform 的狀態文件。
  2. 配置 Terraform 後端: 在 Terraform 的配置代碼中，添加 backend 區塊，指定後端的類型（例如 azurerm）以及儲存帳戶、容器名稱等連接資訊。
  3. 初始化並遷移狀態: 執行 terraform init 命令。Terraform 會自動檢測到後端配置，並提示您將本地狀態文件遷移到遠端後端。之後，所有 Terraform 操作都會與遠端後端進行交互。

透過配置遠端後端，我們可以確保狀態文件的安全、一致性和可訪問性，極大地提升了 Terraform 在企業級應用中的可靠性和協作效率。

CI/CD 中的 Terraform 自動化選項

在 CI/CD 流程中，為了實現無人值守的自動化部署，Terraform 提供了一些實用的選項：

使用 --auto-approve 執行應用

在 CI/CD 管道中，我們通常不希望 Terraform 在執行 apply 命令時等待用戶的手動確認。--auto-approve 選項可以跳過這個確認步驟，讓 Terraform 自動應用變更。

terraform apply --auto-approve

將此命令集成到 CI/CD 腳本中，可以實現完全自動化的基礎設施部署。

使用輸出文件 (-out)

為了進一步增強部署的控制力和可回溯性，terraform plan 命令可以將生成的執行計劃保存到一個文件中，通常使用 .tfplan 擴展名。

terraform plan -out=main.tfplan

然後，terraform apply 命令可以引用這個計劃文件來執行變更：

terraform apply "main.tfplan"

這種做法的好處在於：

  • 分離計劃與應用: 允許在生成計劃後，經過審查或在不同的時間點執行應用。
  • 確保一致性: 確保 apply 命令執行的是與 plan 命令生成時完全相同的變更集。
  • 潛在的回滾: 雖然 Terraform 本身沒有直接的回滾機制，但通過保存計劃文件，可以在需要時分析和理解已執行的變更。

透過結合遠端後端管理狀態文件，以及在 CI/CD 流程中使用自動化選項，我們可以構建一個強健、安全且高效的基礎設施即代碼 (IaC) 工作流程。

Azure 遠端後端配置實踐：儲存帳戶與 Terraform 整合

本章節將提供一個具體的實踐指南，說明如何在 Azure 環境中創建必要的儲存資源，並將 Terraform 配置為使用這些資源作為遠端後端。內容將詳細介紹使用 Azure CLI 腳本創建儲存帳戶和 Blob 容器的步驟，以及如何在 Terraform 的配置文件中聲明遠端後端設置，確保狀態文件的安全與協作。

步驟一：在 Azure 中創建遠端後端儲存資源

為了將 Terraform 的狀態文件安全地存儲在雲端，我們首先需要在 Azure 中創建一個儲存帳戶和一個 Blob 容器。這可以透過 Azure 入口網站或 Azure CLI 腳本來完成。為了實現自動化和可重複性，推薦使用 Azure CLI 腳本。

以下是一個使用 Azure CLI 創建所需資源的範例腳本：

  1. 創建資源群組: 首先，創建一個專門用於存放 Terraform 後端儲存的資源群組。

    az group create --name MyTerraformBackendRg --location westeurope

    此命令會在指定的區域（westeurope）創建一個名為 MyTerraformBackendRg 的資源群組。

  2. 創建儲存帳戶: 接下來，創建一個儲存帳戶。儲存帳戶名稱必須是全局唯一的。我們將使用 Standard_LRS SKU，並啟用 Blob 加密。

    az storage account create --resource-group MyTerraformBackendRg --name storagetfbackendunique --sku Standard_LRS --encryption-services blob

    請注意，storagetfbackendunique 是一個範例名稱，您需要替換為一個在 Azure 中尚未被使用的唯一名稱。

  3. 獲取儲存帳戶金鑰: 為了訪問儲存帳戶中的 Blob 容器，我們需要獲取其存取金鑰。

    STORAGE_ACCOUNT_KEY=$(az storage account keys list --resource-group MyTerraformBackendRg --account-name storagetfbackendunique --query "[0].value" -o tsv)

    此命令會將第一個儲存帳戶金鑰的值賦予 STORAGE_ACCOUNT_KEY 環境變數。

  4. 創建 Blob 容器: 最後，在儲存帳戶中創建一個 Blob 容器，用於存放 Terraform 的狀態文件。

    az storage container create --name tfstate-container --account-name storagetfbackendunique --account-key $STORAGE_ACCOUNT_KEY

    此命令會在名為 storagetfbackendunique 的儲存帳戶中創建一個名為 tfstate-container 的 Blob 容器。

這個腳本可以直接在 Azure Cloud Shell 或任何安裝了 Azure CLI 的環境中執行。將其整合到 CI/CD 流程中，可以確保每次部署前都具備一個乾淨、可用的遠端後端儲存。

步驟二：在 Terraform 配置中聲明遠端後端

在 Azure 中創建了必要的儲存資源後，我們需要修改 Terraform 的配置文件，告知 Terraform 使用這些遠端資源來管理狀態文件。這通常在 Terraform 項目的根目錄下的 main.tf 或一個專門的 backend.tf 文件中完成。

在 Terraform 配置中添加以下 terraform 區塊：

terraform {
  backend "azurerm" {
    resource_group_name  = "MyTerraformBackendRg"
    storage_account_name = "storagetfbackendunique"
    container_name       = "tfstate-container"
    key                  = "myapp/production/terraform.tfstate"
    snapshot             = true
  }
}

在此配置中：

  • backend "azurerm": 指定我們使用的是 AzureRM 後端。
  • resource_group_name: 指向您在步驟一中創建的資源群組名稱。
  • storage_account_name: 指向您在步驟一中創建的儲存帳戶名稱。
  • container_name: 指向您在步驟一中創建的 Blob 容器名稱。
  • key: 指定狀態文件在 Blob 容器中的路徑和名稱。建議使用具有層級結構的路徑，以便管理多個環境或項目的狀態文件。例如，myapp/production/terraform.tfstate 表示這是 myapp 項目在 production 環境下的狀態文件。
  • snapshot = true: 這個選項（如果支持）可以啟用狀態文件的快照功能，提供額外的備份保障。

完成此配置後，當您第一次執行 terraform init 命令時，Terraform 會檢測到這個後端配置，並提示您將現有的本地狀態文件（如果有的話）遷移到 Azure Blob Storage 中。之後，所有的 Terraform 操作（plan, apply, destroy）都會自動與這個遠端後端進行交互，確保狀態文件的安全和一致性。

縱觀現代化基礎設施即代碼（IaC）實踐，遠端狀態管理不僅是技術選項，更是團隊協作與風險控管成熟度的關鍵指標。將狀態文件從本地孤島移轉至遠端後端，其價值遠不止於共享存取；它與 CI/CD 流程中計畫與應用的分離機制相結合，構建了一套可審計、可預測的交付系統。然而，這也意味著後端儲存的存取權限與生命週期管理，將升級為新的資安治理核心，其重要性不亞於程式碼本身。

未來，狀態管理勢必與策略即代碼（Policy-as-Code）等機制深度整合，讓每一次基礎設施變更，都在合規與成本框架內自動驗證。因此，對於追求卓越工程文化的團隊而言，將狀態管理制度化，是從「能用」邁向「可靠」的關鍵躍升，其長期戰略價值遠遠超過初期的建置成本。

玄貓 BlackCat

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。