CI/CD 流水線

GCP 中的 CI/CD 簡介

對於專業雲端架構師 (Professional Cloud Architect) 而言，CI/CD 流水線是雲端基礎設施的「神經系統」。它將程式碼轉換為客戶服務的過程自動化，從而減少人為錯誤並提高創新速度。

Google Cloud 提供了一套完全託管、無伺服器的 CI/CD 技術堆疊，能原生整合 GKE、Cloud Run 和 Compute Engine。核心三本柱為 Cloud Build（建置/測試執行器）、Artifact Registry（含 Artifact Analysis 的二進位/容器儲存庫）與 Cloud Deploy（多目標漸進式遞送）。圍繞它們的還有 Skaffold、Cloud Source Repositories、Binary Authorization 與 Workflows。

白話文解釋

比喻 1 — 自動拼字檢查器 (CI)

想像你在寫一本書。持續整合就像有一個神奇的拼字和語法檢查器，在你寫完每一句話的瞬間就會掃描。Cloud Build trigger 監看儲存庫；只要你 git push，建置步驟就會立即進行 lint、編譯與單元測試，這樣你就不會在發佈時才發現一整本充滿合併錯誤的「書」。

比喻 2 — 試吃員與評論家 (預發佈 vs 生產)

持續遞送就像一位廚師將菜餚擺盤後交給試吃員（Cloud Deploy staging target）。如果試吃員喜歡，這道菜就會放在出菜台上備妥。持續部署則是當自動化的 verify 任務已驗證過溫度、鹹度與擺盤之後，菜直接從鍋裡送到顧客桌上（prod target）— 過程完全無人介入。

比喻 3 — 淨水廠 (流水線)

CI/CD 流水線就像一座淨水廠。原水（原始程式碼）從一端進入。它會通過過濾器（lint）、化學處理（單元測試）、沉澱池（Cloud Build 中的整合測試）、紫外線殺菌（Artifact Registry 的漏洞掃描），最後到品評小組（Cloud Deploy 的 verify 與 approve）。只有 100% 純淨的水才能流入城市的水管（生產 GKE）。

三大支柱：CI、CD 與 CD

1. 持續整合 (Continuous Integration, CI): 自動化建置和測試流程。開發人員頻繁提交程式碼；系統會立即建置並執行單元測試。
2. 持續遞送 (Continuous Delivery, CD): 自動化通往測試或預發佈環境的路径。程式碼始終處於「可部署」狀態，但部署到生產環境可能仍需要手動點擊「推送部署」按鈕。
3. 持續部署 (Continuous Deployment, CD): 自動化通往生產環境的完整路徑。如果程式碼通過了流水線中的所有測試，它將自動推送給真實客戶。

GCP CI/CD 工具堆疊

1. Cloud Build (引擎)

一個無伺服器平台，在 Docker 容器中執行您的建置步驟。

• 觸發條件 (Triggers): 在 GitHub/GitLab 提交程式碼時自動啟動建置。
• 安全性: 與 Secret Manager 整合，在建置期間安全地處理 API 金鑰。

2. Artifact Registry (倉庫)

Container Registry 的進階演進版。它儲存 Docker 映像檔、Maven 套件和 npm 模組。

• 掃描: 上傳時自動掃描漏洞 (CVE)。

3. Google Cloud Deploy (導航員)

一項託管服務，可自動將應用程式遞送至 GKE、Cloud Run 或 Anthos。

• 發佈管理: 處理從 dev 到 prod 的升級流程，並具備內建的復原 (rollback) 能力。

Cloud Build 深度剖析 — Triggers、Substitutions、Private Pools、Cache

Cloud Build 不只是 YAML 執行器，而是整條流水線的執行基底。PCA 情境通常會圍繞如何選擇正確的 trigger 類型、為各環境注入 substitutions、在 default pool 與 private pool 之間抉擇，以及用對的 cache 策略壓縮建置時間。

Trigger 類型

• Push to branch — 最常見；以分支正則篩選 (^main$、^release/.*$)。
• Push new tag — 用於 release 建置；搭配 semver 標籤。
• Pull request — 執行 presubmit 檢查；結果以 GitHub status check 回寫 PR。
• Manual — 由 gcloud builds triggers run 觸發；適合熱修補或透過 Cloud Scheduler + Pub/Sub 排程重新建置。
• Webhook (inbound HTTPS) — 接收來自 Jira、PagerDuty 或任何能 POST JSON 的系統的事件。

