整合 Packer 與 Terraform 實現端對端自動化部署

– 7 分鐘閱讀

在現代雲端維運與 DevOps 實踐中，基礎設施即程式碼（IaC）是確保效率、可重複性與穩定性的基石。其中，Packer 與 Terraform 的整合代表了一種成熟的自動化部署模式。Packer 專注於「映像烘焙」（Image Baking），將作業系統、應用程式與組態設定預先封裝成標準化的虛擬機映像，建立所謂的「黃金映像」（Golden Image）。而 Terraform 則接手後續的資源編排任務，以宣告式語法定義並部署包含網路、儲存與運算實例在內的完整環境。透過在 Terraform 中引用 Packer 生成的不可變映像，企業不僅能大幅縮短應用部署的啟動時間，更能確保每個環境的一致性，從而降低組態漂移（Configuration Drift）的風險，實現真正敏捷且可靠的基礎設施管理。

整合 Packer 與 Terraform：實現端對端自動化基礎設施部署

在成功使用 Packer 創建自定義虛擬機映像後，下一步是利用 Terraform 來部署基於此映像的虛擬機。這種結合 IaC 工具的做法，能夠實現從映像生成到應用部署的端對端自動化，極大地提高了效率和一致性。

步驟一：在 Terraform 中引用 Packer 生成的映像

Packer 在構建過程中創建的映像，可以通過 Terraform 的 azurerm_image 數據塊來引用。這個數據塊允許 Terraform 查詢 Azure 中現有的映像資源。

Terraform data 區塊範例 (compute.tf):

在您的 Terraform 腳本中，添加以下 data 區塊，以獲取由 Packer 生成的自定義映像的屬性：

data "azurerm_image" "custom_nginx_image" {
  name                = "my-webserver-20231027103000" # 替換為您實際的映像名稱
  resource_group_name = "rg_packer_images"           # 替換為映像所在的資源組名稱
}
  • name: 指定您通過 Packer 構建的映像的確切名稱。這個名稱通常是您在 Packer 模板中定義的 image_name 或其動態生成的版本。
  • resource_group_name: 指定存儲該映像的 Azure 資源組名稱。這應與 Packer 構建時使用的 managed_image_resource_group_name 相匹配。

通過這個 data 區塊，Terraform 就可以獲取映像的 ID、位置等信息，並將其用於後續的資源創建。

步驟二：在 Terraform 中配置虛擬機資源

接下來，您需要在 Terraform 的 resource 區塊中，將虛擬機的映像源配置為剛才通過 data 區塊獲取的自定義映像。

Terraform azurerm_virtual_machine 資源範例 (compute.tf):

修改或新增您的 azurerm_virtual_machine 資源，將 source_image_reference 或類似的參數指向自定義映像。

resource "azurerm_virtual_machine" "app_vm" {
  name                  = "my-web-app-vm"
  location              = data.azurerm_image.custom_nginx_image.location
  resource_group_name   = azurerm_resource_group.main.name
  vm_size               = "Standard_DS2_v2"
  network_interface_ids = [azurerm_network_interface.main.id]

  # 使用自定義映像
  storage_image_reference {
    id = data.azurerm_image.custom_nginx_image.id
  }

  os_profile_linux_config {
    # ... 其他 Linux 配置 ...
    admin_username = "azureuser"
    disable_password_authentication = true
    ssh_keys {
      key_data = file("~/.ssh/id_rsa.pub") # 替換為您的 SSH 公鑰路徑
      path     = "/home/azureuser/.ssh/authorized_keys"
    }
  }

  # ... 其他 VM 配置，如磁碟、擴展等
}
  • storage_image_reference.id: 這裡我們將 id 屬性設置為 data.azurerm_image.custom_nginx_image.id，這就是 Terraform 從 Azure 獲取的自定義映像的唯一標識符。
  • location: 通常也從數據塊中獲取，確保 VM 與映像位於同一區域。
  • os_profile_linux_config: 由於我們構建的是 Linux 映像，這裡配置了 Linux 系統的相關設定，例如管理員用戶名和 SSH 公鑰，以便能夠安全地連接到新創建的 VM。

