跳至主要內容
登雲學院 CloudOn 登雲學院.
ESC
跳到課程內容
基礎架構管理與 AI/ML 基礎設施即程式碼與自動化
0%
11 / 25 中級 25 分鐘 00:00

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

掌握 Terraform、Cloud Build 與 GCP 開發工具鏈，學習基礎設施即程式碼（IaC）的架構最佳實踐與自動化策略

2026年3月13日 Updated: 2026年3月20日

為什麼架構師必須重視 IaC？

基礎設施即程式碼（Infrastructure as Code, IaC）不只是自動化工具——它是架構治理的基石。當你管理的環境從一個專案擴展到數十個、數百個專案時，手動操作 Console 不僅效率低落，更是風險的根源。

IaC 對架構師的核心價值在於四個面向：

  1. 可重現性（Reproducibility） — 同一份程式碼在任何環境部署都能得到一致的結果，消除「在我這邊可以跑」的問題
  2. 組態漂移防護（Drift Prevention） — 透過定期 plan/apply 循環，偵測並修正手動變更造成的環境偏移
  3. 合規即程式碼（Compliance as Code） — 安全策略、網路規則、IAM 權限全部版本控制，稽核時一目了然
  4. 災難復原（Disaster Recovery） — 整套環境可以從程式碼重建，RTO 從數天縮短到數小時

💡 考試小提示：PCA 題目常問「如何確保多環境一致性」或「如何加速災難復原」，答案幾乎都指向 IaC 搭配版本控制。

Terraform on GCP

Terraform 是 GCP 生態系中最主流的 IaC 工具，也是 PCA 考試的重點。以下是架構師需要掌握的關鍵概念：

Provider 與 State 管理

Terraform 透過 Google Provider（google）和 Google Beta Provider（google-beta）與 GCP 互動。兩者的差異很重要：

  • google — 僅包含 GA（正式發佈）的 API，適合生產環境
  • google-beta — 包含 Beta 功能，適合測試新功能，但 API 可能會有破壞性變更

State 檔案是 Terraform 的核心——它記錄了「程式碼宣告的狀態」與「實際環境狀態」的對應關係。生產環境必須使用遠端後端：

  • GCS Backend — 將 state 存放在 Cloud Storage bucket，啟用版本控制和物件鎖定（Object Locking）
  • State Locking — 防止多人同時執行 apply 造成衝突，GCS 原生支援

Modules 與可重用性

Terraform Modules 是架構師實現標準化的利器。將常用的資源組合（如「標準 VPC + Subnet + Firewall Rules」）封裝為模組，團隊只需傳入參數即可部署符合規範的基礎設施。搭配 Terraform Cloud/Enterprise 可以進一步實現：

  • 集中管理 state 和存取權限
  • Policy as Code（透過 Sentinel）
  • 跨團隊的模組註冊與版本管理

Cloud Foundation Toolkit（CFT）

Cloud Foundation Toolkit 是 Google 官方維護的一組生產等級 Terraform 模組，專門用於建立 GCP Landing Zone。CFT 涵蓋：

  • 組織階層（Organization Hierarchy） — 資料夾結構、專案工廠（Project Factory）
  • 網路基礎 — 共享 VPC、防火牆規則、Cloud NAT
  • 安全基線 — Organization Policy、VPC Service Controls、日誌匯出
  • IAM 設定 — 角色綁定、Service Account 管理

CFT 的價值在於，它將 Google 的最佳實踐直接編碼為 Terraform 模組，大幅降低從零搭建 Landing Zone 的風險和時間。對於企業級部署，CFT 幾乎是必備的起點。

💡 考試小提示：當題目描述「企業需要建立符合最佳實踐的 GCP 基礎環境」時，Cloud Foundation Toolkit 是首選答案。

Config Connector：Kubernetes 原生的 GCP 資源管理

Config Connector 讓你用 Kubernetes YAML 清單（manifest）來宣告和管理 GCP 資源。它作為 GKE 的 add-on 運行，將 GCP 資源映射為 Kubernetes Custom Resources。

Config Connector vs Terraform

面向TerraformConfig Connector
宣告語言HCLKubernetes YAML
State 管理獨立的 state 檔案（GCS）Kubernetes etcd（無額外 state）
適用團隊基礎設施團隊、平台團隊已有 Kubernetes 經驗的團隊
GitOps 整合需額外工具（Atlantis 等）原生支援 Config Sync
資源覆蓋範圍最廣（所有 GCP 服務）持續擴展中，部分服務尚未支援
最佳場景Landing Zone、跨專案管理應用團隊自助式管理 GCP 資源

選擇原則：如果團隊以 Kubernetes 為核心且想要 GitOps 工作流，選 Config Connector；如果需要管理整個組織層級的基礎設施，選 Terraform。

Cloud Build：CI/CD 引擎

Cloud Build 是 GCP 的全代管 CI/CD 服務，透過 cloudbuild.yaml 定義建置步驟。架構師需要掌握：

  • Build Triggers — 與 Cloud Source Repositories、GitHub、Bitbucket 整合，支援推送、合併請求和標籤觸發
  • Private Pools — 在 VPC 內執行建置，存取私有資源（如 Artifact Registry、內部 API），滿足安全合規需求
  • Cloud Deploy 整合 — Cloud Build 負責 CI（建置與測試），Cloud Deploy 負責 CD（跨環境的漸進式部署），兩者搭配形成完整的交付流水線

