Deployment Manager 與 Terraform

Deployment Manager 與 Terraform 簡介

在 2024-2026 年的 Google Cloud 上，基礎設施即程式碼 (IaC) 已由 Terraform 主導，而 Deployment Manager (DM) 進入新專案不可建立的停用軌道。PCD 考試要求你認知到：全新架構必須預設使用 Terraform 搭配 hashicorp/google provider，而 Deployment Manager 主要只出現在舊系統遷移的題目中。兩個工具底層都是呼叫 Google Cloud Resource Manager API，但 Terraform 擁有更豐富、跨雲、社群驅動的模組生態系。

一位 Professional Cloud Developer 必須能：在 google 與 google-beta provider 之間做出選擇、設定具備鎖定功能的 GCS 遠端狀態 backend、在 Cloud Build 內執行 terraform plan、用 Workload Identity Federation (WIF) 取代長期 service account 金鑰來保護 HCP Terraform，並能辨識 Pulumi 或 Config Connector 等替代方案。本篇為這些能力建立深入的心智模型。

Deployment Manager：舊系統與停用狀態

架構與設定檔

Deployment Manager (DM) 是 Google 於 2015 年推出的第一方 IaC 服務。它接受頂層的 YAML 設定，引用各種 type（例如 compute.v1.instance、storage.v1.bucket），並支援用 Jinja2 或 Python 撰寫的範本。典型工作流程是 gcloud deployment-manager deployments create my-dep --config config.yaml，將清單送交 Deployment Manager API，回傳一個由 Google 自己保存狀態的 deployment 資源，因此不存在需要管理的本地 state 檔案。

2024 年停用公告

2024 年 4 月 Google 公告 Deployment Manager 在截止日後建立的新 Google Cloud 專案中將不再可用，但因受託生命週期理由，現有 deployment 仍可運作。客戶被引導遷移到 Terraform（戰略 IaC 工具）或 Config Connector（Kubernetes 原生對應方案）。新版 PCD 題目若描述「你的團隊在 2025 年啟動全新工作負載，該選哪個 IaC 工具？」答案是 Terraform，不是 DM。

遷移路徑

既有 DM 使用者可用 terraformer 或 gcloud beta terraform vet 類工具抽出資源設定，將 YAML 清單轉為 HCL。實務上團隊會凍結 DM、撰寫 Terraform 透過 terraform import 接管同一批資源，再以 --delete-policy=ABANDON 刪除 DM deployment，使切換期間資源得以保留。PCD 考試可能以 ABANDON 與 DELETE 的差異作為錯誤選項。

Terraform google 與 google-beta Provider

為何存在兩個 provider

HashiCorp 為 Google Cloud 提供兩個互補的 Terraform provider：

• hashicorp/google：穩定版 provider，揭露 Google Cloud 上已 正式發行 (GA) 的資源。
• hashicorp/google-beta：beta 版 provider，揭露 預覽 / beta 功能，例如新的 Workload Identity Pool 欄位、剛釋出的 Cloud Run 旗標或實驗性 Cloud SQL 選項。

你可以在同一個 root module 同時使用兩者，宣告兩個 required_providers 區塊並加上別名，例如 provider "google-beta" { alias = "beta" }，再以 provider = google-beta.beta 在個別資源切換。

鎖定版本

Terraform 最佳實務是同時鎖定 CLI 與 provider，例如 required_version = "~> 1.6" 及 required_providers { google = { version = "~> 5.10.0" } }。沒有鎖版本，半年後一次 terraform init 可能拉進破壞性大版本升級。PCD 考試喜歡測試你是否理解 provider 版本是 IaC 合約的一部分，不只是 HCL 本身。

Provider 認證

Provider 支援四種憑證來源，依序檢查：GOOGLE_CREDENTIALS 環境變數、gcloud Application Default Credentials、附掛的運算身分（如執行於 GCE / Cloud Build）、以及給 GitHub Actions 等外部 CI 用的 Workload Identity Federation。硬編碼 service account JSON 金鑰是最差選項，正式答題時應避免。

