部署與自動化腳本

部署自動化簡介 (Introduction to Deployment Automation)

當基礎設施即程式碼 (IaC，如 Terraform) 負責處理「什麼」（期望的狀態）時，自動化腳本通常負責處理「如何」（操作程序）。一位 Professional Cloud Architect 必須熟練使用 gcloud CLI、Python 或 Bash 編寫強大的腳本，以協調複雜的部署、執行資料遷移並自動化重複性的操作任務。

白話文解釋 Deployment Automation

類比 1 — 自動灑水系統 (The Automatic Sprinkler System)

手動部署就像是用軟管手動幫花園澆水。你可能會漏掉某個角落或忘記某天要澆水。自動化腳本就像是自動灑水系統。你設定好時間和區域，它每次都能完美執行任務，即使你正在睡覺也是如此。

類比 2 — IKEA 組裝說明書對比機器人組裝手臂

Terraform 就像是 IKEA 說明書——它告訴你組裝完成後的書架應該長什麼樣子。自動化腳本則像是機器人組裝手臂，它實際拿起零件、塗膠水並按正確順序鎖上螺栓。機器手臂遵循說明書，但它增加了「動作」。

類比 3 — 飛行員的檢查清單

腳本就像是自動化的駕駛艙檢查清單。與其讓飛行員手動檢查每個開關，電腦會運行腳本來驗證每個系統是否都處於可以起飛的「Go」狀態。如果有一個開關錯誤，腳本會立即停止程序。

GCP 上的腳本工具

1. gcloud CLI： 最適合快速的管理任務和 Shell 腳本。使用 --format 和 --filter 讓腳本更強大且具備機器可讀性。
2. Python 客戶端函式庫 (Python Client Libraries)： 複雜邏輯的金科玉律。使用 google-cloud-* 函式庫以獲得豐富的錯誤處理能力和非同步操作支持。
3. Cloud Build： 不僅僅用於 CI/CD，它還是在安全、無伺服器環境中運行任意腳本的強大引擎。

自動化腳本的最佳實踐

• 錯誤處理： 永遠不要假設命令一定會成功。務必檢查 Bash 中的退出碼 (set -e) 或在 Python 中使用 try-except 區塊。
• 密鑰管理 (Secret Management)： 絕不硬編碼金鑰或密碼。使用 Secret Manager 在運行時獲取憑據。
• 日誌記錄： 輸出結構化日誌 (JSON)，以便 Cloud Logging 輕鬆解析。
• 服務帳戶冒充 (Service Account Impersonation)： 與其下載 JSON 金鑰，不如使用 --impersonate-service-account 以獲得更好的安全性。

自動化資料庫遷移

資料庫遷移是風險最高的自動化任務之一。

• 飛行前檢查 (Pre-flight Checks)： 驗證連線、權限和可用磁碟空間。
• 備份： 在遷移開始「之前」通過腳本觸發快照 (Snapshot)。
• 回滾策略 (Rollback Strategy)： 如果遷移腳本失敗，它必須能夠立即還原更改或通知相關人員。

架構師洞察： 在 PCA 考試中，如果問題詢問如何將自動化任務擴展到數千個資源，答案通常是從簡單的 Shell 腳本遷移到 Cloud Build 或託管工作流引擎（如 Google Cloud Workflows）。 ::

Cloud Build Triggers 與 Private Worker Pools

Cloud Build 是 GCP 上的無伺服器自動化主力。cloudbuild.yaml 檔案描述了有序的 build steps，每個 step 執行一個容器映像（例如 gcr.io/cloud-builders/gcloud、gcr.io/cloud-builders/docker）。Steps 透過共用的 /workspace volume 通訊，並可使用 waitFor 指令平行化執行。

Trigger 類型