步驟三：執行 Terraform 部署

完成 Terraform 配置後，按照標準的 Terraform 工作流程執行部署：

  1. 初始化 Terraform:

    terraform init

    此命令會下載所需的 AzureRM 提供者插件。

  2. 規劃部署:

    terraform plan

    此命令會生成一個執行計劃，顯示 Terraform 將要創建、修改或刪除的資源。您可以檢查計劃，確保 Terraform 將基於您的自定義映像創建虛擬機。

  3. 應用部署:

    terraform apply

    此命令會執行計劃，在 Azure 中創建虛擬機。由於虛擬機是基於已經預先配置好的映像創建的，其啟動速度會比從通用映像創建快得多，並且已經預裝了 Nginx 等應用。

視覺化 Packer 與 Terraform 的整合流程

以下圖示展示了 Packer 和 Terraform 如何協同工作，實現自動化基礎設施部署。

@startuml
!define DISABLE_LINK
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

start

component "Packer" {
  :編寫 Packer 模板 (HCL);
  :執行 `packer build`;
  :創建臨時 VM;
  :配置映像 (安裝 Nginx);
  :通用化映像;
  :生成 Azure 映像;
  :清理臨時資源;
}

component "Terraform" {
  :編寫 Terraform 配置 (HCL);
  :  - 定義 `data "azurerm_image"` (引用 Packer 映像);
  :  - 定義 `resource "azurerm_virtual_machine"` (使用自定義映像);
  :執行 `terraform init`;
  :執行 `terraform plan`;
  :執行 `terraform apply`;
  :部署 VM 至 Azure;
}

Packer --> Terraform : 生成自定義映像
Terraform --> Azure : 部署基於自定義映像的 VM

stop

@enduml

看圖說話：

此圖示清晰地展示了 Packer 和 Terraform 如何協同工作，構建一個自動化的基礎設施部署流程。首先，Packer 作為映像構建的起點。開發者編寫 Packer 模板（通常使用 HCL 格式），然後執行 packer build 命令。Packer 會創建一個臨時虛擬機，在其上執行預定義的配置（例如安裝 Nginx），進行通用化處理，最終生成一個自定義的 Azure 映像，並清理臨時資源。這個過程的產物是一個可重用的、預先配置好的映像。

接下來，Terraform 接管流程。開發者編寫 Terraform 配置，其中關鍵步驟是定義一個 data "azurerm_image" 塊，用於引用 Packer 生成的自定義映像。這個數據塊讓 Terraform 能夠獲取映像的詳細屬性。然後，在定義 azurerm_virtual_machine 資源時，Terraform 會將此自定義映像的 ID 指定為虛擬機的來源映像。執行 terraform init、terraform plan 和 terraform apply 命令後，Terraform 會調用 Azure API，根據配置創建一個新的虛擬機。由於這個虛擬機是基於已經配置好的映像創建的，其部署速度更快，並且預裝了所需的應用程式和服務。最終，Packer 和 Terraform 的結合，實現了從基礎映像構建到應用部署的完整自動化，顯著提升了基礎設施管理的效率和一致性。

整合 Packer 與 Terraform：實現高效基礎設施部署

在完成 Packer 映像的創建後，Terraform 可用於部署基於此映像的虛擬機。透過將 Packer 生成的映像 ID 整合到 Terraform 的資源配置中，我們可以實現快速且一致的基礎設施部署。

引用 Packer 生成的映像 ID