HCP Terraform（Terraform Cloud）搭配 Workload Identity Federation

HCP Terraform 提供什麼

HashiCorp 在 2024 年把 Terraform Cloud 改名為 HCP Terraform。它是一個受管的控制平面，遠端儲存 state、在隔離 worker 上跑 plan/apply、透過 Sentinel 或 OPA 執行政策、提供對 CI/CD 友善的網頁界面。在 PCD 場景中，當多團隊組織需要受治理的執行但不想自己維運 runner 集群時，HCP Terraform 就是答案。

Workload Identity Federation 移除 JSON 金鑰

戰略安全模式是 Workload Identity Federation：HCP Terraform 鑄造短期 OIDC token，Google 的 Security Token Service (STS) 把它換成聯邦化的 Google Cloud 憑證，provider 即可在沒有任何長期 service account JSON 離開 Google 的情況下完成認證。流程使用一個 Workload Identity Pool（iam.googleapis.com/projects/.../locations/global/workloadIdentityPools/<pool>）加上一個信任 HCP Terraform OIDC 簽發者 https://app.terraform.io 的 provider。

設定範例

provider "google" {
  project     = "my-prod-host"
  region      = "asia-east1"
  # 未指定 credentials = ADC + WIF token 交換會自動完成
}

HCP Terraform 暴露 TFC_GCP_WORKLOAD_PROVIDER_NAME 與 TFC_GCP_SERVICE_ACCOUNT_EMAIL workspace 變數；runner 注入後 provider 即可完成 STS 交換。PCD 考生應能完整背誦這條鏈路。

GCS Backend 與狀態鎖

為何團隊必須使用遠端 state

Terraform 把 HCL 資源與 Cloud Resource ID 的對應關係存在 terraform.tfstate JSON 檔案中。對於超過一人的團隊，把這份檔案放在本機是致命的：兩位開發者同時跑 apply 可能破壞 state 並造成資源孤兒。Google 認可的答案是 GCS backend。

Backend 設定

terraform {
  backend "gcs" {
    bucket = "acme-tfstate-prod"
    prefix = "platform/landing-zone"
  }
}

這個貯存桶應為 regional 或 dual-region、啟用 uniform bucket-level access、開啟 物件版本管理 (Object Versioning)（讓誤觸 terraform destroy 可恢復），若法規要求則加上客戶管理加密金鑰 (CMEK)。

原生物件層級鎖

自 2024 年起 GCS backend 支援 以 GCS 物件 generation 加上 If-Match precondition 進行原生狀態鎖，不再需要另一個 Cloud Spanner 或 Cloud SQL 鎖表。Terraform 透過寫入 default.tflock 物件取得鎖；併發執行會收到 409 Conflict 並等到鎖物件釋放才能繼續。這取代了 1.4 版以前「使用 Cloud Storage 加上 Cloud Spanner」的舊模式。

貯存桶的存取控制

貯存桶只授予 roles/storage.objectAdmin 給 Terraform runner 身分。開發者 不應 直接擁有 state 貯存桶的寫入權限，這正是把變更導入 CI 的關鍵。典型 IAM Condition 會限制只有來自 runner Workload Identity Pool 的請求才能存取 GCS state 貯存桶。

Cloud Foundation Toolkit (CFT) 模組

CFT 提供什麼

Cloud Foundation Toolkit 是 Google 開源的 觀念主張型 Terraform 與 Deployment Manager 模組庫，將 GCP 最佳實務固化為程式碼。Terraform 部分位於 GitHub 上的 terraform-google-modules 組織，包含 150 多個模組：網路 (terraform-google-network)、KMS (terraform-google-kms)、Cloud SQL (terraform-google-sql-db)、Kubernetes Engine (terraform-google-kubernetes-engine)，以及招牌的 Project Factory。

取用 CFT 模組

module "vpc" {
  source  = "terraform-google-modules/network/google"
  version = "~> 9.1"

