基礎設施即程式碼與自動化

IaC 管的是變更，不只是建立資源

手動在 Console 建一個 VPC 並不難，困難的是半年後回答：當時為什麼這樣設？誰改過？測試環境和正式環境差在哪裡？如果重建，會不會少一條路由？

Infrastructure as Code（IaC）把期望設定寫成可版本控制的檔案，讓變更可以 review、preview、執行和追蹤。它能提高一致性，但不會自動保證每次結果完全相同：provider version、API default、外部資料、quota 和人工變更都可能造成差異。因此 IaC 還要搭配版本鎖定、state、測試和 drift 管理。

Terraform 的三份真相

排查 Terraform 問題時，分開看三件事：

1. Configuration：程式碼希望環境長什麼樣子。
2. State：Terraform 記得哪些 resource instance，以及它們和遠端資源的對應。
3. Remote system：Google Cloud 現在真正存在的資源。

terraform plan 會比較這三者並提出動作。它不是永久有效的承諾；plan 之後若 configuration、state 或遠端資源改了，apply 結果也可能不同。

Provider 與版本

google provider 提供穩定版資源與欄位；google-beta 可在功能正式進入 stable provider 前提供支援。Beta 不等於永遠不能用於 production，stable 也不代表沒有升級風險。應根據功能成熟度、支援狀態和變更風險決定，並鎖定 provider constraints、提交 dependency lock file、在升級前跑 plan 和測試。

State 要像敏感營運資料一樣保護

團隊不應把 production state 留在個人筆電。使用 Cloud Storage remote backend 時，至少考慮：

• 開啟 uniform bucket-level access 與 public access prevention。
• 用 IAM 限制能讀寫 state 的 principal，因為 state 可能包含敏感值。
• 開啟 Object Versioning，並用 lifecycle policy 控制舊版本成本。
• 視要求使用 CMEK、audit logs 與分離管理專案。
• 避免 force_destroy，並為 bucket 刪除設保護流程。

GCS backend 支援 state locking，能降低同時 apply 的衝突，但 pipeline 仍應避免多個 job 操作同一份 state。一般也不建議直接替 state bucket 加不可逆的 retention lock；Terraform 需要更新和刪除 state object，鎖錯可能讓正常操作卡住。

可參考 Google 的 Store Terraform state in Cloud Storage 範例，再依組織要求縮小權限。

Module 是介面，不是複製貼上

Module 可以把常見的 VPC、project 或服務設定封裝成團隊介面。好 module 通常具備：

• 清楚而少量的 inputs，不把 provider 每個欄位都原樣暴露。
• 安全預設值，危險選項需要明確開啟。
• Outputs 能支援後續組合，不洩漏不必要的敏感資料。
• Semantic version、upgrade notes 和自動化測試。
• Ownership，知道誰負責 review provider 變更與修補。

Cloud Foundation Toolkit（CFT）提供 Google 維護的 Terraform modules 和 blueprints，可作為 landing zone 與常見架構的參考或起點。採用前仍要 review 版本、輸入、組織政策與營運模型；官方 module 不是「不用理解就直接套用」。

三種常見執行方式

自管 Terraform pipeline

把 Terraform 放在 Cloud Build、GitHub Actions 或其他 CI 平台，適合已有成熟 pipeline、需要自訂測試和多雲整合的團隊。相對地，團隊要自行管理 runner、credentials、state、concurrency 和 approval flow。

Infrastructure Manager

Infrastructure Manager（Infra Manager）是 Google Cloud 的受管理 IaC 服務，以 Terraform configuration 部署和管理 Google Cloud infrastructure。它提供 deployment、revision、preview，並替每個 deployment 管理相關 state 和執行環境。

它適合希望使用 Terraform、但不想自己組整套 apply runner 和 state workflow 的團隊。Infra Manager 管的是基礎設施生命週期；應用版本的漸進式交付仍要用 Cloud Build、Cloud Deploy 或其他交付工具。詳情可看 Infrastructure Manager overview。

Config Connector

Config Connector 透過 Kubernetes CRDs 和 controllers 管理支援的 Google Cloud resources。團隊提交 Kubernetes object，controller 持續把實際資源 reconcile 到 spec 所描述的 desired state，並在 status 和 events 回報結果。

它適合已經以 Kubernetes API、RBAC 和 GitOps 工作的團隊，但要接受：

• Reconciliation 是 eventual consistency，不是 apply 完立刻全部就緒。
• 支援資源和欄位要查 Config Connector reference。
• Controller 需要雲端權限，刪除 policy 與 resource ownership 要先定義。
• Kubernetes etcd 不是一句話就能取代所有 state 思考；desired state、observed status 和外部 resource lifecycle 仍要管理。

Terraform 和 Config Connector 都能管理 Google Cloud 資源。選擇重點是團隊工作流、控制面、資源支援與 ownership，避免同一個資源同時被兩套 controller 管理。

一條安全的 Terraform pipeline

Production pipeline 可以拆成這幾步：