Substitutions

Substitutions 將 context 注入到 cloudbuild.yaml：

• 內建：$PROJECT_ID、$BUILD_ID、$COMMIT_SHA、$SHORT_SHA、$BRANCH_NAME、$TAG_NAME、$LOCATION。
• 使用者自訂：以 _ 為前綴，例如 _REGION、_DEPLOY_TARGET。可在 trigger 或單次呼叫覆寫。
• Dynamic substitutions（在 options.dynamic_substitutions: true 下啟用）可使用 ${_FOO:-default} 形式的 fallback。

Private pools

Default pool 在 Google 託管的 tenant project 中執行，無法觸達 VPC。當建置步驟需要與私有 GKE 控制平面、透過 Cloud VPN/Interconnect 連線的地端主機，或透過 private IP 連到 Cloud SQL 通訊時，就必須使用 Private pool。Private pool 也可以固定 machine type（e2-medium → e2-highcpu-32）、worker 數量，以及為了符合 VPC-SC 而設定 egress（NO_PUBLIC_EGRESS）。

Cache 策略

• Kaniko cache (--cache=true --cache-ttl=6h) — 在 Artifact Registry 中的 layer cache；對含有大型 apt-get install 或 npm ci layer 的 Dockerfile 效益巨大。
• Cloud Storage cache — 手動在建置步驟前後 gsutil rsync node_modules、.m2、.gradle。
• Buildpacks — pack build 自動重用基礎映像 layer。

Cloud Deploy 深度剖析 — Targets、Canary、Postdeploy、Verify

Google Cloud Deploy 是一個有強烈意見的持續遞送服務。你不再寫自由形式的腳本，而是宣告一個 DeliveryPipeline 與一連串 Target 資源；Cloud Deploy 會強制執行晉級順序、復原、核准與稽核。

Targets

一個 Target 指向以下其一：GKE 叢集 (gke:)、Cloud Run 服務 (run:)、Anthos 叢集 (anthosCluster:)，或 multi-target（跨區域平行 fan-out）。每個 target 都有自己的 service account、execution config 與 requireApproval 旗標。

Canary 策略

在 strategy.canary 下定義：

strategy:
  canary:
    runtimeConfig:
      kubernetes:
        serviceNetworking:
          service: web
          deployment: web
    canaryDeployment:
      percentages: [10, 25, 50]
      verify: true

Cloud Deploy 自動建立 phase 資源、透過 Gateway API 或 Istio 分流，並在 phase 間暫停。percentages: [10, 25, 50] 表示在 100% 之前有三個中繼站 — 每個都可執行 verify 任務與 postdeploy hook。

Predeploy / Verify / Postdeploy

• Predeploy — 在 manifests 套用之前執行（例如透過 Cloud Build job 進行資料庫遷移）。
• Verify — 在 phase 達到 Succeeded 之後執行；整合測試、smoke test、合成監控。
• Postdeploy — 在 phase 完全 drain 後執行（例如更新 PagerDuty、發 Slack 訊息、執行 bq query 記錄部署）。

Rollback

失敗的 Rollout 會自動標記為 FAILED；一次點擊（或 gcloud deploy rollouts rollback）就能將上一個成功的 Release 重新晉級回 target。因為每個 release 都是 Artifact Registry 中不可變的成品，rollback 是 deterministic 的。

Artifact Registry + 容器掃描

Artifact Registry 是 Container Registry 的區域級繼任者。PCA 考題會從三個面向測驗：格式支援、區域擺放，以及透過 Artifact Analysis 的整合式漏洞掃描。

格式支援

• Docker / OCI — 給 GKE、Cloud Run、Cloud Build 基礎映像使用。
• Maven、npm、Python、Go、Apt、Yum — 在單一產品中提供語言與 OS 套件 repo。
• Remote repositories — 對 Docker Hub、Maven Central、PyPI 的 pull-through cache；避開速率限制，並讓 VPC-SC 叢集能取得外部依賴。
• Virtual repositories — 將多個 upstream repo 依優先序聚合在單一 endpoint。

區域擺放與複寫

Repositories 為區域級或多區域級。請挑選與消費端 GKE 叢集相同的區域以最小化 egress 與延遲。多區域 active-active 則建立每區一個 repo，並用 CI matrix 推送到所有區域。