• Push to branch / tag： 最常見的模式 — main 觸發 production 部署，feature branches 觸發 preview 環境。
• Pull request triggers： 在程式碼合併前執行 linting、unit tests、security scans。_PR_NUMBER substitution 讓你建立短暫的 preview URL。
• Manual triggers： 適用於需要核准才能執行的「break-glass」操作，例如資料庫遷移。
• Pub/Sub triggers： 從上游事件啟動 build，例如新的 artifact 出現在 Artifact Registry。

Private Worker Pools

Cloud Build 預設在共享的、短暫的 Google 託管 VM 上執行，並具有公開的對外網路存取。對於企業工作負載，這通常是不可接受的。Private Pools 是專用的 worker fleet，具備：

• 透過 Private Service Connect 進入你的 VPC，讓 builds 能存取 Cloud SQL Private IP、GKE private clusters，或透過 Cloud VPN / Interconnect 連接的地端系統。
• 遵守 VPC Service Controls 周邊，build steps 無法將資料外洩到公開 registries。
• 允許自訂 machine types（例如 e2-highcpu-32）以建置大型 monolith 專案。
• 按每個 pool 每分鐘計費，而非按 build 計費，因此需要謹慎預留容量。

典型的強化配置會使用沒有外部 IP 的 private pool、透過 --service-account 限縮範圍的 user-managed service account，以及儲存在 Secret Manager 中、透過 availableSecrets.secretManager 引用的 substitutions。

Build Provenance 與 SLSA Compliance

軟體供應鏈攻擊（SolarWinds、Codecov）讓 provenance 成為董事會層級的議題。GCP 透過在 Cloud Build 整合 SLSA (Supply-chain Levels for Software Artifacts) 來解決此問題。

GCP 上的 SLSA Levels

• SLSA Level 1： Build process 是腳本化的（任何 cloudbuild.yaml 都符合）。
• SLSA Level 2： Cloud Build 為每個 build 產生簽署過的 provenance metadata。
• SLSA Level 3： Builds 在強化、隔離的 Cloud Build infrastructure 上執行，具有無法偽造的 provenance — 這是託管 Cloud Build 的預設值。

Provenance Metadata

每個 build 會發出一份 JSON 文件，描述：

• Trigger（commit SHA、branch、repository URL）。
• 所使用的 builder image digests 確切值。
• Input materials 與產出的 artifacts，附帶 SHA-256 digests。
• 來自 Cloud Build 簽署金鑰的簽章，可透過 Sigstore / Cosign 驗證。

Provenance 儲存在 Artifact Analysis（前稱 Container Analysis）中，可透過 gcloud artifacts docker images describe --show-provenance 查詢。下游工具 — Binary Authorization、GKE admission controllers、Kritis — 可以在允許部署前要求有效的 SLSA-3 provenance。

對於 PCA，請記得：SLSA 關注的是「誰建置了這個以及如何建置」。如果場景提到「在部署前驗證 build 來自我們受信任的 CI pipeline」，答案就是 Cloud Build 所支援的 SLSA provenance 加上 Binary Authorization attestations。

Cloud Deploy：Targets、Custom Actions 與漸進式 Rollouts

當 Cloud Build 處理「建置」時，Cloud Deploy 處理「交付」 — 它是 GCP 對 GKE、Cloud Run、Anthos 有明確意見的託管 continuous delivery 服務。

Delivery Pipelines 與 Targets

clouddeploy.yaml 定義一個 Delivery Pipeline，包含有序的 Targets：通常是 dev → staging → prod。每個 target 指向一個特定的 GKE cluster、Cloud Run service 或 Anthos config。Targets 之間的 promotion 是明確的 gcloud deploy releases promote 呼叫，可選擇性地由 approvals（requireApproval: true）把關。

Render 與 Deploy Phases

Cloud Deploy 呼叫 Skaffold 以 target 特定的值（image tags、replica counts、namespaces）渲染 manifests，然後透過 target 的部署機制（kubectl apply、gcloud run services replace）套用。

Custom Target Types 與 Custom Actions

對於非原生 targets（Helm releases、Terraform stacks、Spinner pipelines），可以定義一個 Custom Target Type，由你自己的 container 實作 render 與 deploy actions。這是團隊將 Cloud Deploy 接入客製化環境而不放棄稽核軌跡的方法。

