Terraform、Infrastructure Manager、Config Connector 怎麼選？

前言

用 Console 建第一個環境很方便；到了第二、第三個環境，設定若只靠人工記憶，就很難確認哪裡不同。IaC（Infrastructure as Code，基礎架構即代碼）把設定放進版本控制，讓團隊能審查變更並重複部署。在 GCP 上可使用 Terraform 管理資源，透過 Infrastructure Manager 執行 Terraform 部署；熟悉 Kubernetes 的團隊也可評估用 Config Connector 管理 GCP 資源。

這篇先比較幾種工具各自適合的團隊與工作流程，再談 Terraform state 怎麼保存。讀之前知道 Terraform 是什麼、GCS 是物件儲存即可；不熟 Kubernetes，也可以先把 Config Connector 當成另一種管理雲端資源的方式來看。

注意：Google Cloud Deployment Manager 已棄用，2026 年 3 月 31 日終止支援。目前 ACE 考試指南已不再列出 Deployment Manager 作為 IaC 工具範例。

ACE 考試指南中的 IaC 範圍

根據目前的 ACE 考試指南 Section 2.4：

2.4 Planning and implementing resources using tooling. Considerations include:

• Infrastructure as Code tooling (e.g., Fabric FAST, Config Connector, Terraform, Helm)
• AI-assisted planning and implementation (e.g., Gemini CLI, Google Antigravity, Gemini Cloud Assist, Application Design Center)

重點：考試考的是 Terraform、Config Connector、Fabric FAST、Helm，不是 Deployment Manager。

Terraform 基礎

什麼是 Terraform？

Terraform 是 HashiCorp 的開源 IaC 工具，使用 HCL（HashiCorp Configuration Language）宣告式語法定義基礎架構：

# main.tf — 建立一台 GCE VM
provider "google" {
  project = "my-project-id"
  region  = "asia-east1"
}

resource "google_compute_instance" "web" {
  name         = "web-server"
  machine_type = "e2-medium"
  zone         = "asia-east1-a"

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-12"
    }
  }

  network_interface {
    network = "default"
    access_config {}  # 公開 IP
  }

  labels = {
    env = "production"
  }
}

核心工作流程

flowchart TB
  CODE["版本化 HCL 設定"] --> INIT["terraform init<br/>初始化 Backend<br/>與 Provider"]
  INIT --> PLAN["terraform plan<br/>比較設定、<br/>State 與真實資源"]
  PLAN --> REVIEW{"Plan 經人工審查？"}
  REVIEW -->|"需要修正"| CODE
  REVIEW -->|"核准"| APPLY["terraform apply"]
  APPLY --> CLOUD["建立／更新 GCP 資源"]
  APPLY --> STATE["更新 Remote State"]
  CLOUD -. "下次偵測 Drift" .-> PLAN
  DESTROY["terraform destroy"] -. "只有明確退役時" .-> CLOUD

State 管理

Terraform 用 State 檔案追蹤實際基礎架構與設定的對應關係：

# backend.tf — 使用 GCS 作為遠端 State 後端
terraform {
  backend "gcs" {
    bucket = "my-terraform-state"
    prefix = "prod/network"
  }
}

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

State 檔案可能包含敏感資訊（密碼、金鑰），務必使用 Remote Backend 並限制存取權限。

Terraform Module

Module 就是把一坨常用的 resource 打包成一個可帶參數的積木，跟你平常 import 函式庫一個意思：

# 使用 Google 官方的 VPC Module
module "vpc" {
  source  = "terraform-google-modules/network/google"
  version = "~> 18.0"  # 撰文時最新主版本；實際請查 Terraform Registry

  project_id   = "my-project-id"
  network_name = "production-vpc"

  subnets = [
    {
      subnet_name   = "web-subnet"
      subnet_ip     = "10.10.10.0/24"
      subnet_region = "asia-east1"
    }
  ]
}

Module 來源：

• Terraform Registry：數千個社群模組
• Google 官方模組：terraform-google-modules 組織提供的驗證模組
• 本地路徑：團隊自建的內部模組

Infrastructure Manager（託管 Terraform）

什麼是 Infrastructure Manager？

Infrastructure Manager（Infra Manager）是 GCP 的託管 Terraform 服務，自動執行 terraform init、validate、apply：