容器掃描

Artifact Analysis 執行兩種掃描器：

• OS scan — Debian/Ubuntu/Alpine/CentOS 套件 CVE。
• Language package scan — Maven、npm、Python、Go 依賴 CVE。

掃描結果以 Occurrences 對應 Notes 形式產出，並整合：

• Cloud Build — 若發現 CRITICAL CVE 則建置失敗（gcloud artifacts docker images list-vulnerabilities）。
• Binary Authorization — 阻擋缺少「漏洞已清除」attestation 的映像。
• Security Command Center — 將結果浮上 SecOps。

Skaffold 用於 Inner-Loop 開發

Skaffold 是支撐 Cloud Deploy render 與 deploy phase 的開源 CLI — 同時也是縮短 kubectl apply 與 git push 之間回饋差距的內迴圈 (inner-loop) 開發工具。

skaffold dev 工作流

skaffold dev 監看本地檔案，用可用的最快 builder（Docker / Kaniko / Buildpacks / Jib）重新建置映像，推送到本地 registry 或 Artifact Registry，再 kubectl apply manifests 到你的 minikube / GKE Autopilot 開發叢集。日誌串流與 port-forwarding 都自動完成。

skaffold render 與 skaffold apply

Cloud Deploy 在 Release 建立時使用 skaffold render 將 Kustomize overlay 或 Helm template 物化成一組靜態 manifests — 該 render 後的輸出就是跨 targets 晉級的不可變成品。在每個 Rollout 時，skaffold apply（或 kubectl）才實際部署。這就是為什麼 Cloud Deploy 的 Release 是可重現的：manifests 已凍結在 Artifact Registry 中作為 Release 的一部分。

用 Profile 區隔各 target 設定

profiles:
  - name: prod
    patches:
      - op: replace
        path: /build/artifacts/0/image
        value: us-docker.pkg.dev/prod-proj/web/api
