基礎設施即程式碼 (Infrastructure as Code, IaC) 全面解析

發表於 2025-09-14 分類於技術筆記

在現代軟體開發與雲端運算的世界裡，基礎設施即程式碼 (Infrastructure as Code, IaC) 已經成為 DevOps 及雲端自動化的核心理念之一。傳統上，基礎設施 (例如伺服器、網路、防火牆、資料庫) 的建置與管理往往依賴系統管理員手動操作，但這種方式隨著系統規模擴張，很快會變得緩慢、不一致且難以維護。IaC 的出現正是為了解決這些問題。

什麼是基礎設施即程式碼？

基礎設施即程式碼 (IaC) 是一種透過程式碼來定義、配置與管理基礎設施的方式。換句話說，伺服器、網路設定、安全性規則等不再需要人為手動設定，而是寫成可版本控制的程式碼，並交由工具自動執行。

舉例來說，與其進入雲端管理控制台點選幾十個按鈕來建立 VM (Virtual Machine)，可以透過像 Terraform 或 AWS CloudFormation 的設定檔案，一鍵部署整個環境。

為什麼需要 IaC？

一致性與可重現性

手動操作難免會有人為錯誤，導致「測試環境可以跑，但上線環境卻壞掉」。IaC 可保證不同環境之間的設定一致，避免「配置漂移 (configuration drift)」。

自動化與快速部署

一旦定義好基礎設施，只需執行部署指令，就能快速建立完整環境，適合 CI/CD 流程。

可追蹤與版本控制

IaC 通常與 Git 搭配使用，讓基礎設施的變更有完整的歷史紀錄，可回滾、可審查。

降低成本與風險

自動化與一致性意味著更少的人力操作錯誤與維運負擔，進而降低運行成本。

常見 IaC 工具

工具	特點	使用情境
Terraform	跨雲支援，宣告式語法 (HCL)，社群活躍	多雲部署、自動化 CI/CD
AWS CloudFormation	AWS 原生，深度整合 AWS 服務	完全使用 AWS 的團隊
Ansible	指令式，適合伺服器配置與應用程式安裝	VM / Container 配置管理
Pulumi	可用 TypeScript、Python、Go 撰寫	偏好通用程式語言的團隊
Chef / Puppet	偏向系統配置管理	傳統大型 IT 環境

IaC 的工作流程

一個典型的 IaC 工作流程如下：

flowchart TD
    A["撰寫基礎設施程式碼"] --> B["提交到版本控制 (Git)"]
    B --> C["CI/CD Pipeline 驗證配置"]
    C --> D["執行 IaC 工具部署"]
    D --> E["雲端平台建立資源"]
    E --> F["監控與維護"]

撰寫程式碼：使用 IaC 工具撰寫基礎設施定義檔案。
版本控制：將程式碼提交到 Git，以便協作與審查。
自動化流程：透過 CI/CD pipeline 驗證配置正確性。
部署：IaC 工具執行程式碼，建立或更新雲端資源。
監控：持續追蹤資源狀態，確保與程式碼一致。

宣告式 vs 指令式

IaC 工具可分為 宣告式 (Declarative) 與 指令式 (Imperative)：

模型	特點	工具範例
宣告式 (Declarative)	描述「期望狀態」，工具負責決定如何達成	Terraform, CloudFormation
指令式 (Imperative)	描述「步驟流程」，由人決定執行順序	Ansible, Chef

例如：

宣告式：「我要有三台 VM」 → 工具自動判斷需新增或刪除 VM。
指令式：「先建立 VM，再安裝套件，然後設定防火牆」 → 每個步驟都需明確描述。

實際應用場景

多環境管理：開發、測試、上線環境皆可用相同程式碼快速建立。
自動化 CI/CD 部署：新功能發布可同時更新應用程式與基礎設施。
災難復原 (Disaster Recovery)：發生問題時可用 IaC 快速重建整個環境。
混合雲與多雲管理：統一管理多個雲端平台的資源。

實務範例：Terraform 建立 AWS EC2

以下是一個最簡單的 Terraform 配置，建立一台 EC2：

provider "aws" {
  region = "ap-northeast-1"
}

resource "aws_instance" "example" {
  ami           = "ami-0c3fd0f5d33134a76" # Amazon Linux 2
  instance_type = "t2.micro"

  tags = {
    Name = "Hello-IaC"
  }
}

只要執行以下三個步驟，就能快速建置資源：

terraform init
terraform plan
terraform apply

IaC 常見挑戰

狀態管理
工具需要追蹤「現有資源」與「程式碼定義」是否一致。例如 Terraform 的 terraform.tfstate 檔案，必須妥善保存（通常放在 S3 + DynamoDB lock）。
安全性
API 金鑰、資料庫密碼等敏感資訊，不能直接寫在 IaC 檔案內，需搭配 Vault、AWS Secrets Manager 或 環境變數 管理。
配置漂移 (Configuration Drift)
如果有人手動修改雲端資源，IaC 記錄就會與實際環境不一致。解法是透過 terraform plan 定期檢查，或啟用 Policy as Code。
學習曲線
不同工具語法差異大，團隊需要時間建立共識與最佳實踐。

IaC 最佳實踐

模組化設計：將 VPC、EC2、RDS 拆成可重複使用的模組。
GitOps 流程：所有變更透過 Git Pull Request，並經過 CI/CD pipeline 驗證。
自動化測試：使用工具如 terraform validate、terratest 確保程式碼正確。
權限最小化：IaC 工具使用的帳號應採用最小權限原則。
監控與審查：整合 CloudWatch、Prometheus，追蹤基礎設施狀態。

結論

基礎設施即程式碼 (IaC) 不只是「取代手動操作」，而是讓基礎設施管理進入軟體工程化的層次。
它帶來的一致性、自動化與可追蹤性，使得團隊能更快、更穩定地交付產品。

對於剛接觸 IaC 的工程師，可以從 Terraform 開始，體驗將「點選式操作」轉換成「程式碼定義」的威力；而在企業級場景中，IaC 更能結合 CI/CD、監控、安全策略，成為整個 DevOps pipeline 的基石。

下一步，建議嘗試在本地寫一份 Terraform 配置檔，並將它與 GitHub Actions 整合，自動化建立與銷毀雲端環境，這會讓你真正體會到 「基礎設施也能像程式碼一樣敏捷開發」 的價值。