flowchart TB
  SOURCE["Git Repository／<br/>Cloud Storage<br/>Terraform 設定"] --> REV["Infrastructure<br/>Manager Revision"]
  REV --> PREVIEW["Preview<br/>託管 init + validate + plan"]
  PREVIEW --> APPROVE{"審查預覽結果"}
  APPROVE -->|"退回"| SOURCE
  APPROVE -->|"核准"| DEPLOY["Deployment<br/>託管 apply"]
  DEPLOY --> BUILD["短暫 Cloud Build<br/>執行環境"]
  BUILD --> GCP["GCP 資源"]
  BUILD --> STATE["Google 管理的<br/>GCS State"]
  DEPLOY --> HISTORY["保留 Revision／部署歷史"]

核心功能

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

操作範例

# 預覽部署
gcloud infra-manager previews create \
  projects/my-project/locations/asia-east1/previews/my-preview \
  --service-account=projects/my-project/serviceAccounts/infra-manager@my-project.iam.gserviceaccount.com \
  --git-source-repo=https://github.com/my-org/infra-configs \
  --git-source-directory=environments/prod \
  --git-source-ref=main

# 執行部署
gcloud infra-manager deployments apply \
  projects/my-project/locations/asia-east1/deployments/prod-network \
  --service-account=projects/my-project/serviceAccounts/infra-manager@my-project.iam.gserviceaccount.com \
  --git-source-repo=https://github.com/my-org/infra-configs \
  --git-source-directory=environments/prod \
  --git-source-ref=main

# 查看部署狀態
gcloud infra-manager deployments describe \
  projects/my-project/locations/asia-east1/deployments/prod-network

定價

Infrastructure Manager 本身免費。你只需支付：

• Cloud Build 執行時間（免費層：2,500 build-minutes / 月，限 e2-standard-2 預設機型；換更大的機型就不適用免費層）
• Cloud Storage 存放 State 和設定檔（標準費率）

Config Connector（K8s 原生 IaC）

什麼是 Config Connector？

Config Connector 讓你用 Kubernetes YAML 管理 GCP 資源，做法是把 GCP 資源變成 Kubernetes Custom Resource：

# cloud-sql.yaml — 用 K8s YAML 建立 Cloud SQL
apiVersion: sql.cnrm.cloud.google.com/v1beta1
kind: SQLInstance
metadata:
  name: my-database
  namespace: my-namespace
spec:
  databaseVersion: POSTGRES_15
  region: asia-east1
  settings:
    tier: db-f1-micro
    ipConfiguration:
      ipv4Enabled: true

# 像管理 K8s 資源一樣管理 GCP 資源
kubectl apply -f cloud-sql.yaml
kubectl get sqlinstances
kubectl delete sqlinstance my-database

flowchart TB
  GIT["Git 中的 KRM YAML"] --> GITOPS["Argo CD／Flux"]
  GITOPS --> API["Kubernetes API<br/>Custom Resource"]
  API --> KCC["Config Connector Controller"]
  KCC -->|"呼叫 GCP API"| RESOURCE["Cloud SQL／VPC／Pub/Sub 等資源"]
  RESOURCE -->|"實際狀態"| KCC
  KCC -->|"更新 status／condition"| API
  API --> DESIRED{"實際狀態符合 YAML？"}
  DESIRED -->|"否：持續 reconcile"| KCC
  DESIRED -->|"是"| STEADY["維持期望狀態"]

適用場景

• 團隊已經用 GitOps（把部署設定也放 Git，靠 PR merge 觸發部署的做法；常見工具 ArgoCD、Flux）管理 K8s
• 想要統一管理 K8s Workload 和 GCP 資源
• 不想引入 Terraform 額外工具鏈

支援範圍

Config Connector 支援 多種 GCP 資源類型，包含：

• Compute Engine、GKE、Cloud SQL
• BigQuery、Pub/Sub、Cloud Storage
• IAM、VPC、Cloud DNS 等

Fabric FAST

Fabric FAST 是 Google Cloud 提供的 Terraform-based 企業級地基框架：

Fabric FAST 提供：
├── Organization 設定
├── 資料夾結構（Folders）
├── 共享 VPC 設定
├── IAM 權限綁定
├── 日誌和監控
└── 安全基線