Canary 與 Progressive Rollouts

對於 GKE 與 Cloud Run，Cloud Deploy 支援自動化的 canary 策略（例如 10% → 50% → 100%），並透過 Cloud Monitoring SLOs 進行 metric-driven verification。驗證失敗會觸發自動 rollback 至前一個 release。

GitHub Actions 透過 OIDC 連接 GCP

許多組織標準化 CI 於 GitHub Actions，但仍需要部署到 GCP。傳統做法 — 將長期的 service account JSON key 儲存為 GitHub secret — 現在被認為是 anti-pattern：金鑰會外洩、輪換不易，並授予過於廣泛的存取權限。

OIDC Flow

GitHub Actions 為每次 workflow run 發行一個短期 OIDC token，由 GitHub OIDC provider（token.actions.githubusercontent.com）簽署。GCP 的 Workload Identity Federation 會根據設定好的 Workload Identity Pool 與 Provider 驗證此 token，然後為一個冒充的 service account 鑄造短期的 GCP access token。

設定範例

permissions:
  id-token: write
  contents: read

steps:
  - uses: google-github-actions/auth@v2
    with:
      workload_identity_provider: projects/123/locations/global/workloadIdentityPools/github/providers/my-repo
      service_account: deployer@my-project.iam.gserviceaccount.com
  - uses: google-github-actions/setup-gcloud@v2
  - run: gcloud run deploy api --image=us-docker.pkg.dev/proj/repo/api:${{ github.sha }}

Attribute Conditions

Workload Identity Provider 應該透過 attribute.repository == 'my-org/my-repo' && attribute.ref == 'refs/heads/main' 將信任綁定到特定的 repositories 與 branches。這可防止 forked repo 或 feature branch 冒充 production deployer。

對於 PCA，標準答案模式是：「使用 Workload Identity Federation 搭配 OIDC；絕不要將 service account keys 儲存在第三方 CI 中。」

Workload Identity Federation for CI/CD 深度解析

Workload Identity Federation (WIF) 比 GitHub Actions 應用更廣泛 — 它是 GCP 對任何支援 OIDC 或 SAML 2.0 的外部 identity provider 的無金鑰驗證框架。

支援的 Providers

• OIDC： GitHub Actions、GitLab CI、CircleCI、Bitbucket Pipelines、AWS（透過 STS）、Azure AD、通用的 Kubernetes service account tokens。
• SAML 2.0： Okta、Ping、ADFS 用於 human workforce identity（由 Workforce Identity Federation 處理，這是姊妹產品）。
• AWS： 聯合驗證，讓 AWS Lambda 函式或 EC2 instances 能使用其 AWS IAM role 呼叫 GCP APIs。

Pool、Provider、Principal 階層

1. Workload Identity Pool： 外部身份的命名空間，以 project 為範圍。
2. Provider： 一個外部 IdP 的設定（issuer URI、allowed audiences、attribute mappings）。
3. Principal： Pool 內的特定 subject，可定址為 principal://iam.googleapis.com/projects/.../subject/...，或對群組使用 principalSet://...。

Service Account Impersonation

外部身份不會直接成為 GCP principal；它透過 roles/iam.workloadIdentityUser 綁定來冒充一個 GCP service account。隨後使用一般 IAM 對該 service account 授予權限 — 這保留了所有現有的稽核、allow/deny policies 與 VPC-SC 控制。

稽核與輪換

每次 WIF token 交換都記錄在 Cloud Audit Logs 的 sts.googleapis.com 下。由於 tokens 是短期的（預設 1 小時，可設定降至 10 分鐘），無需輪換金鑰 — 比下載 JSON keys 在運維上是巨大的勝利。

Terraform Cloud / HCP Terraform 搭配 gcloud

對於使用 HashiCorp 託管 Terraform 服務（HCP Terraform，前稱 Terraform Cloud）的團隊，與 GCP 的整合模式結合了 IaC plans 與命令式 gcloud post-steps。

