優化 Terraform 配置：代碼結構、變數與敏感資料管理

– 7 分鐘閱讀

在採用 Terraform 進行基礎設施自動化時，初期的腳本編寫往往著重於功能實現。然而，隨著專案規模擴大與團隊協作需求增加，代碼的長期維護成本與潛在風險便會浮現。一套缺乏結構、將敏感資訊寫死、且充滿重複配置的代碼，將成為技術債務的溫床，不僅拖累開發效率，更可能引發安全漏洞。因此，掌握系統性的編寫慣例至關重要。本文將從實務角度出發，說明如何將單一的 Terraform 腳本，逐步重構成易於管理、安全可靠且具備高度彈性的模組化配置，為企業級雲端環境管理奠定穩固基礎。

Terraform 最佳實踐：代碼組織、敏感數據保護與配置動態化

本章節將探討 Terraform 編寫中的重要最佳實踐，旨在提升代碼的可讀性、可維護性及安全性。內容將涵蓋如何透過文件分離來優化代碼結構，如何妥善保護敏感資訊，以及如何利用變數和內建函數來實現配置的動態化，從而提高代碼的靈活性和重用性。

實踐 Terraform 的良好編寫習慣

在成功編寫了一個能夠部署基礎 Azure 基礎設施的 Terraform 腳本後，我們需要關注代碼的組織、可讀性及安全性，這對於長期項目維護至關重要。

透過文件分離提升代碼可讀性

Terraform 會自動讀取執行目錄下所有 .tf 擴展名的文件。雖然在小型項目中將所有配置放在一個文件中（如 provider.tf 和 main.tf）是可行的，但隨著項目規模的擴大，將代碼劃分為多個文件能夠顯著提升可讀性和可維護性。

以我們之前的示例腳本為例，可以進行以下文件結構的優化：

  • rg.tf: 專門用於定義資源群組的相關代碼。
  • network.tf: 包含虛擬網絡 (VNet) 和子網 (Subnet) 的定義。
  • compute.tf: 集中管理網絡接口 (NIC)、公共 IP 地址、存儲賬戶（用於診斷）以及虛擬機器的代碼。

這種文件分離的策略，使得每個文件只關注特定類型的資源，讓開發者能夠更快速地定位和修改相關配置。

保護敏感數據

在 Terraform 配置中處理敏感數據，如密碼、訪問權限等，需要格外謹慎。我們之前已討論過，Azure 服務主體的身份驗證資訊不應直接寫入配置文件，而是透過環境變數傳遞。

對於虛擬機器的管理員帳戶密碼，直接在 Terraform 配置中明文指定是極不安全的做法。為了解決這個問題，建議採取以下方法：

  • 使用秘密管理服務: 整合 Azure Key Vault 或 HashiCorp Vault 等專門的秘密管理工具。Terraform 可以透過相應的提供者（Provider）與這些服務進行集成，安全地獲取和使用敏感憑證。
  • SSH 金鑰驗證: 對於 Linux 虛擬機器，優先使用 SSH 金鑰對進行身份驗證，而非明文密碼。Terraform 可以配置讀取本地 SSH 公鑰文件，並將其部署到虛擬機器上。

利用變數和函數實現配置的動態化

在實際應用中，託管應用程式的基礎設施通常在不同環境（如開發、測試、生產）之間具有相似性，但某些參數（如資源名稱、實例數量）會有所不同。為了讓 Terraform 代碼更具靈活性和可重用性，我們應該利用變數和內建函數。

聲明變數

變數允許我們將配置中的參數化值提取出來，以便在需要時輕鬆修改。變數可以在 Terraform 配置的任何地方聲明，但為了更好的組織，通常會將其集中定義在一個單獨的文件中，例如 variables.tf。

以下是一個變數聲明的示例：

variable "resource_group_name" {
  description = "指定資源群組的名稱"
  type        = string # 聲明變數類型為字串
  default     = "my-default-rg" # 可選：設置預設值
}

在這個變數聲明中：

  • variable "resource_group_name": 定義了一個名為 resource_group_name 的變數。
  • description: 提供對變數用途的簡要說明。
  • type: 指定變數的數據類型，例如 string（字串）、number（數字）、bool（布爾值）或 list（列表）等。
  • default: （可選）為變數設置一個預設值。如果在使用時未提供具體值，則會使用此預設值。

透過這種方式，我們可以在資源定義中使用此變數，例如：

resource "azurerm_resource_group" "rg" {
  name     = var.resource_group_name # 使用變數
  location = "West Europe"
  tags = {
    environment = "Terraform Azure"
  }
}

當 Terraform 執行時，它會查找 var.resource_group_name 的值。這個值可以透過多種方式提供，包括：

  • 在 variables.tf 文件中設置 default 值。
  • 透過命令行參數傳遞（例如 terraform apply -var="resource_group_name=my-prod-rg"）。
  • 使用 Terraform 變數文件（例如 terraform.tfvars）。
  • 透過環境變數傳遞。

Terraform 實戰：變數與函數應用，以及部署流程啟動