  project_id   = "acme-prod-host"
  network_name = "shared-prod-vpc"
  subnets = [{
    subnet_name   = "ae1-app"
    subnet_ip     = "10.20.0.0/20"
    subnet_region = "asia-east1"
  }]
}

鎖定 version 至關重要，否則下游一次大版本變更可能在下次 terraform apply 對網路造成破壞性改動。

版本控制與驗證

CFT 模組附帶自家整合測試（kitchen-terraform、blueprint test 框架）、CHANGELOG 與 SemVer 保證。PCD 考試可能會區分 CFT 模組與隨機社群模組：CFT 模組是 Google 維護、有簽署、針對 Forseti / Policy Library 測試過；Registry 上的隨機模組則沒有。

Project Factory 與 Resource Manager Tag

Project Factory 模式

terraform-google-project-factory 模組把 專案建立 標準化：帳單、API、預設 service account、網路掛載與標籤都集中在一處強制執行。典型 landing zone 在 for_each 迴圈內帶入業務單位 map，用幾百行 HCL 產出數十甚至上百個專案。

module "project" {
  source  = "terraform-google-modules/project-factory/google"
  version = "~> 16.0"

  name              = "acme-payments-prod"
  org_id            = "111122223333"
  billing_account   = "0123AB-456789-CDEF01"
  folder_id         = "folders/4444555566"
  activate_apis     = ["run.googleapis.com", "pubsub.googleapis.com"]
}

Resource Manager Tag 加 IAM Condition

Resource Manager Tag 是綁定於 project/folder/org 的鍵值對（例如 env=prod、dataclass=pii），並餵給 IAM Condition 來界定權限範圍。Terraform 的模式是用 google_tags_tag_key 與 google_tags_tag_value 定義鍵值，再用 google_tags_tag_binding 掛載，接著撰寫 IAM 政策，使該 role 僅在 resource.matchTag('111122223333/env', 'prod') 時生效，達成 prod 限定存取而不必逐專案綁定。

Config Connector：Kubernetes 風格的宣告式 IaC

Config Connector 是什麼

Config Connector (KCC) 是 Google 自製的 Kubernetes operator，將 Google Cloud 資源以 Custom Resource Definitions (CRDs) 形式暴露。安裝在 GKE 叢集後（通常透過受管的 Config Controller），即可 kubectl apply -f bucket.yaml，由 KCC 呼叫 Cloud Storage API 來和解 StorageBucket 資源。

何時用 KCC 而非 Terraform

當你的平台團隊已在 GKE 上以 Config Sync 或 Argo CD 等 GitOps 工具運作，並希望用同一個 Kubernetes 和解迴圈來管理 GCP 基礎設施時，KCC 即是首選。漂移偵測是持續的（控制器持續再和解），而 Terraform 只有顯式 apply 才會跑。代價是：KCC 的資源目錄比 Terraform google provider 小，且缺少 plan 式的差異預覽。

CRD 範例

apiVersion: storage.cnrm.cloud.google.com/v1beta1
kind: StorageBucket
metadata:
  name: acme-logs-bucket
  namespace: acme-prod
spec:
  location: ASIA-EAST1
  uniformBucketLevelAccess: true
  versioning:
    enabled: true

認證

KCC 透過 GKE 的 Workload Identity 認證：在控制器的 KSA 上加註 iam.gke.io/gcp-service-account，對應到一個持有管理資源所需 GCP 角色的 GSA。與 HCP Terraform 一樣是 WIF 心智模型，只是來源換成 Kubernetes Pod 身分而非 OIDC token。

在 Cloud Build Trigger 內執行 Terraform Plan

CI/CD 流水線形狀

Google 文件「Managing IaC with Terraform and Cloud Build」的參考架構把流水線拆成兩個 trigger：

1. PR trigger：對 main 發出 pull request 時，跑 terraform fmt -check、terraform validate，再跑 terraform plan 並把 plan 結果以 PR 留言張貼。
2. 合併 trigger：推到 main 時，對 production state 跑 terraform apply -auto-approve。

