多雲架構微服務與 DevOps 自動化部署

類別：Multi-Cloud · DevOps · Side Project技術棧：Terraform · AWS · GCP · GKE · Kubernetes · GitHub Actions · FastAPI · Django · Vertex AI

背景

這是我在面試前自主建置的 Side Project。目的很明確：證明自己能在短時間內，將較不熟悉的 GCP 從零建置到具備一定可用程度，並在過程中解決真實的跨雲整合問題。

我在上一份工作主要使用 AWS CDK，雖然熟悉 AWS，但 CDK 的缺點是綁死在 AWS 生態系。這次我刻意選擇 Terraform 作為 IaC 工具，原因是它使用 HCL 語法，能跨雲管理（AWS + GCP）同一套 Infra 程式碼。

架構設計

系統由 Vue.js 前端、FastAPI 後端、Django 認證服務組成，部署在 AWS 與 GCP 雙雲上，使用 Kubernetes（GKE）進行容器編排。

踩坑紀錄

坑 1：CI/CD 的 GCP 部署問題

問題： 一開始想用 GitHub Actions 統包所有 CI/CD。但在自動部署至 GCP 時卡了很久。

追查後發現：GCP 的 VPC 網路與 GKE 權限控管非常嚴格。GitHub Actions Runner 屬於外部網域，不只會被防火牆阻擋，若要讓它能部署，還需要給予過高的 Service Account 權限，增加金鑰外洩風險。

解法：CI 與 CD 解耦

GitHub Actions（CI）
  ├── 執行自動化測試
  ├── 建置 Docker Image
  └── 推送至 AWS ECR

GCP Cloud Build（CD）
  ├── 監聽 Git Merge 事件
  ├── 在 GCP 內網執行部署
  └── 更新 GKE 上的服務

這個解法帶來兩個好處：

無金鑰認證（Keyless Authentication）：GitHub Actions 不再需要持有 GCP Service Account 金鑰，消除了金鑰管理與外洩風險
網路安全：部署動作在 GCP 內網執行，完全繞過外部網路阻擋問題

坑 2：跨雲拉取 Docker Image

問題： Docker Image 統一存放在 AWS ECR，但需要在 GCP GKE 的 Pod 上拉取執行。跨雲的身分驗證讓這個過程複雜了很多。

傳統做法是將 AWS 的存取金鑰（Access Key）設定為 Kubernetes Secret，讓 Pod 用這組金鑰向 ECR 驗證。但這有個根本問題：長期存在的靜態金鑰是最大的安全隱患。

解法：Workload Identity Federation

導入 GCP 與 AWS 之間的 Workload Identity Federation（工作負載身分聯邦） 機制：

GKE Pod 透過 GCP Workload Identity 取得自己的 GCP Service Account 身分
透過 Federation 機制，向 AWS STS 申請換取短期的 AWS Token
用短期 Token 向 AWS ECR 驗證並拉取 Image

GKE Pod → GCP Workload Identity → AWS STS (Federation) → 短期 Token → AWS ECR

短期 Token 自動過期，即使被竊取也無法長期使用，大幅提升了安全性。

坑 3：保護 Vertex AI API 端點

問題： 後端 FastAPI 呼叫 GCP Vertex AI（Gemini）進行翻譯。如果 API 端點是公開的，任何人都可以無限制地呼叫，直接消耗我的 GCP 額度。

解法：雙層防護

Layer 1 — Django Auth 身分驗證 建立了一套 Token-based 的身分驗證機制，只有持有有效 Token 的請求才能通過驗證進入 Vertex AI 呼叫。

Layer 2 — CORS 域名限制 在前端與 API 層設定嚴格的 CORS 規則：

python

# FastAPI CORS 設定
app.add_middleware(
    CORSMiddleware,
    allow_origins=["https://my-authorized-domain.com"],
    allow_methods=["POST"],
)

只有來自授權域名的請求才會被接受，直接從源頭阻擋非法呼叫。

版本控制與品質控管

在 GitHub 端設定了 Branch Protection Rules：

main 分支禁止直接 Push，只能透過 Pull Request 合入
PR 必須通過所有 GitHub Actions 的測試才能 Merge
這是防止未測試程式碼破壞正式環境的第一道防線

成果

成功將 GCP 從零建置到微服務完整運行，驗證了快速切入新雲端平台的能力
解決三個真實的跨雲整合難題（CI/CD 解耦、跨雲 Image 拉取、API 保護）
Terraform 實現跨雲 IaC，AWS 與 GCP 資源統一版本管理

反思

跨雲整合最難的地方不是技術本身，而是每個雲的安全模型和網路邊界都不一樣。AWS 的 IAM 邏輯和 GCP 的 Workload Identity 設計思路有根本的差異，需要先理解各自的身分模型，才能設計出優雅的解決方案。

多雲架構微服務與 DevOps 自動化部署 ​

背景 ​

架構設計 ​

踩坑紀錄 ​

坑 1：CI/CD 的 GCP 部署問題 ​

坑 2：跨雲拉取 Docker Image ​

坑 3：保護 Vertex AI API 端點 ​

版本控制與品質控管 ​

成果 ​

反思 ​