初學者在學習 Terraform 時最常犯的錯誤之一，就是把自己的本機當作部署伺服器。

典型的流程通常如下：

terraform init
terraform plan
terraform apply

Enter fullscreen mode Exit fullscreen mode

這種做法在學習階段完全沒問題，但當你在真實世界中與多位工程師共同協作時，就會開始產生問題。

試想以下問題：

  • 是誰部署了這套基礎設施？
  • 基礎設施在部署前是否經過審核？
  • 其他人是否能重現這次部署？
  • 如果工程師的筆電遺失或設定錯誤，會發生什麼事？
  • 我們如何確認到底改了哪些內容？

這些正是為什麼在專業環境中，Infrastructure as Code (IaC) 幾乎都會與 Continuous Integration 和 Continuous Deployment (CI/CD) 管線整合的原因。

在本文中，我們將使用 GitHub Actions 建立一個簡單的 Terraform CI/CD 管線。我們不會只聚焦在 YAML 語法，而是先理解為什麼每個階段存在，以及它們如何共同運作來產生安全且可重複的基礎設施部署。

什麼是 Terraform CI/CD？

Terraform CI/CD 是指每當 Terraform 程式碼發生變更時，自動執行驗證、規劃和部署基礎設施的流程。

不再由開發人員從筆電手動執行 Terraform 指令，而是由 CI/CD 平台在受控環境中自動執行這些指令。

典型流程如下：

Developer
      │
      ▼
Git Push
      │
      ▼
GitHub Repository
      │
      ▼
GitHub Actions
      │
      ▼
Terraform Init
      │
      ▼
Terraform Validate
      │
      ▼
Terraform Plan
      │
      ▼
Manual Approval
      │
      ▼
Terraform Apply
      │
      ▼
AWS Infrastructure

Enter fullscreen mode Exit fullscreen mode

這種做法能提供一致性、可見度與安全性，同時降低人為錯誤的風險。

為什麼不手動執行 Terraform？

從你的筆電執行 Terraform 適合個人專案，但在團隊環境中卻會帶來多項風險。

手動部署 CI/CD 部署
需要有人記住每個指令 自動執行
容易跳過驗證步驟 強制執行驗證
難以追蹤部署紀錄 每次部署都有紀錄
憑證儲存在開發人員的筆電上 機密資訊安全儲存
不同機器使用不同版本的 Terraform 一致的執行環境

自動化讓每一項基礎設施變更都遵循相同流程，無論是誰做的變更。

我們將建立什麼

我們的目標是建立兩個獨立的 GitHub Actions 工作流程：

工作流程 1 – 持續整合 (CI)

此工作流程會檢查 Terraform 程式碼品質，執行以下指令：

  • terraform fmt
  • terraform init
  • terraform validate
  • terraform plan

請注意，此工作流程不會建立任何基礎設施。

它的職責只是告訴我們所提出的變更是否安全且有效。

工作流程 2 – 部署

部署工作流程負責建立或更新基礎設施。

只有當我們確認 Terraform plan 結果可接受後才會執行。

這種分離是一項重要的最佳實踐，因為審核基礎設施變更與審核應用程式程式碼同樣重要。

專案結構

我們的儲存庫會如下所示：

terraform-github-actions/
│
├── .github/
│   └── workflows/
│       ├── terraform-ci.yml
│       └── terraform-deploy.yml
│
├── main.tf
├── variables.tf
├── outputs.tf

Enter fullscreen mode Exit fullscreen mode

將 CI 與部署工作流程分開，能讓它們更容易理解、維護，並隨著專案成長而擴展。

理解 CI 管線

CI 工作流程負責回答一個問題：

「這份 Terraform 程式碼是否已準備好部署？」

為了回答這個問題，它會執行多項檢查。

步驟 1：檢查格式

Terraform 要求一致的程式碼風格。

執行：

terraform fmt -check

Enter fullscreen mode Exit fullscreen mode

有助於確保每位貢獻者都遵循相同的格式標準。

步驟 2：初始化 Terraform

在 Terraform 驗證或規劃基礎設施前，必須先下載所需的 providers 並初始化工作目錄。

這可透過以下指令完成：

terraform init

Enter fullscreen mode Exit fullscreen mode

步驟 3：驗證設定

接下來，Terraform 會驗證設定在語法上是否正確。

terraform validate

Enter fullscreen mode Exit fullscreen mode

這能在部署前發現缺少的參數、無效的參照，以及其他設定問題。

步驟 4：產生執行計畫

最後，Terraform 會產生執行計畫。

terraform plan

Enter fullscreen mode Exit fullscreen mode

這個計畫會顯示 Terraform 打算執行的動作，但不會進行任何實際變更。

例如：

  • 將被建立的資源
  • 將被更新的資源
  • 將被刪除的 ресурси

審核這個輸出是 Infrastructure as Code 工作流程中最重要的環節之一。

將 CI 與部署分離

我經常從學生那裡聽到一個問題：

「如果 CI 工作流程已經執行了 terraform plan，為什麼還需要另一個部署工作流程？」

答案很簡單。

CI 工作流程的目的是驗證基礎設施。

部署工作流程的目的是變更基礎設施。

將這兩種職責分開，能讓團隊對部署時機有更好的掌控。

典型流程如下：

Push Code
     │
     ▼
CI Pipeline
     │
     ▼
Plan Generated
     │
     ▼
Engineer Reviews Changes
     │
     ▼
Deployment Triggered
     │
     ▼
Terraform Apply

Enter fullscreen mode Exit fullscreen mode

這種做法能避免意外部署，並鼓勵適當的變更審核。

安全管理 AWS 憑證

初學者常犯的一個錯誤，是將 AWS 憑證硬編碼在 Terraform 程式碼或 GitHub 工作流程中。

千萬不要這麼做。

GitHub 提供了加密的儲存庫機密，可在工作流程執行期間安全存取。

這樣能讓敏感資訊不會出現在原始碼與版本歷史中。

在後續文章中，我們會更進一步，使用 GitHub 的 OpenID Connect (OIDC) 整合來取代長期有效的 AWS 存取金鑰，完全不需要儲存 AWS 憑證。

接下來要做什麼？

在本文中，我們探討了 Terraform CI/CD 的概念，以及為什麼將驗證與部署分離能帶來更安全的基礎設施自動化。

在下一篇文章中，我們將從零開始建立第一個 GitHub Actions 工作流程，理解 YAML 檔案的每一行，並針對 AWS 專案自動化 Terraform 驗證與規劃。

在本系列結束時，我們將擁有一個可安全部署基礎設施的生產級管線，使用 GitHub Actions 與 Terraform 完成。

結語

學習 Terraform 不只是撰寫 .tf 檔案。

專業的 Infrastructure as Code 建立在可重複的流程、程式碼審核、安全的憑證管理，以及自動化部署之上。

GitHub Actions 為我們提供了實踐這些做法的工具，而 Terraform 則提供了以程式碼描述基礎設施的基礎。

結合兩者，團隊就能建立可靠、可擴展且可稽核的雲端基礎設施。

如果你正踏上 DevOps 之旅，掌握這個工作流程將是你能做的最好的投資之一。

你可以在我的 GitHub 儲存庫中找到本文使用的完整範例：

github repo