本章節將深入探討如何在 Terraform 配置中使用變數，並結合內建函數來實現配置的動態化與靈活性。我們將展示如何聲明變數、在 .tfvars 文件中賦值，以及如何在資源定義中使用這些變數。此外，本章節也將正式進入 Terraform 的部署階段，介紹如何準備 Azure 認證，為後續的基礎設施部署流程奠定基礎。

變數的聲明與應用

變數是 Terraform 中實現配置參數化的核心機制，它使得我們的代碼能夠適應不同的環境和需求。

聲明更多變數

除了資源群組名稱，我們還可以聲明其他常用的配置參數作為變數：

variable "location" {
  description = "資源部署的地理位置"
  type        = string
  default     = "West Europe" # 預設部署在西歐地區
}

variable "application_name" {
  description = "應用程式的名稱，用於資源命名與標籤"
  type        = string
}
  • variable "location": 定義了部署位置的變數，並設置了預設值 West Europe。
  • variable "application_name": 定義了應用程式名稱的變數，這通常用於為創建的資源添加命名規範或標籤，以便於識別和管理。
使用 .tfvars 文件賦值

為了方便管理和覆蓋預設值，我們可以創建一個名為 terraform.tfvars 的文件，並在其中為變數賦值。Terraform 會自動載入此文件。

# terraform.tfvars 文件內容
resource_group_name = "bookRg"
application_name    = "book"
# location            = "East US" # 可選：覆蓋預設的 location 值

在這個文件中，我們使用 變數名稱 = 值 的語法為之前聲明的變數提供了具體的值。例如，resource_group_name 被設置為 "bookRg"，application_name 被設置為 "book"。如果我們想將資源部署到其他地區，可以取消 location 的註釋並指定新的值。

在資源代碼中使用變數

一旦變數被聲明並賦值，我們就可以在資源塊中使用 var.<變數名稱> 的語法來引用它們。

例如，更新資源群組的定義：

resource "azurerm_resource_group" "rg" {
  name     = var.resource_group_name # 使用變數指定的名稱
  location = var.location            # 使用變數指定的地理位置

  tags = {
    environment = "Terraform Azure"
    application = var.application_name # 使用應用程式名稱變數
  }
}

通過這種方式，我們可以輕鬆地修改 terraform.tfvars 文件來更改資源群組的名稱、部署位置或應用程式名稱，而無需修改核心的資源定義代碼。

運用 Terraform 內建函數

Terraform 提供了一系列強大的內建函數，用於處理字符串、數字、列表、映射以及進行邏輯判斷等操作。這些函數極大地增強了 Terraform 配置的表達能力和靈活性。例如，join() 函數可以將列表中的元素合併為一個字符串，format() 函數可以格式化字符串，lookup() 函數可以在映射中查找值。熟練運用這些函數，可以幫助我們編寫出更簡潔、更強大的 Terraform 代碼。

啟動 Terraform 部署流程

在完成了 Terraform 配置的編寫、代碼結構的優化以及敏感數據的保護後，我們就進入了實際部署基礎設施的階段。

準備 Azure 認證

在 Terraform 能夠管理 Azure 資源之前，必須先建立與 Azure 的連接並進行身份驗證。這通常通過以下方式實現：

  1. 設置環境變數: 為 Terraform 提供 Azure 服務主體的認證資訊。這包括 ARM_CLIENT_ID、ARM_CLIENT_SECRET、ARM_SUBSCRIPTION_ID 和 ARM_TENANT_ID 等環境變數。Terraform 的 Azure 提供者會自動讀取這些變數來進行身份驗證。
  2. 使用 Azure CLI 登錄: 如果您已經在本地安裝並配置了 Azure CLI，可以直接執行 az login 命令進行交互式登錄。Terraform 可以利用當前 Azure CLI 的登錄會話進行身份驗證。

選擇哪種認證方式取決於您的部署環境和安全策略。在自動化部署場景（如 CI/CD 流水線）中，通常會選擇設置環境變數的方式。

好的，這是一篇根據您提供的 Terraform 最佳實踐文章內容，並遵循「玄貓風格高階管理者個人與職場發展文章結論撰寫系統」所撰寫的結論。

結論

縱觀基礎設施即代碼（IaC）的演進，Terraform 的價值不僅在於自動化部署，更體現於其工程化實踐的深度。從單一文件的簡易配置，走向模組化的文件分離與動態化的變數管理，這不僅是代碼組織的優化，更是思維模式的躍升——從一次性的「腳本思維」，轉向可持續維護的「系統工程思維」。此過程中的關鍵挑戰，在於如何抵禦專案時程壓力下回歸硬編碼與明文密碼的誘惑。將敏感資訊管理（如整合 Key Vault 或採用 SSH 金鑰）內化為開發流程的預設環節，是跨越業餘與專業分水嶺的核心指標。

展望未來，隨著雲原生架構日趨複雜，Terraform 配置的品質將直接決定維運成本與安全韌性。熟練運用變數、函數與安全實踐，將不再是資深工程師的加分項，而是評估雲端團隊專業成熟度的基礎門檻。

綜合評估後，這套方法論已不僅是「最佳實踐」，而是現代雲端基礎設施管理的「標準作業程序」。對於追求高效能與高安全性的技術團隊而言，將其視為專案啟動時的設計規範，而非日後重構的技術債，才能真正釋放 IaC 的長期價值。

玄貓

玄貓

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