這四個 labs 展示了 Cloud SQL PostgreSQL 作為企業級資料庫服務的強大功能，從資料遷移到安全管理再到災難恢復，形成完整的資料庫生命週期管理解決方案。特別是看到 Database Migration Service 如何無縫遷移資料，還有應用如何安全地連接到受保護的資料庫實例，真的很實用。

GSP918 - Migrate to Cloud SQL for PostgreSQL using Database Migration Service
GSP919 - Connect an App to a Cloud SQL for PostgreSQL Instance
GSP920 - Securing a Cloud SQL for PostgreSQL Instance
GSP922 - Configure Replication and Enable Point-in-Time Recovery for Cloud SQL for PostgreSQL

主要特色

➊ Database Migration Service (DMS) 讓資料遷移變得簡單，支援連續同步避免停機
➋ GKE 應用與 Cloud SQL 的安全連接，透過 Auth Proxy 實現零信任架構
➌ CMEK 客戶自管加密金鑰，提供資料靜態加密的完全控制權
➍ pgAudit 詳細記錄 SQL 操作，滿足合規與安全稽核需求
➎ IAM 資料庫認證整合，簡化身分管理與權限控制
➏ Point-in-time recovery 時間點恢復功能，精準回復到特定時間點的資料狀態

Labs 實作

➊ 準備來源 PostgreSQL 並安裝配置 pglogical 延伸模組
➋ 建立 Database Migration Service 連線設定檔和遷移作業
➌ 建立 GKE cluster 並部署容器化應用程式
➍ 配置 Kubernetes secrets 管理資料庫認證資訊
➎ 設定 Cloud KMS 金鑰環與 CMEK 加密金鑰
➏ 配置 pgAudit 與 Cloud SQL IAM 資料庫認證
➐ 啟用自動備份與 point-in-time recovery 功能
➑ 測試資料遷移同步與災難恢復機制

𝕂𝕖𝕖𝕡 𝕃𝕖𝕒𝕣𝕟𝕚𝕟𝕘. 𝕂𝕖𝕖𝕡 𝕙𝕒𝕔𝕜𝕚𝕟𝕘!

實作影片

指令整理

環境初始化

此部分設定 GCP 專案的基礎環境變數。這些變數在後續指令中被引用，確保所有操作都在正確的專案、區域、實例上執行。

export PROJECT_ID=$(gcloud config list --format 'value(core.project)')
export REGION=""      # 根據 lab 環境設定，影響資源部署位置
export ZONE=""        # 用於 Compute Engine 實例的特定可用區
export PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format 'value(projectNumber)')

資料庫遷移與複製

此部分涵蓋 Database Migration Service 的完整設定流程。DMS 解決了傳統資料庫遷移的停機問題，透過邏輯複製實現連續資料同步。

# 啟用必要 API
gcloud services enable databasemigration.googleapis.com
gcloud services enable servicenetworking.googleapis.com

# 建立遷移連線設定檔
gcloud database-migration connection-profiles create postgres-vm \
  --region=$REGION \
  --source-engine=postgresql \
  --host=10.128.0.2 \
  --port=5432 \
  --username=migration_admin \
  --password="DMS_1s_cool!"

# 建立遷移作業
gcloud database-migration migration-jobs create vm-to-cloudsql \
  --region=$REGION \
  --source=postgres-vm \
  --destination=postgresql-cloudsql \
  --type=CONTINUOUS

常見坑點：pglogical 延伸模組必須正確安裝並配置，否則遷移會失敗。來源資料庫的權限設定也很關鍵，migration_admin 使用者需要 REPLICATION 權限。
概念連結：此概念與「安全配置」相關，因為遷移過程需要處理敏感資料，確保連線安全至關重要。

應用部署與連接

此部分展示如何將容器化應用部署到 GKE 並安全連接到 Cloud SQL。解決了傳統應用架構中資料庫連接管理的複雜性。