典型流程：程式碼推送 → Cloud Build 觸發建置 → 執行測試 → 推送 Container Image 至 Artifact Registry → Cloud Deploy 自動推進至 dev → staging → production。

Cloud Shell 與 Cloud Code

Cloud Shell

Cloud Shell 提供瀏覽器內的開發環境，預裝 gcloud CLI、Terraform、kubectl 等工具。Cloud Shell Editor 基於 Theia IDE，適合快速原型開發和臨時操作，但不適合大型專案的持續開發。

Cloud Code

Cloud Code 是 VS Code 和 IntelliJ 的擴充套件，提供：

  • GKE 叢集瀏覽與部署
  • Cloud Run 本地開發與除錯
  • Kubernetes 和 Cloud Run 的本地模擬器（Local Emulators）
  • Skaffold 整合，支援快速的內循環開發

自動化策略比較

面向TerraformConfig ConnectorDeployment Manager
狀態主流首選持續成長2025/12/31 已終止支援
管理範式宣告式（Declarative）宣告式（Declarative）宣告式（Declarative）
語言HCLKubernetes YAMLYAML/Jinja/Python
State 位置GCS / Terraform CloudKubernetes etcdGCP 服務內建
多雲支援是（AWS、Azure 等）否（僅 GCP）否（僅 GCP）
團隊工作流PR Review → Plan → ApplyGitOps + Config Sync不建議新專案採用

💡 考試小提示：Deployment Manager 已被 Google 標記為棄用。Deployment Manager 已於 2025/12/31 終止支援並關閉，所有現有部署必須遷移。如果題目選項中同時出現 Deployment Manager 和 Terraform，一律選 Terraform。

GitOps 與持續交付

GitOps 將 Git 倉庫作為基礎設施和應用配置的唯一事實來源（Single Source of Truth）。在 GCP 上實踐 GitOps 的關鍵元件：

  • Config Sync — 自動將 Git 倉庫中的 Kubernetes 配置同步到 GKE 叢集，偵測並修正組態漂移
  • Policy Controller — 基於 Open Policy Agent（OPA）/ Gatekeeper，在資源套用前執行策略檢查（例如：禁止建立公開的 Cloud Storage bucket）
  • Drift Detection — Config Sync 持續監控叢集狀態，若有人手動修改資源，會自動回滾至 Git 中定義的狀態

GitOps 的工作流程：開發者提交 PR → 自動化測試與策略驗證 → 合併至主分支 → Config Sync 自動同步至目標叢集。整個過程可稽核、可回滾、可追溯。

實戰情境

情境一：企業 Landing Zone 建置

背景：一家金融集團需要在 GCP 上建立符合金融監管要求的基礎環境，預計 20 個業務團隊共用。

架構決策：

  • 使用 Cloud Foundation Toolkit 建立組織階層：Organization → Folders（按業務線分） → Projects（按環境分）
  • 透過 Terraform Modules 封裝標準網路拓撲（共享 VPC + Private Service Connect）和 IAM 角色
  • State 存放於專用 GCS bucket，啟用版本控制和物件鎖定
  • 所有變更透過 Cloud Build 執行 terraform plan 和 terraform apply，需經 PR 審核後才能合併
  • Policy Controller 強制執行合規策略（如資料必須留在特定區域）

情境二：多環境持續交付流水線

背景：一個微服務團隊需要將應用從開發環境自動推進至生產環境。

架構決策：

  • 程式碼推送觸發 Cloud Build，執行單元測試和容器映像建置
  • 映像推送至 Artifact Registry，搭配漏洞掃描（Vulnerability Scanning）
  • Cloud Deploy 定義三階段交付流水線：dev → staging → production
  • 每個環境的 GCP 資源（Cloud Run 服務、Cloud SQL 實例）由 Terraform 管理，環境差異透過 .tfvars 檔案區分
  • 生產環境部署需要手動核准（Manual Approval），搭配 Canary 部署策略降低風險

重點整理

  • IaC 是架構治理的基石——可重現性、漂移防護、合規追蹤和災難復原都依賴它
  • Terraform 是 GCP 上 IaC 的首選工具，搭配 GCS backend 管理 state，用 modules 實現標準化
  • Cloud Foundation Toolkit 提供 Google 官方的生產等級 Terraform 模組，是企業 Landing Zone 的最佳起點
  • Config Connector 適合 Kubernetes 原生團隊，與 GitOps 工作流天然整合
  • Cloud Build + Cloud Deploy 組成完整的 CI/CD 流水線，Private Pools 滿足安全需求
  • Deployment Manager 已於 2025/12/31 終止支援——所有現有部署必須遷移至 Terraform，新專案一律使用 Terraform
  • GitOps + Config Sync + Policy Controller 實現可稽核、可回滾的持續交付

下一步

在下一課中，我們將進入安全與合規設計，深入 IAM 架構、Organization Policy、Workload Identity Federation 與 Chrome Enterprise Premium 的企業級身分管理策略。

徽章解鎖！