Google PCD: 持續交付、組態與基礎設施自動化 — 學習指南
屬於 Google Professional Cloud Developer — 學習指南. 使用經過驗證的解答練習： Google 考試中心, 或參加限時模擬考試： ExamRoll.io.
總覽
Google Cloud 上的持續交付整合了建置自動化、artifact 管理、部署協調、基礎設施即程式碼 (infrastructure as code)，以及強健的治理機制，以重複且安全地交付變更。穩健的 pipeline 將不可變的 artifact 和宣告式設定，與政策及稽核能力結合。本節將說明在端對端實作 Cloud Build、Cloud Deploy、Artifact Registry、Terraform、Kubernetes、功能旗標 (feature flags) 和治理控制項時的設計選擇、操作實務和常見的失敗模式。
建置與部署協調
Cloud Build
- 觸發條件 (Triggers)：將建置作業與來源事件（例如分支推送、標籤、PR）或排程連結。建議使用分支或標籤的 regex，以確保只有預期的 ref 會觸發。觸發條件可以指定特定的服務帳戶執行，以強制執行最低權限原則；如果建置需要廣泛的 API 存取權限，請勿依賴預設帳戶。
- 建置步驟 (Build steps)：每個步驟都在一個容器中執行。當預設的工具鏈不足時，可使用專門的建置工具 (如 docker、gcloud) 或自訂建置工具。將編譯、單元測試、整合測試、程式碼風格檢查 (lint)、安全性掃描和 artifact 封裝等步驟分開，以便在發生故障時能歸因並有效利用快取。
- 替代變數 (Substitutions)：使用內建變數 (如 PROJECT_ID、SHORT_SHA) 和自訂替代變數 (以
$_為前綴) 進行參數化建置。避免將環境特定的值寫入建置邏輯中；應將它們作為替代變數傳入，或在部署時再解析。 - 服務帳戶 (Service accounts)：Cloud Build 服務帳戶 (PROJECT_NUMBER@cloudbuild.gserviceaccount.com) 需要明確的角色（例如，Artifact Registry 寫入權限、Cloud Deploy 發布版本管理員）。應為每個專案指派最小權限的角色和範圍。對於私有資源，請使用具備 VPC 連線能力的 Private Pools。
- Artifacts：將不可變的映像檔發布到 Artifact Registry，並可選擇透過
artifacts區塊將非容器的 artifact 上傳到 Cloud Storage。使用語意化版本和 commit digest 兩者來標記映像檔；在部署中使用映像檔 digest 以避免標籤漂移 (tag drift)。
Cloud Build 設定範例：
cloudbuild.yaml: steps:
- name: gcr.io/cloud-builders/docker args: [“build”,"-t","$REGION-docker.pkg.dev/$PROJECT_ID/app/app:${SHORT_SHA}","."]
- name: gcr.io/cloud-builders/docker args: [“push”,"$REGION-docker.pkg.dev/$PROJECT_ID/app/app:${SHORT_SHA}"]
- name: gcr.io/cloud-builders/gcloud args: [“deploy”,“releases”,“create”,“app-${SHORT_SHA}”,"–delivery-pipeline=app-pipeline","–images=app=$REGION-docker.pkg.dev/$PROJECT_ID/app/app@sha256:${COMMIT_SHA}"] substitutions: _REGION: us-central1 serviceAccount: projects/$PROJECT_ID/serviceAccounts/cb-deployer@$PROJECT_ID.iam.gserviceaccount.com
觸發條件範例： gcloud builds triggers create cloud-source-repositories –repo=my-repo –branch-pattern=^main$ –build-config=cloudbuild.yaml –service-account=cb-deployer@$PROJECT_ID.iam.gserviceaccount.com
Cloud Deploy
- 交付 pipeline (Delivery pipelines) 定義了有序的階段 (stages) 和目標 (targets)。目標會參照 GKE 叢集、Cloud Run 服務或其他支援的執行環境。將生產階段標記為
requireApproval以管制晉升 (promotion)。 - Rollouts 將一個發布版本 (release) 對應到一個目標；晉升 (promotion) 則是將發布版本推進到下一個目標。使用漸進式交付（金絲雀、藍/綠部署）和掛鉤 (hooks) 進行部署前/部署後檢查。
- 失敗模式：使用可變的標籤會導致非預期的升級；務必鎖定 digest。部署者帳戶缺少 IAM 權限會阻礙 rollout。無法渲染的 manifest 或環境特定設定的漂移會導致晉升失敗；應在建置期間驗證 manifest。
Cloud Deploy 定義範例：
delivery-pipeline.yaml: apiVersion: deploy.cloud.google.com/v1 kind: DeliveryPipeline metadata: name: app-pipeline serialPipeline: stages:
- targetId: dev
- targetId: prod strategy: standard: verify: true requireApproval: true
targets.yaml: apiVersion: deploy.cloud.google.com/v1 kind: Target metadata: name: dev gke: cluster: projects/PROJECT/locations/REGION/clusters/DEV_CLUSTER
生產環境目標定義
apiVersion: deploy.cloud.google.com/v1 kind: Target metadata: name: prod gke: cluster: projects/PROJECT/locations/REGION/clusters/PROD_CLUSTER
發布版本與晉升： gcloud deploy releases create app-20260903-1 –delivery-pipeline=app-pipeline –region=us-central1 –images=app=us-central1-docker.pkg.dev/PROJECT/app/app@sha256:IMAGE_DIGEST gcloud deploy releases promote –delivery-pipeline=app-pipeline –release=app-20260903-1 –region=us-central1
Artifacts 與供應鏈完整性
Artifact Registry
- 存放庫 (Repositories)：為每個團隊或環境建立獨立的存放庫，以劃定 IAM 範圍和清理作業。在建置工具和執行環境附近使用區域性存放庫，以減少出口流量和延遲。套件格式包括 Docker 映像檔和語言套件 (Maven、npm、PyPI)。
- 保留政策 (Retention)：定義清理政策以移除未被參照或過舊的標籤，並保留一個安全的回滾時間窗。避免過於激進的保留政策，以免刪除最後一個已知的良好版本。
- 來源證明 (Provenance) 與 SBOM：啟用建置來源證明，使映像檔帶有符合 SLSA 標準的證明。在建置期間產生 SBOM 並將其儲存為證明，以改善漏洞分類處理的效率。
- 漏洞掃描 (Vulnerability scanning)：啟用容器分析，並在偵測到沒有可用修補程式或政策例外的高嚴重性 CVE 時，中斷建置或阻止晉升。
- 權衡取捨：將所有 artifact 集中在單一專案中可簡化治理，但可能產生一個大的爆炸半徑；為每個環境或應用程式建立存放庫可降低風險，但會增加管理負擔。
供應鏈強制執行
- GKE 上的 Binary Authorization 可以要求證明（例如，「由專案 X 中的 Cloud Build 建置」、「無重大 CVE」）。與 Cloud Deploy 的管制關卡整合，以阻止不合規的發布版本。
- 失敗模式：依賴可變的標籤、停用掃描或未經驗證的拉取，都可能導致未經驗證的軟體進入生產環境。務必鎖定 digest 並要求證明。
基礎設施即程式碼與 GitOps
Terraform
- 設定與模組：將功能分解為可重複使用的模組，並具備清晰的輸入/輸出與語意化版本。將模組發布到共用的 repo 或 registry；鎖定版本以避免非預期的變更。
- 狀態 (State)：使用 GCS 後端來儲存遠端狀態，並搭配 bucket 層級的 IAM、物件版本控制與 CMEK。保護狀態免於人為編輯，並確保狀態有被加密。避免將密鑰存放在狀態中，應在 apply 時從 Secret Manager 讀取，並謹慎使用 data sources。 terraform { backend “gcs” { bucket = “tf-state-prod” prefix = “networking” } }
- 計畫與套用 (Plans and applies)：執行
terraform plan時加上-out參數，並透過人工或自動化閘門審查差異；只套用先前已核准的計畫。在漂移偵測作業中使用-refresh-only或-detailed-exitcode。 - 環境隔離：每個環境使用獨立的專案、狀態 bucket 及服務帳號。對於複雜的組織，偏好使用「每個環境一個目錄搭配變數檔」的方式，而非 workspaces。絕不在環境之間共用狀態。
- 失敗模式：同時執行 apply 會損毀狀態；透過 CI/CD 與鎖定 (locking) 來強制序列化執行 (GCS 使用物件先決條件)。手動在 console 變更會導致漂移；限制直接的變動，並定期執行 plan 作業。
Kubernetes 宣告式設定
- Manifests：保持 Kubernetes 物件為宣告式；在生產環境流程中避免使用 kubectl 指令式操作。鎖定 image digests 以及資源的 requests/limits。
- Kustomize：使用 base + overlays 的方式來處理針對特定環境的補丁，而不用 fork charts。
kustomization.yaml (overlay):
resources:
- ../../base patches:
- target:
kind: Deployment
name: api
patch: |
- op: replace path: /spec/replicas value: 3
- Helm：每個環境使用各自的 values files；文件化說明其優先順序 (命令列的 values 會覆寫 values files，而 values files 會再覆寫 chart 的預設值)。在 CI 中進行樣板化與渲染 (skaffold render 或 helm template)，如此一來，部署階段的設定檔就是不可變的。
- GitOps：將期望的狀態儲存在 Git 中。使用 Cloud Deploy 或 Config Sync 來將叢集與 Git 的狀態進行同步。PR 成為變更管制的介面，並具備稽核軌跡與政策檢查功能。避免使用
kubectl exec進行未被 Git 記錄的修改。
發布安全性、組態與治理
功能旗標與執行期組態
- 功能旗標將部署與發布解耦；交付休眠的程式碼，並依據不同群體、百分比或區域來啟用。將旗標定義儲存在低延遲、高可用性 (HA) 的系統 (如 Firestore、Memorystore) 中，並使用短 TTL 進行快取。記錄評估過程以供追蹤。
- 漸進式推出：結合流量分割 (Cloud Run) 或金絲雀子集 (GKE) 與功能旗標，以最小化衝擊範圍。使用健康指標和基於 SLO 的自動化回滾觸發器。
- 安全回滾：偏好透過功能旗標快速停用。若需進行二進位檔回滾，則提升 (promote) 上一個已知良好的版本，或重新套用先前的 manifest digest。
環境變數、優先順序與密鑰
- 優先順序通常遵循：執行期旗標 > 環境變數 > 組態檔 > 程式碼預設值。在所有服務中將此標準化並文件化。
- 使用 ConfigMaps 和環境變數注入組態；對敏感值使用 Secret Manager 或 Kubernetes Secrets。定期輪替，並避免將密鑰寫死 (bake) 在映像檔中。
- 密鑰注入範例：
- Cloud Run 環境變數：
undefined
- GKE Secret Manager CSI：
undefined
CI/CD 中的品質閘門
- 單元測試在每次 commit 時執行；快速回饋至關重要。
- 整合測試針對帶有種子資料的短暫環境或沙箱執行。
- 安全性檢查：SAST、依賴項掃描、容器漏洞掃描、IaC 政策檢查 (Conftest、Policy Controller)。若有重大發現，則阻擋合併或晉升。
- 部署檢查：Cloud Deploy 的部署前 (predeploy) 與部署後 (postdeploy) 動作會驗證就緒狀態、資料庫遷移的安全性以及煙霧測試。
分支、程式碼審查、版本控制與可追溯性
- 偏好使用基於主幹的開發 (trunk-based development)，搭配短生命週期的功能分支和強制性的 PR 審查。為了可稽核性，強制執行必要的檢查並維持線性歷史紀錄。
- 版本控制：發布版本使用語意化版本標籤；映像檔 digest 和 commit SHA 用於確保不可變性。在生產環境部署中，避免使用像
latest這樣會移動的標籤。 - 可追溯性：為建置和發布版本加上 commit、PR、工單 ID 的註解。將部署事件發送到 Logging；為資源附加標籤以利成本和所有權管理。
基礎設施漂移、政策、稽核與變更控制
- 漂移偵測：排程執行
undefined
；當 exit code 非零時發出警報。對於叢集，Config Sync 確保最終會收斂至 Git 的狀態。
- 政策強制執行：使用 Organization Policy 作為護欄 (例如，限制外部 IP)、使用 Policy Controller 進行 KRM 限制條件，以及使用 Binary Authorization 執行映像檔政策。
- 稽核日誌：啟用管理員活動 (Admin Activity) 和資料存取 (Data Access) 日誌；透過 sink 將日誌路由到集中的專案，並根據合規要求設定保留期限。Cloud Asset Inventory 提供變更歷史和存取分析的資料來源。
- 變更控制：對生產環境的晉升進行手動核准，並將理由記錄為註解。凍結期間 (Freeze windows) 可以編碼為 CI/CD 中的政策檢查。確保緊急回滾路徑有文件記錄並經過演練。
實務問題情境
Acme Retail 公司需要在開發 (dev) 和生產 (prod) 環境中，將一個新的訂單服務 (order-service) 部署到 GKE。部署過程需包含安全的金絲雀推出、嚴格的政策強制執行，以及完整的發布可追溯性。團隊必須標準化由 Terraform 管理的基礎設施、使用 Kustomize 的宣告式 Kubernetes 組態，以及使用 Cloud Build 和 Cloud Deploy 的可稽核 CI/CD 流程。
方法：
- 建立神器存放庫與身分
- 建立區域性的 Artifact Registry 存放庫
undefined
和
undefined
。將應用程式專案中的 Cloud Build 服務帳戶授予
undefined
角色，並將 GKE 執行節點授予對應存放庫的
undefined
角色。
- 理由：隔離的存放庫可減少衝擊範圍並簡化生命週期政策。明確的 IAM 設定可避免使用權限過大的預設值。
- 為基礎設施定義 Terraform，並進行環境分離
- 建立
undefined
和
undefined
目錄。每個組態都包含一個使用獨立 state bucket 的 GCS 後端、一個 GKE 叢集模組，以及 Cloud Deploy 服務帳戶的 IAM 綁定。在每個環境受管制的 CI 工作中，執行
undefined
、
undefined
和
undefined
。
- 理由：每個環境獨立的 state 和專案可防止意外的跨環境影響；plan 檔案則支援審查和可稽核的變更控制。
- 撰寫宣告式的 Kubernetes 基礎組態與 Kustomize overlays
- 將 Deployment、Service 和 HPA 的 Kubernetes manifest 檔案放在
undefined
中，並透過 digest 鎖定映像檔版本。在
undefined
和
undefined
中建立 replicas、資源請求和組態的補丁 (patches)。使用 Secret Manager CSI class 來處理資料庫憑證。
- 理由：使用 overlays 的單一事實來源 (Single source of truth) 可消除漂移，並讓組態保持 DRY (Don’t Repeat Yourself) 原則，同時能夠安全地實現特定於環境的差異。
- 實作 Cloud Build，並區分測試與打包步驟
undefined
包含以下步驟：程式碼風格檢查 (lint) 和單元測試、針對可拋棄的開發命名空間進行整合測試、建置容器並推送到對應環境的存放庫、SBOM 和漏洞掃描，以及來源證明 (provenance) 的生成。觸發器設定為對
undefined
分支的 PR 執行測試，並在合併後進行打包。建置工作以最低權限的
undefined
服務帳戶執行。
- 理由：早期失敗的成本較低；關注點分離可改善可觀測性，並實現有針對性的重試。最低權限原則可降低供應鏈風險。
- 設定 Cloud Deploy 交付管道，包含手動生產環境核准與金絲雀策略
- 定義一個包含 dev 和 prod 目標的 DeliveryPipeline。生產階段需要核准，並採用金絲雀策略 (例如，先 10% 再 100%)。使用部署前掛鉤 (predeploy hooks) 進行 schema 相容性檢查和煙霧測試；部署後 (postdeploy) 則驗證 SLO。
- 理由：漸進式交付可限制衝擊範圍並引入自動化的品質閘門，而手動核准則強制在生產環境部署時有人工介入。
- 串接 GitOps 與政策強制執行
- 透過要求審查和通過檢查來保護
undefined
分支。使用 Policy Controller 的限制條件來阻擋特權 pod 並禁止使用可變的標籤。啟用 Binary Authorization，要求在准入 (admission) 前必須有 Cloud Build 的來源證明和「無高風險 CVE」的證明 (attestations)。
- 理由：政策即程式碼 (Policy-as-code) 可防止有風險的組態進入叢集，並提供一致的強制執行。
- 管理組態與功能旗標以實現安全發布
- 將非密鑰的執行期組態儲存在 ConfigMaps 中；密鑰則透過 Secret Manager CSI 提供。引入一個名為
undefined
的功能旗標，從 Firestore 讀取，並在生產環境中初步推出 1%；旗標會以短 TTL 快取並記錄下來。
- 理由：旗標將發布與部署解耦，使得在問題出現時能夠立即停用功能，而無需回滾二進位檔。
- 確保可觀測性、漂移偵測與可追溯性
- 為建置和發布版本加上 commit SHA、PR 編號和變更工單的註解。將 Cloud Deploy 事件和 GKE 稽核日誌路由到一個中央的 Logging 專案。夜間的
undefined
工作會在偵測到漂移時發出警報；Config Sync 則監控 KRM 的分歧，並使其與 Git 同步。
- 理由：完整的來源證明和稽核軌跡可加速事件應對；持續的漂移偵測則維持基礎設施的完整性。
- 操作回滾與變更控制
- 發生事件時，首先透過旗標停用
undefined
。如有需要，在 Cloud Deploy 中將上一個成功的版本晉升 (promote) 到 dev 和 prod 環境。所有對生產環境的晉升都需要在發布註解中提供工單參考，並由值班的 SRE 核准。
- 理由：旗標提供即時的緩解措施；不可變的發布版本則實現了可預測的回滾。核准和註解滿足了營運治理和合規性的要求。
← 身分、驗證與應用程式安全 · 所有領域 · 可觀測性、偵錯與網站可靠性維運 →
練習這些題目 → · 在 ExamRoll.io 上限時練習 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
通過考試 →