# 建立 GKE cluster
gcloud container clusters create postgres-cluster --zone=$ZONE --num-nodes=2

# 建立 Kubernetes secrets
kubectl create secret generic cloudsql-instance-credentials --from-file=credentials.json=$SERVICE_ACCOUNT_KEY.json
kubectl create secret generic cloudsql-db-credentials --from-literal=username=postgres --from-literal=password=supersecret!

# 建立負載平衡器服務
kubectl expose deployment gmemegen --type="LoadBalancer" --port 80 --target-port 8080

常見坑點：Cloud SQL Auth Proxy 的連接字串格式必須完全正確，否則應用程式無法連接到資料庫。容器映像也要正確推送到 Artifact Registry。
概念連結：此概念與「安全配置」緊密相關，因為應用連接需要適當的身分認證和權限管理。

安全配置

此部分實現 Cloud SQL 的全方位安全保護。CMEK 和 IAM 認證解決了資料加密和存取控制的核心問題。

# 建立 Cloud SQL 專用服務帳號
gcloud beta services identity create --service=sqladmin.googleapis.com --project=$PROJECT_ID

# 建立 KMS 金鑰環和金鑰
gcloud kms keyrings create cloud-sql-keyring --location=$REGION
gcloud kms keys create cloud-sql-key --location=$REGION --keyring=cloud-sql-keyring --purpose=encryption

# 綁定金鑰到服務帳號
gcloud kms keys add-iam-policy-binding cloud-sql-key \
  --location=$REGION \
  --keyring=cloud-sql-keyring \
  --member=serviceAccount:service-${PROJECT_NUMBER}@gcp-sa-cloud-sql.iam.gserviceaccount.com \
  --role=roles/cloudkms.cryptoKeyEncrypterDecrypter

# 建立具 CMEK 的 Cloud SQL 實例
gcloud sql instances create secure-postgres \
  --database-version=POSTGRES_13 \
  --cpu=2 \
  --memory=7680MB \
  --region=$REGION \
  --root-password=supersecret! \
  --disk-encryption-key=projects/$PROJECT_ID/locations/$REGION/keyRings/cloud-sql-keyring/cryptoKeys/cloud-sql-key \
  --backup-encryption-key=projects/$PROJECT_ID/locations/$REGION/keyRings/cloud-sql-keyring/cryptoKeys/cloud-sql-key

常見坑點：CMEK 金鑰遺失將導致資料無法存取，務必妥善備份金鑰。IAM 權限設定不正確會造成連線失敗。
概念連結：安全配置與「應用部署」和「備份恢復」都相關，因為所有操作都需要適當的權限控制。

備份與恢復

此部分實現資料保護和災難恢復。Point-in-time recovery 解決了資料意外損失的問題，提供精準的時間點回復能力。

# 啟用自動備份
gcloud sql instances patch postgres-orders --backup-start-time=13:00

# 啟用時間點恢復
gcloud sql instances patch postgres-orders \
  --enable-point-in-time-recovery \
  --retained-transaction-log-days=1

# 執行時間點恢復
gcloud sql instances restore-backup postgres-orders-restore \
  --backup-instance=postgres-orders \
  --restore-time="2023-11-01 14:30:00"

常見坑點：備份開始時間必須早於當前時間，否則設定會失敗。恢復操作會建立新實例，無法覆蓋現有實例。
概念連結：備份恢復與「安全配置」相關，因為加密的金鑰也必須用於備份資料的保護。

驗證與測試

整合上述概念，展示如何驗證整個架構的正確性。確保所有組件協調運作，提供可靠的資料庫服務。

# 驗證遷移狀態
gcloud database-migration migration-jobs describe vm-to-cloudsql --region=$REGION --format="value(status)"

# 測試應用連線
gcloud sql connect secure-postgres --user=postgres --quiet

# 檢查備份配置
gcloud sql instances describe postgres-orders --format='value(settings.backupConfiguration)'