整合CI/CD實現基礎設施即代碼自動化

將基礎設施即代碼（IaC）導入持續整合與持續交付（CI/CD）框架，是現代化雲端維運的關鍵實踐。此模式的核心在於將基礎設施的生命週期管理完全代碼化與自動化，從而解決手動配置所帶來的人為錯誤與環境不一致性問題。透過自動化管道，從 Packer 映像檔的構建、Terraform 的語法驗證與變更計畫預覽，到最終的部署執行，每一步驟皆有紀錄且可重複執行。這種結合版本控制系統（如 Git）的方法，不僅提升了部署速度與可靠度，更讓基礎設施的變更如同軟體開發般，具備可審計、可回滾的特性，為企業打造了穩健且敏捷的雲端基礎架構。

CI/CD 驅動的基礎設施即代碼：自動化部署與版本管理

深入探討如何將 CI/CD 流程應用於基礎設施即代碼 (IaC) 的自動化部署，整合 Packer 構建雲端映像檔，並利用 GitLab CI、Azure Pipelines 等工具實現端到端的基礎設施管理，同時強調程式碼版本控制的重要性

本節將聚焦於將持續整合與持續交付 (CI/CD) 的強大能力，應用於基礎設施即代碼 (IaC) 的自動化部署。我們將探討如何透過 CI/CD 管道來管理 Packer 構建的雲端映像檔，並整合 Terraform 等 IaC 工具來自動化基礎設施的創建、更新與維護。同時，我們將詳細介紹 GitLab CI 的配置與應用，並將其與 Azure Pipelines 的實踐進行對比，強調在整個流程中，Git 程式碼版本控制的關鍵作用。

CI/CD 在 IaC 中的應用

將 CI/CD 實踐應用於 IaC，能夠顯著提升基礎設施管理的效率、一致性和可靠性。

1. IaC 的核心理念:

   • 將基礎設施的定義（如伺服器、網路、儲存、安全組等）以程式碼的形式進行管理，通常使用 Terraform, Ansible, CloudFormation, ARM Templates 等工具。
   • 這使得基礎設施的創建、修改和刪除過程可以像應用程式碼一樣進行版本控制、自動化測試和部署。

2. CI/CD 管道的 IaC 工作流程:

   • 程式碼提交: 開發者或基礎設施工程師將 IaC 腳本（如 Terraform .tf 文件）提交到 Git 倉庫。
   • CI 階段:
     • 觸發: 程式碼提交會觸發 CI 管道。
     • 驗證: 運行 IaC 工具的語法檢查和靜態分析（如 terraform validate, terraform fmt）。
     • 計劃 (Plan): 執行 terraform plan 命令，生成基礎設施變更的預覽，但不實際執行。
     • 測試: 執行單元測試或策略檢查（如 Open Policy Agent, Sentinel）。
   • CD 階段:
     • 觸發: CI 階段成功後，觸發 CD 管道，通常需要手動批准。
     • 應用 (Apply): 執行 terraform apply 命令，將計劃中的變更應用到目標雲端環境。
     • 後續驗證: 運行整合測試或端到端測試，驗證部署的基礎設施是否按預期工作。
     • 映像檔更新: 如果 CI/CD 流程也包含了 Packer 構建映像檔，那麼當映像檔更新時，可以觸發 Terraform 管道來更新使用該映像檔的虛擬機器。

Packer 與 IaC 的協同構建

Packer 構建的雲端映像檔是 Terraform 等 IaC 工具部署的關鍵組件。

1. Packer 構建映像檔:

   • 如前所述，Packer 模板定義了如何創建一個包含特定軟體和配置的基礎映像檔。
   • 構建的輸出是一個映像檔的 ID 或名稱，這個 ID 是 Terraform 部署虛擬機器時必須引用的。

2. 將 Packer 構建整合到 CI/CD 管道:

   • 觸發: 當 Packer 模板有變更，或需要更新基礎映像檔時，觸發 Packer 構建管道。
   • 執行 Packer: 在 CI/CD 工具（如 GitLab CI, Azure Pipelines）中執行 packer build 命令。
   • 發布映像檔: Packer 構建完成後，將生成的映像檔 ID 或名稱存儲為 CI/CD 變數，或發布到映像檔倉庫。
   • 觸發 Terraform 部署: 使用此映像檔 ID 作為輸入，觸發 Terraform 部署管道，以更新使用該映像檔的虛擬機器或創建新的虛擬機器。

GitLab CI 的配置與應用