cloudbuild.yaml 範例

steps:
- name: 'hashicorp/terraform:1.7'
  entrypoint: sh
  args: ['-c', 'terraform init && terraform plan -no-color -out=tfplan']
- name: 'hashicorp/terraform:1.7'
  entrypoint: sh
  args: ['-c', 'terraform show -json tfplan > plan.json']
artifacts:
  objects:
    location: 'gs://acme-tfplans/$BUILD_ID'
    paths: ['tfplan', 'plan.json']
options:
  logging: CLOUD_LOGGING_ONLY
serviceAccount: 'projects/acme-cicd/serviceAccounts/[email protected]'

Cloud Build service account 只授予所需最低 project 層級角色（沙盒典型為 roles/editor，prod 更嚴格），且當由 GitHub Actions 或 GitLab 觸發時改用 Workload Identity Federation，而非 Cloud Build 原生 trigger。

保存 plan 產物

Plan 產物進入一個專屬 GCS 貯存桶，物件生命週期 30 天後自動刪除，方便稽核者回答「Terraform 在 2026-03-04 究竟改了什麼？」時重播該 JSON plan。

Pulumi：替代的 IaC 引擎

Pulumi 為何存在

Pulumi 是開源 IaC 工具，讓你以 真正的程式語言 撰寫基礎設施 — TypeScript、Python、Go、C#、Java — 而非 HCL。底層同樣呼叫 Google Cloud API（透過 @pulumi/gcp 套件）、支援遠端 state（Pulumi Cloud、S3、GCS），並提供類似 terraform plan / apply 的預覽/套用語意。

Pulumi 與 Terraform 取捨

• Pulumi 優勢：完整語言能力（迴圈、條件、類別、用 Jest/pytest 寫單元測試）、TS/Go 強型別、共用 helper 為 npm/pip 套件更容易。
• Terraform 優勢：生態系更大、Google 維護的 CFT 模組、HCP Terraform 企業治理、社群範例豐富、業界事實標準。

範例

import * as gcp from "@pulumi/gcp";

const bucket = new gcp.storage.Bucket("acme-logs", {
  location: "ASIA-EAST1",
  uniformBucketLevelAccess: true,
  versioning: { enabled: true },
});

考試相關度

在 PCD 中，只有當場景明確寫「團隊想用 TypeScript 撰寫基礎設施並以 Jest 跑單元測試」時，Pulumi 才是答案。其餘通用 GCP IaC 題目，預設仍是 Terraform。

白話文解釋

類比 1：建築藍圖

IaC 就是建築物的數位藍圖。在 Console 點按鈕等於僱用日薪工人靠記憶堆磚；把 Terraform plan 餵給 Google Cloud STS 支撐的 runner，等於把藍圖餵給一台 3D 列印機：同樣的輸入永遠產出同樣的建築，任何偏差都會被回報為漂移。Deployment Manager 是 Google 自家舊型列印機；Terraform 是整個業界採用的列印機，所以 Google 正在淘汰自家機種，並以 Cloud Foundation Toolkit 作為新列印機的擴充卡匣。

類比 2：撤銷按鈕

沒有 IaC 時，誤刪資源等於一場恐慌的 Slack 串接加上工單復原；有了 Terraform 加 GCS backend、物件版本管理 與 狀態鎖，撤銷按鈕就是 git revert 加上 terraform apply：列印機讀取昨天的藍圖，重新蓋出昨天的建築。HCP Terraform 再加上第二層安全網：每次 apply 都記錄 OIDC token 中的使用者身分，所以稽核問「誰按了撤銷？」會有具名答案。

類比 3：萬用轉接頭

google 與 google-beta provider 就像 Type-C 與 Thunderbolt 線：外型相同、能力等級不同。兩種都能插到 Terraform CLI，但 Thunderbolt（google-beta）承載的是可能在無預警下變更的預覽功能。Workload Identity Federation 則是線材內證明真品的晶片：不能用假的 JSON 金鑰，只接受密碼學上綁定 CI runner 身分的短期 STS token。