Terraform 的 azurerm_virtual_machine 資源塊需要指定虛擬機的來源映像。當使用 Packer 創建的自定義映像時，我們需要將該映像的唯一 ID 傳遞給 Terraform。這通常通過以下步驟完成：

  1. 定義數據塊以獲取映像信息: 在 Terraform 的配置文件中（例如 compute.tf），使用 data "azurerm_image" 塊來引用由 Packer 生成的映像。這個數據塊會查詢 Azure，並獲取映像的屬性，包括其唯一的 id。

    data "azurerm_image" "custom_vm_image" {
  name                = "my-webserver-20231027103000" # 請替換為實際映像名稱
  resource_group_name = "rg_packer_images"           # 請替換為映像所在的資源組
}

  2. 在虛擬機資源中指定映像 ID: 在定義 azurerm_virtual_machine 資源時，將 storage_image_reference.id 屬性設置為從上述數據塊獲取的映像 ID。

    resource "azurerm_virtual_machine" "app_server" {
  name                  = "my-web-app-instance"
  location              = data.azurerm_image.custom_vm_image.location
  resource_group_name   = azurerm_resource_group.main.name
  vm_size               = "Standard_DS2_v2"
  network_interface_ids = [azurerm_network_interface.main.id]

  # 使用 Packer 生成的自定義映像
  storage_image_reference {
    id = data.azurerm_image.custom_vm_image.id
  }

  # ... 其他 VM 配置，如 OS 設定、磁碟等
  os_profile_linux_config {
    admin_username = "azureuser"
    ssh_keys {
      key_data = file("~/.ssh/id_rsa.pub")
      path     = "/home/azureuser/.ssh/authorized_keys"
    }
  }
}

部署流程與優勢

當 Terraform 執行 apply 命令時，它將利用 data.azurerm_image.custom_vm_image.id 指向的自定義映像來創建虛擬機。由於此映像已經預裝了所需的軟體（如 Nginx）和配置，部署過程將顯著加快，並且新創建的虛擬機即可立即投入使用。

整合 IaC 工具鏈:

此流程展示了一個完整的基礎設施即程式碼 (IaC) 工作流程：

  • Terraform: 用於定義和管理雲端基礎設施的整體架構。
  • Packer: 用於創建預先配置好的、不可變的虛擬機映像。
  • Ansible (或其他配置管理工具): 可用於在 Packer 映像構建過程中執行詳細的軟體安裝和系統配置。

這種組合能夠實現：

  • 加速部署: 映像已預裝應用，減少了 VM 啟動後的配置時間。
  • 提高一致性: 確保所有部署的 VM 都基於相同的、經過測試的映像。
  • 減少停機時間: 更快的部署和更可靠的配置，有助於縮短服務中斷時間。

發展視角： 績效與成就視角 + 創新與突破視角

縱觀現代IT基礎設施管理的演進，Packer與Terraform的整合不僅是工具的疊加，更是維運哲學的重大轉變。相較於傳統在空白虛擬機上執行組態腳本的作法，這種預先烘烤「黃金映像」（Golden Image）的模式，從根本上解決了「組態漂移」（Configuration Drift）的頑疾，確保了從開發到生產環境的高度一致性。Packer專注於映像內容的「不變性」（Immutability），而Terraform則負責基礎設施狀態的「宣告性」（Declarative），兩者結合，讓各自專注於最擅長的領域，從而實現了1+1>2的系統性效益。

展望未來，隨著容器化技術與無伺服器架構的普及，這種「不可變基礎設施」（Immutable Infrastructure）的核心理念將持續深化。黃金映像不僅是部署單元，更將成為企業安全合規與治理的關鍵控制點，將安全性左移至開發週期的更前端。然而，導入此流程的挑戰在於映像版本的管理與更新策略，若無完善的CI/CD流程支持，映像的維護本身可能成為新的管理負擔。

玄貓認為，對於追求高效能與高穩定性的技術團隊而言，掌握Packer與Terraform的整合應用，已非選項，而是建立現代化、可擴展雲端維運體系的基石。建議從核心應用開始，逐步建立此自動化映像工廠，其長期投資回報將遠超過初期的建置成本。

玄貓 BlackCat

玄貓 BlackCat

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