deploy:
  kubectl:
    manifests:
      - k8s/*.yaml

每個 Cloud Deploy Target 引用一個 Skaffold profile，因此 prod 可以有不同的映像 repo、replica 數或資源 quota，不必重複 YAML。

為何對 PCA 重要

若情境提到「開發人員抱怨微服務迭代時回饋緩慢」或「我們希望本地與 CI 使用同一工具」，那麼Skaffold 就是統一的答案 — 不是 Tilt、不是 Garden、也不是原生 kubectl。

Cloud Source Repositories vs GitHub 透過 Cloud Build

PCA 考生常會混淆這兩者 — 它們不是互斥的，正確答案取決於法遵、鏡像與 trigger 語義。

Cloud Source Repositories (CSR)

• 完全託管的私有 Git，託管在你的 GCP 專案內。
• 由 IAM 控管（無另外的使用者系統） — 可透過 Cloud Audit Logs 稽核。
• 可從 GitHub、Bitbucket、GitLab 鏡像 — 唯讀副本在每次 upstream push 時更新，對 VPC-SC 環境中無法 egress 到 github.com 的 build worker 很實用。
• Cloud Build trigger 類型：cloudSourceRepoEvent。

GitHub（主站）透過 Cloud Build GitHub App

• 多數團隊為了 PR 文化、code review、branch protection 而將原始碼留在 GitHub。
• Cloud Build 透過 Cloud Build GitHub App（建議）或 webhook trigger 連接。
• Trigger 類型：push、pull request、tag、manual。
• Status check 會回寫到 PR（可作為 branch protection 的 required）。

何時選哪個

• 氣隙或 VPC-SC 專案 — 將 GitHub → 鏡像到 CSR，用 private pool 從 CSR 建置。避開 github.com egress。
• 標準 SaaS 工作流 — 直接連 GitHub；由 Cloud Build GitHub App 處理 webhook。
• 受監管產業、稽核軌跡 — CSR 的每次 commit Cloud Audit Log entry 比 GitHub API 呼叫更容易在稽核時呈現。

GitHub Actions OIDC 連接 GCP

許多團隊在 CI 上標準化使用 GitHub Actions，但仍需部署到 GCP。現代化、無金鑰的模式是使用 Workload Identity Federation 搭配 GitHub 的 OIDC token — 不再有需要輪換或可能外洩的 JSON service account key。

設定步驟

1. 建立一個 Workload Identity Pool 與一個 OIDC 類型的 Provider，issuer 為 https://token.actions.githubusercontent.com。
2. 加入 attribute mapping（例如 attribute.repository = assertion.repository）以及 attribute.condition，例如 assertion.repository == 'my-org/my-repo'。
3. 建立 GCP service account、授予部署所需權限（roles/run.developer、roles/clouddeploy.releaser），並透過 roles/iam.workloadIdentityUser 讓 pool 能 impersonate 它。
4. 在 workflow 中使用 google-github-actions/auth@v2，傳入 workload_identity_provider 與 service_account 參數。

為何 OIDC 勝過 SA key

• 無長期憑證 — 短期 STS token（預設 1 小時）。
• 限定於 repo — attribute condition 確保只有對的 repo（或選擇性的 branch / environment）能換到 token。
• 可稽核 — Cloud Audit Logs 顯示 GitHub assertion subject（repo:my-org/my-repo:ref:refs/heads/main）。

常見陷阱

• 忘記設 attribute.condition — 會讓 provider 對任何 GitHub repo 開放（爆炸半徑極大）。
• audience 不一致 — 必須符合 provider 的完整資源名稱。
• 忘記在 service account 上授予 roles/iam.workloadIdentityUser。

用 Workflows 編排多叢集部署

當單一 DeliveryPipeline 無法滿足需求時 — 例如跨 50 個區域 GKE 叢集的 fan-out，或按順序部署 GKE + Cloud Run + Spanner schema — Workflows 是 GCP 原生的編排器。

Workflows 基礎

Workflows 執行 YAML/JSON 定義；每個步驟是一次 HTTP 呼叫或對 GCP 服務的 connector 呼叫。它支援平行分支、retry、條件邏輯，並能等待長時間執行的 operation。

多叢集 fan-out 模式

- parallel:
    shared: [release_name]
    for:
      value: cluster
      in: ${clusters}
      steps:
        - createRollout:
            call: http.post
            args:
              url: ${"https://clouddeploy.googleapis.com/v1/" + cluster.pipeline + "/releases/" + release_name + "/rollouts"}
              auth:
                type: OAuth2
              body:
                targetId: ${cluster.target}

這會平行啟動每個區域叢集的 Cloud Deploy Rollout，並透過 polling 等待所有完成。

跨服務編排

典型的「release weekend」workflow：

1. 執行 gcloud spanner databases ddl update 進行 schema migration。
2. 為 API 服務（GKE）建立 Cloud Deploy Release。
3. Release 抵達 prod 後，將靜態前端部署到 Cloud Run。
4. 透過 Cloud Functions 發送 Slack 通知。
5. 透過 GitHub API 為 Git commit 打 tag。

Workflows 與單獨 Cloud Deploy 的時機

Cloud Deploy 處理單一成品跨 N 個環境的晉級。Workflows 處理 M 個成品及 Cloud Deploy 並未原生建模的 side effect 之協調。兩者可組合：Workflows 呼叫 Cloud Deploy。

Build Approver 與手動核准閘門

即使完全自動化的流水線也需要為生產部署、涉及 GDPR 的變更，或變更凍結窗口設置人為閘門。GCP 在 Cloud Build 與 Cloud Deploy 兩層都提供核准 primitive。

Cloud Build 核准

在 trigger 上設定 approvalConfig.approvalRequired: true。trigger 觸發時，build 會進入 PENDING_APPROVAL 狀態。具有 roles/cloudbuild.builds.approver（不能是 trigger 建立者）的核准者，可在主控台點擊 Approve 或執行 gcloud builds approve。Pub/Sub 通知會發送到 cloud-builds-approvals topic，方便你路由到 Slack 或 PagerDuty。

Cloud Deploy 核准

在 Target 上設定 requireApproval: true。當 Release 晉級到該 target 時，Rollout 會停在 PENDING_APPROVAL，直到有 roles/clouddeploy.approver 的人透過 gcloud deploy rollouts approve 核准。重點是核准者不能是建立該 Release 的同一個身分 — 強制執行職責分離。

最佳實務

• 只在 prod target 要求核准 — dev/staging 維持完全自動化。
• 用 Google Groups 綁定 approver IAM，讓 on-call 輪值可運作。
• 透過 Pub/Sub → Cloud Functions → Slack 發送核准通知，並附核准 UI 的深連結。
• 同時啟用 Binary Authorization — 核准者為映像簽 attestation，叢集在 admission 時強制驗證（縱深防禦）。

稽核

每次核准都是一筆 Cloud Audit Log entry（google.devtools.cloudbuild.v1.CloudBuild.ApproveBuild / google.cloud.deploy.v1.CloudDeploy.ApproveRollout），附核准者 email、timestamp 與自由文字註解。將其匯入 BigQuery 以利變更管理報表。

Cloud Build Webhook Trigger

Webhook trigger 讓任何外部系統都能啟動建置 — 不限於 Git 服務商。它是 Jira、ServiceNow、自製 dashboard 甚至 Cloud Scheduler 的整合膠水。

運作方式

1. 建立一個 webhook 類型的 trigger。
2. Cloud Build 產生 URL：https://cloudbuild.googleapis.com/v1/projects/PROJECT/triggers/TRIGGER:webhook?key=API_KEY&secret=SECRET。
3. 將 secret 儲存在 Secret Manager 並在 trigger 設定中引用；Cloud Build 驗證收到的 secret query parameter。
4. 外部系統 POST JSON；body 透過 substitutions 以 $(body.commit_sha) 等形式在 trigger 中曝露。

使用情境

• Cloud Scheduler 夜間重新建置 — 即使原始碼沒變，也重新跑建置以套用新基礎映像的 CVE 修補。
• Jira ticket 流轉觸發部署 — Jira automation rule 在 ticket 移到 Ready for Prod 時 POST 到 webhook。
• Pub/Sub fan-out — Eventarc → Cloud Function → webhook 串接多個建置。
• ChatOps — Slack slash command → webhook → 建置執行。

安全性

• secret 透過更新 Secret Manager 版本來輪換；舊版本在停用前仍然有效。
• 搭配 API key 限制（HTTP referrer 或 IP）以及 VPC-SC（若呼叫端為內部）。
• 透過 Cloud Audit Logs 記錄入站 User-Agent 與來源 IP，並對異常設警報。

部署策略

GitOps：基礎設施即程式碼 (IaC)

現代 CI/CD 通常遵循 GitOps 模式。

• Git 儲存庫是應用程式程式碼和基礎設施的「單一事實來源」。
• Config Sync 或 Anthos Config Management 會監視 Git 儲存庫，並自動將變更套用到您的 GKE 叢集。

**架構師的選擇：**對於需要嚴格稽核軌跡的高度受監管環境，請使用 GitOps。對生產環境的每一次變更都會記錄在 Git 提交中，且沒人擁有對生產環境的「手動」存取權限。 ::

常見問題 — CI/CD 流水線

Q1. Cloud Build 只能用於 Docker 嗎？

不是。雖然它使用 Docker 容器來「執行」建置步驟，但您可以用它來建置任何內容 — Go 二進位檔、Java JAR 檔、Python 套件，甚至是部署 Terraform 配置。

Q2. 我該如何在流水線中處理祕密（如資料庫密碼）？

絕對不要將它們硬編碼在 cloudbuild.yaml 中。應將其儲存在 Secret Manager 中並在建置步驟中引用。Cloud Build 可以在執行時使用其服務帳戶解密。

Q3. 什麼是「復原 (Rollback)」，GCP 如何處理它？

復原是在部署失敗後返回上一個穩定版本。Google Cloud Deploy 透過單個按鈕或指令即可輕鬆實現，將環境重新指向之前的「發佈 (Release)」成品。

Q4. 我可以在 GCP 上使用 Jenkins 嗎？

可以，您可以在 Compute Engine 或 GKE 上執行 Jenkins。然而，對於「雲端原生」的方法，首選 Cloud Build，因為它是無伺服器的（您不需要管理 Jenkins 伺服器）且能自動擴充。

Q5. "Binary Authorization" 如何與 CI/CD 整合？

CI 流水線 (Cloud Build) 在映像檔通過測試後對其進行「簽署」。GKE 叢集配置為僅允許由該特定「證明者 (Attestor)」簽署的映像檔進行部署。

最後的架構師提示

在 PCA 考試中，如果您需要零停機時間，請選擇藍綠部署或漸進式更新。如果您需要以最小風險對真實使用者進行測試，請選擇金絲雀部署。對於多環境晉級 (Multi-environment promotion)（Dev -> Staging -> Prod），答案是 Google Cloud Deploy。始終確保您的流水線包含自動化測試和安全性掃描 (Artifact Analysis)。