考試技巧與陷阱

常見陷阱

• 陷阱：在 2025 年以後的全新工作負載中選擇 Deployment Manager。技巧：新專案已停用，選 Terraform。
• 陷阱：為 HCP Terraform 認證選「每 90 天輪替 service account JSON 金鑰」。技巧：用 Workload Identity Federation，不要長期金鑰。
• 陷阱：把 terraform.tfstate 存進 Git repo。技巧：使用 GCS backend 搭配版本管理與狀態鎖；state 絕不入 Git，內含機敏資料。
• 陷阱：把 label 與 Resource Manager Tag 混為一談。技巧：只有 tag 能驅動 IAM Condition。
• 陷阱：通用 IaC 題目選 Pulumi。技巧：除非情境明確要求 TypeScript/Python，否則預設 Terraform。

高價值背誦

依優先順序記住四個 IaC 引擎：Terraform（預設）、Config Connector（GKE/GitOps 場景）、Pulumi（指定 TS/Python 語言時）、Deployment Manager（僅限既有遷移）。記住三個安全預設：WIF 優於 JSON 金鑰、GCS backend 加鎖、Cloud Build 採用最小權限 runner 身分。

常見問題 (FAQs)

Q1：Deployment Manager 會被停用嗎？

A1：會的，2024 年 Google 公告 Deployment Manager 在截止日後建立的新 Google Cloud 專案中將不再可用。現有 deployment 仍可運作，但所有新架構都應預設使用 Terraform 加 hashicorp/google provider。PCD 考試遇到任何全新題目都期待你選 Terraform。

Q2：IaC 中如何處理機敏資料？

A2：絕不在 .tf 或 .yaml 檔中硬編碼機敏資料。請存入 Secret Manager，在 apply 時透過 google_secret_manager_secret_version data source 引用，並透過 Cloud Run / GKE 的 secret 掛載方式提供給執行階段工作負載。CI runner 認證請使用 Workload Identity Federation，這樣就完全沒有 JSON service account 金鑰存在。

Q3：該用 google 還是 google-beta？

A3：穩定 GA 資源預設用 google。只有需要預覽功能時，才以 provider = google-beta.beta 別名在個別資源上使用 google-beta，並規劃功能升 GA 後遷回 google：預覽語意可能不需大版本變更就改變。

Q4：GCS 的狀態鎖實際上怎麼運作？

A4：自 Terraform 1.4 起，GCS backend 採用 GCS 物件 generation 與 If-Match precondition 的原生鎖。Terraform 寫入一個 default.tflock 物件；併發執行收到 HTTP 409 並退避。不需要 Cloud Spanner 或外部資料庫，貯存桶啟用物件版本管理以策安全即可。

Q5：何時該選 Config Connector 而非 Terraform？

A5：當你的平台已運行於 GKE 且採用 GitOps（Config Sync、Argo CD），希望透過 Kubernetes 控制器持續和解漂移時，選 Config Connector。當你需要 plan 式預覽、最廣的資源目錄、HCP Terraform 治理或多雲可攜性時，選 Terraform。

Q6：HCP Terraform 如何在沒有金鑰的情況下認證到 GCP？

A6：HCP Terraform 鑄造一個只對 workspace 有效的 OIDC token。Google 的 Security Token Service (STS) 透過信任 app.terraform.io 簽發者的 Workload Identity Pool + Provider，把該 token 換成模擬 Google service account 的短期聯邦化憑證。Terraform provider 再以這份憑證呼叫 GCP API：沒有 JSON 金鑰、完整稽核軌跡、自動輪替。

Q7：Pulumi 在 PCD 考試中是嚴肅的選項嗎？

A7：只有當情境明確要求以通用語言（TypeScript、Python、Go）撰寫 IaC 並進行單元測試時才提及 Pulumi。PCD 其餘所有 IaC 題目，預期答案都是 Terraform 加 google provider 加 GCS backend，可選用 Cloud Foundation Toolkit 模組與 Project Factory 加速。