GitLab CI/CD 是 GitLab 平台內建的 CI/CD 工具，與 GitLab 的程式碼倉庫、問題追蹤等功能緊密集成。

1. GitLab CI 配置:

   • .gitlab-ci.yml 文件: CI/CD 管道的定義文件，通常放在專案根目錄。
   • 結構: 管道由多個階段 (stages) 組成，每個階段包含多個任務 (jobs)。
   • 執行器 (Runners): GitLab Runner 是執行 CI/CD 任務的代理。可以設置共享 Runner 或自建 GitLab Runner。
   • 腳本執行: 在 script 節中定義要執行的命令，例如 packer build, terraform apply, git push 等。

2. GitLab CI 實踐:

   • 身份驗證: 配置 GitLab Runner 與雲端提供商（如 Azure）的身份驗證，通常使用服務主體或訪問令牌。
   • 變數管理: 在 GitLab 的 CI/CD 設置中定義敏感變數（如雲端憑證），這些變數可以在 .gitlab-ci.yml 文件中使用。
   • 管道示例:
     • 構建階段: 執行 packer build，生成映像檔。
     • 部署階段: 執行 terraform init, terraform plan, terraform apply。

3. 訪問 CI 執行細節:

   • 在 GitLab 的 CI/CD 頁面，可以查看所有管道的執行狀態、日誌、任務輸出，以及構建產物。

CI/CD 驅動的基礎設施部署流程圖示

@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

partition "IaC 的 CI/CD 自動化部署" {
  partition "程式碼管理 (Git)" {
    :1. 基礎設施代碼 (Terraform, etc.) 儲存在 Git 倉庫;
    :2. 映像檔定義 (Packer) 儲存在 Git 倉庫;
  }

  partition "CI 階段" {
    :3. 程式碼提交觸發 CI 管道 (GitLab CI / Azure Pipelines);
    :4. 驗證 IaC 語法 (`terraform validate`);
    :5. 執行 Packer 構建映像檔 (`packer build`);
    :6. 獲取映像檔 ID 作為輸出變數;
    :7. 執行 `terraform plan` 生成變更計劃;
  }

  partition "CD 階段" {
    :8. 手動批准觸發 CD 管道;
    :9. 使用映像檔 ID 更新 Terraform 配置;
    :10. 執行 `terraform apply` 部署/更新基礎設施;
    :11. 執行後續測試與驗證;
  }

  partition "工具整合" {
    :GitLab CI / Azure Pipelines 作為調度器;
    :Packer 負責映像檔構建;
    :Terraform 負責基礎設施部署;
    :Git 負責版本控制與協作;
  }
}

stop

@enduml

看圖說話：

此圖示全面展示了如何利用 CI/CD 管道實現基礎設施即代碼 (IaC) 的自動化部署。圖的開頭強調了 Git 在程式碼管理中的核心地位，所有 IaC 和映像檔定義都儲存在 Git 倉庫中。隨後，「CI 階段」詳細描述了自動化過程的起始，包括程式碼提交觸發管道，執行 Packer 構建映像檔，並生成 Terraform 所需的映像檔 ID，最後進行 Terraform 的變更計劃。接著，「CD 階段」說明了在手動批准後，如何利用 Terraform 應用這些變更，實現基礎設施的部署或更新，並進行後續驗證。最後，「工具整合」部分總結了 GitLab CI/Azure Pipelines、Packer、Terraform 和 Git 如何協同工作，共同構建一個高效、可靠且可追溯的基礎設施管理體系。

結論

縱觀現代技術管理的演進，基礎設施的生命週期管理已從手動配置的工藝時代，邁向自動化與程式碼驅動的工程化紀元。CI/CD 驅動的基礎設施即代碼（IaC）流程，其核心價值不僅在於提升部署效率，更在於將基礎設施從不確定、易變的資產，轉化為可預測、可追溯且高度一致的數位產品。然而，此轉型的關鍵瓶頸往往不在於工具的導入，而在於團隊思維模式的躍遷——從被動應對故障，轉向主動設計系統韌性，並要求維運人員具備開發者的紀律與版本控制素養。Packer、Terraform 與 CI/CD 工具鏈的無縫整合，正是實現此一價值閉環的關鍵。

展望未來，我們預見此基礎將進一步與 AIOps 及安全左移（Shift-Left Security）深度融合，讓基礎設施的變更不僅自動化，更具備智慧化的風險預判與合規性自我修復能力。

玄貓認為，掌握這套自動化部署與版本管理的系統性方法，已非單純的技術選項，而是高階管理者打造高效能、高韌性技術組織的必要修養與核心競爭力。