1. PR 執行 fmt、validate、lint、module tests 與 policy checks。
2. 使用固定版本的 Terraform 和 providers 產生 plan。
3. 保存 machine-readable plan artifact、摘要與執行身分，供 reviewer 檢查 create／update／delete／replace。
4. 高風險環境需要獨立核准；核准者不應只看「plan succeeded」。
5. Apply 使用專用 service account 和最小權限，優先透過短效憑證／service account impersonation，不在 repository 存長效 key。
6. Apply 後執行 smoke test、policy verification 與監控檢查。
7. 失敗時保存 log 和 state，不要讓多個人同時手動重跑。

不要在每個 merge 後無條件自動 apply production。是否自動化到哪一步，要看變更風險、blast radius、法規與團隊的復原能力。

Source repository 的現況

Cloud Build 可以和 GitHub、GitLab、Bitbucket 等來源整合，也可依需求使用 Secure Source Manager。Cloud Source Repositories 從 2024-06-17 起已不提供給新客戶，因此不應再把它寫成所有新架構的預設程式碼來源。既有客戶要依官方支援狀態規劃。

GitOps、Config Sync 與 Policy Controller

GitOps 把版本庫當作 desired configuration 的來源，controller 持續同步和回報 drift。在 GKE 環境中：

• Config Sync 同步 Kubernetes configuration。
• Policy Controller 對送進 Kubernetes API 的 objects 執行 policy constraints。
• Config Connector 可把支援的 Google Cloud resources 表示成 Kubernetes objects。

因此「Policy Controller 能禁止公開 Cloud Storage bucket」只有在該 bucket 透過受支援的 Config Connector object 管理、且 constraint 有涵蓋時才成立。它不會自動攔住所有人在 Console、Terraform 或 API 建的任意 bucket。組織層級的強制控制仍要評估 Organization Policy、IAM 與其他 Google Cloud controls。

Drift 也不應一律自動改回去。緊急 incident 期間的手動修復若被 controller 立刻覆蓋，反而會擴大問題。團隊要定義 break-glass 流程、暫停 reconciliation 的方式，以及事後把改動帶回 Git 的責任。

Deployment Manager 已停止服務

Google Cloud Deployment Manager 已在 2026-03-31 停止服務，API 和 gcloud deployment-manager 功能不再可用。過去由 Deployment Manager 建立的個別 Google Cloud resources 仍會運作，也能用一般產品工具管理，但不能再靠 Deployment Manager 更新。

現在遇到舊 Deployment Manager 環境，工作不是在選擇題裡背「Terraform 比較新」，而是：

1. 盤點 deployment、template、依賴和實際 resources。
2. 決定使用 Infra Manager、自管 Terraform 或其他工具。
3. Import／adopt 既有 resources，確認 configuration、state 和 remote system 一致。
4. 先在低風險環境演練，避免 migration 意外重建 production resources。

官方狀態與遷移說明見 Deployment Manager deprecation。

Cloud Shell 與 Cloud Code 放在哪裡？

Cloud Shell 提供瀏覽器中的臨時開發與管理環境，預裝 gcloud、Terraform、kubectl 等常用工具，適合快速診斷和教學。它不是 production pipeline，也不應成為只有某個人知道怎麼操作的部署主機。

Cloud Code 是 VS Code 與 IntelliJ 的開發擴充，協助本機開發、瀏覽 Google Cloud resources，以及處理 GKE、Cloud Run 等工作流。兩者提高個人操作效率，但治理仍要回到 repository、pipeline、IAM 和 audit trail。

情境練習：建立多團隊 landing zone

假設平台團隊要替 20 個產品團隊建立 folders、projects、Shared VPC 和安全基線。可以這樣設計：

1. 先定義 folder／project ownership、billing、network 和 security boundaries。
2. 評估 CFT modules，但用自己的 tests 和 policies 驗證輸出。
3. 將 organization、network 和 workload stacks 拆成 blast radius 合理的 states，不把全公司塞進一份 state。
4. State bucket 放在受控管理專案，開啟 versioning、PAP、UBLA 和最小權限。
5. PR pipeline 產生 plan；平台 reviewer 檢查 replace／delete 和 IAM 變更；production apply 使用專用 service account。
6. 部署後驗證 Organization Policy、log sinks、Shared VPC attachments 和必要告警。
7. 每次 provider／module 升級先在測試 organization 或低風險 stack 驗證。

這樣 IaC 才是治理流程，而不是把 Console 點擊翻譯成 HCL。

本課檢查清單

• IaC 提高可重現性，但 provider、default、state、quota 和人工變更仍會造成差異。
• Terraform configuration、state 和 remote resources 是三個要分開檢查的狀態。
• Remote state 要限制讀寫、保留版本並避免互相衝突的 apply。
• CFT 是可評估的 module／blueprint 起點，不是每個 landing zone 都必須照抄。
• Infra Manager 管受管理的 Terraform infrastructure deployment；Config Connector 使用 Kubernetes reconciliation。
• Production pipeline 要保留 plan、核准、短效身分、apply 結果與驗證紀錄。
• Deployment Manager 已在 2026-03-31 停止服務，既有資源要遷移管理方式。
• GitOps policy 只會控制它實際看得到的 objects，不能取代組織層 controls。

延伸閱讀

• Terraform on Google Cloud
• Infrastructure Manager overview
• Config Connector overview
• Managing infrastructure as code with Terraform and Cloud Build

下一步

下一課會進入安全與合規。你會看到 IaC 流程中的 service account、組織政策和資料邊界，如何和 IAM 架構接在一起。