• 用於企業快速建立 GCP Landing Zone（企業在 GCP 開帳號的標準地基：組織結構、共用網路、權限、稽核一次設好）
• 基於 Terraform Module，符合 Google 最佳實踐
• ACE 考試指南明確列出，需要知道它的定位

Helm（K8s 套件管理）

Helm 是 Kubernetes 的套件管理工具，不直接管理 GCP 資源，但管理 GKE 上的應用部署：

# 安裝 Helm Chart（以 ingress-nginx 為例；該專案已於 2026 年 3 月退役、不再有安全更新，這裡只示範指令）
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm install my-ingress ingress-nginx/ingress-nginx

# 升級
helm upgrade my-ingress ingress-nginx/ingress-nginx --set controller.replicaCount=3

# 回滾
helm rollback my-ingress 1

• Chart：可重用的 K8s 應用範本
• Release：Chart 的一次安裝實例
• Values：可自訂的參數
• ACE 考試考它作為 IaC 工具鏈的一部分

Deployment Manager（棄用）

重要：已於 2026/3/31 終止支援

⚠️ Deployment Manager 已於 2026 年 3 月 31 日終止支援。 若仍有既有部署，應規劃轉換與接手方式；下方用 DM Convert 示範遷移流程。

Deployment Manager 是 GCP 原生 IaC 工具，使用 YAML + Jinja2/Python 範本：

# 歷史參考——DM 設定檔格式
resources:
  - name: my-vm
    type: compute.v1.instance
    properties:
      zone: asia-east1-a
      machineType: zones/asia-east1-a/machineTypes/e2-medium

為什麼棄用？

• 僅支援 GCP：無法管理多雲資源
• Composite Types 已於 2022 年 2 月停止支援
• 社群小：Module 生態系遠不如 Terraform
• 無法偵測 Drift：不知道手動變更
• State 不透明：無法像 Terraform 一樣檢視和修改 State

遷移路徑

flowchart TB
  DM["既有 Deployment Manager<br/>設定與實際資源"] --> CONVERT["DM Convert"]
  CONVERT --> CHOICE{"新的管理模型？"}
  CHOICE -->|"Terraform／Infra Manager"| HCL["輸出並審查 Terraform HCL"]
  CHOICE -->|"Kubernetes GitOps"| KRM["輸出並審查 KRM YAML"]
  HCL --> PLAN["Plan／Import 對照既有資源"]
  KRM --> ADOPT["Config Connector 採用既有資源"]
  DM --> ABANDON["刪除 DM Deployment<br/>delete-policy = ABANDON"]
  ABANDON --> KEEP["保留真實 GCP 資源"]
  KEEP --> HANDOFF["由新工具接手後續變更"]
  PLAN --> HANDOFF
  ADOPT --> HANDOFF

--delete-policy=ABANDON 是遷移的關鍵——刪除 DM 追蹤但保留實際資源。

📝 考場提點

Deployment Manager 已終止支援，規劃新部署時不應把它當成首選。若情境是遷移既有資源，則要留意以下步驟：

• 2026/3/31 已終止支援，新部署應改評估其他工具
• 遷移工具是 DM Convert（官方標示 Preview），輸出 Terraform HCL 或 Config Connector（KRM）YAML
• --delete-policy=ABANDON：解除 DM 追蹤但保留實際資源，後續還須驗證新工具是否正確接手

IaC 工具選型

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

選型公式

flowchart TB
  START{"現在要管理什麼？"}
  START -->|"既有 Deployment Manager"| MIGRATE["DM Convert<br/>遷移到 Terraform 或 KRM"]
  START -->|"GKE 上的應用套件"| HELM["Helm"]
  START -->|"企業 Organization／Landing Zone"| FAST["Fabric FAST + Terraform"]
  START -->|"一般 GCP 基礎架構"| WORKFLOW{"團隊既有哪種工作流程？"}
  WORKFLOW -->|"Kubernetes + GitOps"| KCC["Config Connector"]
  WORKFLOW -->|"HCL／通用或多雲 IaC"| MANAGED{"要自行管理 Runner 與 State？"}
  MANAGED -->|"是，需要最大控制"| TF["Terraform"]
  MANAGED -->|"否，偏好 GCP 託管"| IM["Infrastructure Manager"]