驗證模式

HCP Terraform 現在透過 Workload Identity Federation 支援動態憑證 — 與 GitHub Actions 相同的 OIDC flow。Workspace 請求一個 OIDC token，將其交換為短期的 GCP token，然後執行 terraform plan / apply，不需任何靜態憑證。

混合式 IaC + 命令式 Steps

Terraform 是宣告式的，擅長 provisioning，但某些操作本質上是命令式的：

• 在 BigQuery dataset 建立後觸發一次性的 Dataflow job。
• 透過 gcloud sql import 將初始 seed data 載入 Cloud SQL。
• 在新部署後使 Cloud CDN 快取失效。

建議的模式是先執行 terraform apply 進行 infrastructure 建置，接著由 local-exec provisioner 或下游的 Cloud Build step 執行 gcloud 命令。保持命令式 steps 為冪等的（check-then-act），並發出結構化日誌以便觀察。

Sentinel 與 OPA Policies

HCP Terraform 的 Sentinel policy engine 在 apply 執行之前強制執行 guardrails，例如「不允許公開的 Cloud Storage buckets」或「所有 VMs 必須啟用 shielded VM」。這補足了 GCP 端的 Organization Policies，在任何 API 呼叫發出之前的 plan 階段就攔截違規。

Skaffold 用於 GKE 內層開發循環

Skaffold 是支撐 Cloud Deploy 渲染流程的開源工具，但作為 GKE 工作負載開發者的內層循環工具同樣有價值。

內層循環 (Inner Loop)

skaffold dev 會監看本地原始碼檔案、在儲存時重新建置容器映像（使用 Buildpacks、Docker 或 Jib）、推送到 Artifact Registry、並將更新後的 manifests 套用到目標 cluster — 全程僅需數秒。檔案同步模式對直譯式語言會完全跳過重建，直接將變更的檔案複製到執行中的 pods。

Multi-Environment Builds 的 Profiles

單一 skaffold.yaml 宣告 profiles，依環境覆寫行為：

profiles:
  - name: dev
    build:
      local: { push: false }
    deploy:
      kubectl: { manifests: [k8s/dev/*.yaml] }
  - name: prod
    build:
      googleCloudBuild:
        projectId: my-prod-project
    deploy:
      kubectl: { manifests: [k8s/prod/*.yaml] }

Render-Only 模式用於 GitOps

skaffold render 輸出完全 hydrated 的 manifests 而不套用 — 非常適合 GitOps 工作流，其中 Config Sync 或 Argo CD 從 Git repo 取得 manifests。這正是 Cloud Deploy 內部在交給 target 之前渲染 manifests 的方式。

Cloud Code IDE 整合

Cloud Code 的 VS Code 與 IntelliJ plugins 將 Skaffold 包裝為 GUI-driven debugging、log streaming 與 pod shell access — 對於不熟悉 Kubernetes CLI 工具的開發者上手非常有幫助。

Artifact Registry 與 Artifact Analysis

Artifact Registry 是統一接替 Container Registry、Maven repositories 與特定語言 package stores 的服務。對 PCA 而言，關鍵能力是 repository 設計與整合式漏洞掃描。

Repository Modes

• Standard： 你團隊的私有 artifacts（Docker images、Maven、npm、Python、Apt、Yum、Go modules、Helm charts、generic）。
• Remote： 公開上游（如 Docker Hub、Maven Central 或 PyPI）的 pull-through cache。解決 Docker Hub rate limits 並改善 build latency。
• Virtual： 一個統一的 endpoint，依設定好的優先順序 fan out 到多個上游 Standard 或 Remote repos。在 repos 之間遷移而不破壞 client 設定時很有用。

Regional vs Multi-Regional

Regional repos（us-central1-docker.pkg.dev）與工作負載共置以最小化 pull latency 與 egress 成本。Multi-regional（us-docker.pkg.dev）適合提供給多個 regions 的 golden images。

Artifact Analysis（前稱 Container Analysis）

每次 image push 都會觸發針對 National Vulnerability Database 與 Google curated feeds 的非同步漏洞掃描。結果以 Occurrences 儲存，連結到 Artifact Analysis 中的 Notes。可使用 gcloud artifacts docker images list-vulnerabilities IMAGE_URL 查詢，或透過 Pub/Sub 串流以實現即時安全工作流。

掃描器也會產生 SBOM (Software Bill of Materials) 文件，採用 SPDX 與 CycloneDX 格式，符合 executive order 14028 對聯邦承包商的要求。

Binary Authorization 與簽署過的 Attestations

Binary Authorization 是 GCP 的部署時閘門，確保只有受信任、已驗證的 images 在 GKE、Cloud Run 與 Anthos clusters 上執行。

Policy Model

Binary Authorization policy 在每個 cluster 或 project 層級指定：

• Default rule： 對沒有 attestations 的 images 該怎麼做（在 production 通常是 ALWAYS_DENY）。
• Cluster-specific rules： 允許非關鍵 clusters 的例外。
• Allowlists： 依 URL 模式豁免 images（例如 gcr.io/google-containers/* 用於系統 pods）。
• Required attestors： 必須全部存在的 attestors 簽章列表。

Attestors 與 Attestations

Attestor 是一個具名實體，綁定到 PGP 或 Cloud KMS-managed asymmetric key。Attestation 是由受信任的程序所建立的簽署過聲明（「此 image SHA-256 digest 通過了漏洞掃描」） — 通常是 Cloud Build step 呼叫 gcloud beta container binauthz attestations sign-and-create。

端到端 Flow

1. Cloud Build 建置 image，推送到 Artifact Registry。
2. Artifact Analysis 掃描 CVEs；若無高於閾值者，Cloud Build step 使用為「qa-scanner」attestor 保留的 KMS key 簽署一個 attestation。
3. 選擇性的手動核准 step（透過 Cloud Deploy approval gate）從「release-manager」attestor 建立第二個 attestation。
4. 部署時，GKE admission controller 查詢 Binary Authorization，後者檢查兩個 attestations 是否都存在且由受信任的 keys 簽署。缺少簽章 → pod 建立被拒絕，並在稽核日誌留下清楚的記錄。

Continuous Validation

Binary Authorization 也會在背景執行 Continuous Validation，每 24 小時重新檢查執行中的 pods。若先前受信任的 image 後續被撤銷（例如新揭露了重大 CVE），CV 會發出 log-based metric — 搭配 Pub/Sub 警示可清空受影響的工作負載。

常見問題 — 部署自動化 (FAQ — Deployment Automation)

Q1. 應該用 Python 還是 Bash？

對於簡單的單行命令或順序性的 GCP 資源建立，Bash + gcloud 即可。對於涉及迴圈、複雜邏輯或外部 API 呼叫的任何任務，請使用 Python。

Q2. 我該如何在腳本中處理驗證 (Authentication)？

在本地環境中，使用 gcloud auth application-default login。在生產環境（VM、Cloud Build）中，腳本會自動使用附加到資源的服務帳戶 (Service Account)。

Q3. 我可以在 GCP 上使用 Ansible 嗎？

可以。Google 提供了官方的 Ansible 模組來管理 GCP 資源。這在混合雲場景中很常見，特別是當你已經在使用 Ansible 進行地端配置時。

Q4. 如何讓我的腳本具備冪等性 (Idempotent)？

在建立資源（例如 Bucket）之前，腳本應該檢查它是否已存在。在 gcloud 中，你可以使用 gsutil ls 或 gcloud ... describe 並處理「未找到」的錯誤。

Q5. 將腳本儲存在 Git 儲存庫中安全嗎？

是的，而且強烈建議這樣做。但是，請確保沒有將密鑰 (Secrets) 提交到程式碼中。使用 .gitignore 和 Secret Manager 來處理敏感數據。