📝 考場提點

選工具時先看誰負責部署、是否跨雲，以及團隊既有的工作流程：

• 通用 / 多雲 → Terraform
• GCP 託管 Terraform 部署 → Infrastructure Manager
• 已有 K8s + GitOps（ArgoCD / Flux） → 評估 Config Connector 的 Kubernetes 資源管理方式
• 企業 Landing Zone / 一次把組織地基蓋好 → Fabric FAST
• GKE 上裝應用（不是建 GCP 資源） → Helm

Helm 主要協助安裝 Kubernetes 應用；若要以 Kubernetes 資源定義管理 Cloud SQL、VPC 等 Google Cloud 資源，再評估 Config Connector。

IaC 最佳實踐

State 管理

# 永遠使用 Remote Backend
terraform {
  backend "gcs" {
    bucket = "my-terraform-state"
    prefix = "env/prod"
  }
}

• 永遠使用 Remote Backend（GCS），不要用本地 State
• State Locking 自動生效（GCS backend 內建並預設啟用，免設定；與 S3 不同，不必另外開 DynamoDB 或加 use_lockfile）
• 分環境儲存：prod/、staging/、dev/ 各自獨立
• 加密敏感資料：GCS 預設加密，可額外使用 CMEK

版本控制

• 所有 IaC 設定存入 Git
• 使用 Branch Protection：PR Review 才能合併
• CI/CD 自動跑 terraform plan：PR 自動顯示變更預覽
• Tag 每次成功部署：方便回溯

組織結構

infra-configs/
├── modules/           # 可重用模組
│   ├── vpc/
│   ├── gke-cluster/
│   └── cloud-sql/
├── environments/      # 環境設定
│   ├── prod/
│   ├── staging/
│   └── dev/
├── backend.tf         # Remote State 設定
└── variables.tf       # 共用變數

ACE 考試重點整理

必背知識點

1. Terraform 是 GCP 推薦的首選 IaC 工具
2. State 管理：使用 GCS 作為 Remote Backend，支援 Locking
3. terraform plan 預覽變更、偵測 Drift
4. Infrastructure Manager 是託管 Terraform，免費使用
5. Config Connector 讓 K8s 團隊用 YAML 管理 GCP 資源
6. Fabric FAST 是企業 Landing Zone 框架（Terraform-based）
7. Deployment Manager 已棄用（2026/3/31 終止支援）

常見陷阱題

Q：需要用 IaC 管理 GCP 基礎架構，選什麼工具？ A：Terraform。Google 官方推薦，ACE 考試指南明確列出。

Q：Terraform State 應該存在哪裡？ A：Cloud Storage（GCS）Remote Backend。不要存本地，要支援團隊協作和 State Locking。

Q：團隊用 GitOps 管理 GKE，想用同樣的方式管理 GCP 資源，選什麼？ A：Config Connector。將 GCP 資源變成 K8s Custom Resource，用 kubectl 和 ArgoCD/Flux 管理。

Q：Deployment Manager 還能用嗎？ A：已棄用，2026/3/31 終止支援。應使用 DM Convert 工具遷移到 Terraform 或 Config Connector。

Q：Infrastructure Manager 和直接用 Terraform 有什麼不同？ A：Infra Manager 是託管 Terraform——自動管理 State、自動執行 init/validate/apply，不需要在本地安裝 Terraform CLI。適合想要 GCP 原生體驗的團隊。

Q：什麼是 Fabric FAST？ A：Google Cloud 提供的 Terraform-based 企業地基框架，快速建立符合最佳實踐的 GCP Organization、資料夾結構、Shared VPC 等。

總結

這課要分清楚每個工具管理的是哪一層：Terraform 與 Infrastructure Manager 管雲端資源，Config Connector 讓 Kubernetes 團隊用宣告式設定管理 Google Cloud 資源，Helm 管 GKE 裡的應用。選工具前先看團隊現有流程、state 要由誰管理，以及是否需要跨雲。

準備考試時，可以特別練習 Terraform 的 Plan／Apply 流程，以及多人協作時如何保存與鎖定 state。

下一課 GCP-115：Cloud Memorystore 入門，來看看 GCP 的全託管記憶體資料庫服務。