ハンズオンラボ — PCDE Google Cloud Professional Cloud Database Engineer

概要

前提条件

ステップ

1. 1.プロバイダ、プロジェクトサービス、命名

   Cloud Build、Cloud Deploy、Cloud Run、Artifact Registry、およびCloud Monitoringの各APIを有効にします。

   コピー

   terraform {
     required_version = ">= 1.5"
   
     required_providers {
       google = { source = "hashicorp/google", version = "~> 6.0" }
     }
   }
   
   provider "google" {
     project = "your-project-id" # REPLACE
     region  = "us-central1"
   }
   
   locals {
     labels = {
       project    = "certlabpro-pcde"
       managed_by = "terraform"
     }
   }
   
   resource "google_project_service" "cloudbuild" {
     service            = "cloudbuild.googleapis.com"
     disable_on_destroy = false
   }
   
   resource "google_project_service" "clouddeploy" {
     service            = "clouddeploy.googleapis.com"
     disable_on_destroy = false
   }
   
   resource "google_project_service" "run" {
     service            = "run.googleapis.com"
     disable_on_destroy = false
   }
   
   resource "google_project_service" "artifactregistry" {
     service            = "artifactregistry.googleapis.com"
     disable_on_destroy = false
   }
   
   resource "google_project_service" "monitoring" {
     service            = "monitoring.googleapis.com"
     disable_on_destroy = false
   }

2. 2.Artifact Registryのイメージ保存先を作成する

   プロビジョニング対象:

   • Artifact Registry

   PCDEの標準的なCI/CD形式：Cloud BuildはイメージをArtifact Registryに出力し、Cloud Deployは同じイメージSHAを複数の環境にプロモートします。リポジトリはすべての環境における唯一の真実のソースとなります — 不変のイメージ、可変のタグ。

   コピー

   resource "google_artifact_registry_repository" "images" {
     repository_id = "certlabpro-pcde-images"
     location      = "us-central1"
     format        = "DOCKER"
   
     labels = local.labels
   
     depends_on = [google_project_service.artifactregistry]
   }

3. 3.GitHubリポジトリにCloud Buildトリガーを定義する

   プロビジョニング対象:

   • Cloud Build

   Cloud Buildトリガーは、PCDEのコミットからビルドへのプリミティブです。GitHubリポジトリの main ブランチに対するトリガーを定義します。プッシュするたびにリポジトリルートの cloudbuild.yaml が実行され、ステップ2のArtifact Registryに docker build + docker push します。

   github-owner と github-repo を実際のレポに置き換えてください。トリガーはプロビジョニングされますが、GitHub Cloud Buildアプリがレポにインストールされるまで（一度限りの手動コンソール設定）、実行されません。

   コピー

   resource "google_cloudbuild_trigger" "main_push" {
     name        = "certlabpro-pcde-main-push"
     description = "Build on push to main"
     filename    = "cloudbuild.yaml"
   
     github {
       owner = "github-owner" # REPLACE
       name  = "github-repo"  # REPLACE
   
       push {
         branch = "^main$"
       }
     }
   
     depends_on = [google_project_service.cloudbuild]
   }

4. 4.ステージング → 本番Cloud RunターゲットでCloud Deployパイプラインを構築する

   プロビジョニング対象:

   • Cloud Deploy
   • Cloud Run

   Cloud Deploy はGCPのマネージドCDサービスであり、リリースを順序付けられたステージ（通常は開発 → ステージング → 本番）を通してプロモートします。各ステージはターゲット（Cloud Runサービス、GKEクラスタ、またはAnthosクラスタ）によってバックアップされます。PCDE試験では、この一度リリースし、何度もプロモートする形式が広範囲にわたってテストされます。

   ここでは、2つのCloud Run ターゲットサービス（ステージング用と本番用、両方ともスケール・トゥ・ゼロ）と、それらを連鎖させる1つのデリバリーパイプラインを定義します。実際のリリースは、Cloud Buildの実行が成功した後、gcloud deploy releases create を介してトリガーされます。このラボでは、リリースを実行せずに基盤をプロビジョニングします。

   コピー

   resource "google_cloud_run_v2_service" "staging" {
     name     = "certlabpro-pcde-staging"
     location = "us-central1"
   
     template {
       scaling { max_instance_count = 5 }
   
       containers {
         image = "us-docker.pkg.dev/cloudrun/container/hello"
       }
     }
   
     labels = local.labels
   
     depends_on = [google_project_service.run]
   }
   
   resource "google_cloud_run_v2_service" "prod" {
     name     = "certlabpro-pcde-prod"
     location = "us-central1"
   
     template {
       scaling { max_instance_count = 10 }
   
       containers {
         image = "us-docker.pkg.dev/cloudrun/container/hello"
       }
     }
   
     labels = local.labels
   
     depends_on = [google_project_service.run]
   }
   
   resource "google_clouddeploy_target" "staging" {
     name     = "staging"
     location = "us-central1"
   
     run {
       location = "projects/${data.google_project.current.project_id}/locations/us-central1"
     }
   
     depends_on = [google_project_service.clouddeploy]
   }
   
   resource "google_clouddeploy_target" "prod" {
     name     = "prod"
     location = "us-central1"
   
     run {
       location = "projects/${data.google_project.current.project_id}/locations/us-central1"
     }
   
     require_approval = true # promotion to prod needs manual approval
   
     depends_on = [google_project_service.clouddeploy]
   }
   
   data "google_project" "current" {}
   
   resource "google_clouddeploy_delivery_pipeline" "main" {
     name     = "certlabpro-pcde-pipeline"
     location = "us-central1"
   
     serial_pipeline {
       stages {
         target_id = google_clouddeploy_target.staging.name
       }
   
       stages {
         target_id = google_clouddeploy_target.prod.name
       }
     }
   
     depends_on = [google_project_service.clouddeploy]
   }

5. 5.本番サービスにSLO + アラートポリシーを定義する

   プロビジョニング対象:

   • Cloud Monitoring

   PCDEのSLO / SLI / エラーバジェットの語彙は、負荷を支える可観測性の形式です — サイト信頼性とタグ付けされたPCDE試験のすべての質問がこれをテストします。ここでは、サービスレベル目標を定義します。「本番サービスへのHTTPリクエストの99%は、28日間のローリング期間で2xxを返す必要がある」。そして、バーンレートがバジェットが速すぎるペースで消費されていることを示すときに、Cloud Monitoringアラートが発動します。

   5つのブロック（Artifact Registry、Cloud Buildトリガー、2つのCloud Runターゲット、Cloud Deployパイプライン、本番SLO + アラート）が配置されると、PCDEのコミット → ビルド → デプロイ → 監視ループがエンドツーエンドでプロビジョニングされます。

   コピー

   resource "google_monitoring_service" "prod" {
     service_id   = "certlabpro-pcde-prod-svc"
     display_name = "PCDE prod Cloud Run service"
   
     basic_service {
       service_type = "CLOUD_RUN"
   
       service_labels = {
         service_name = google_cloud_run_v2_service.prod.name
         location     = google_cloud_run_v2_service.prod.location
       }
     }
   
     depends_on = [google_project_service.monitoring]
   }
   
   resource "google_monitoring_slo" "prod_availability" {
     service             = google_monitoring_service.prod.service_id
     slo_id              = "certlabpro-pcde-prod-availability"
     display_name        = "99% requests return 2xx (28-day rolling)"
     goal                = 0.99
     rolling_period_days = 28
   
     basic_sli {
       availability {
         enabled = true
       }
     }
   }
   
   resource "google_monitoring_alert_policy" "prod_budget_burn" {
     display_name = "PCDE prod — fast budget burn"
     combiner     = "OR"
   
     conditions {
       display_name = "1-hour burn rate > 14.4 (fast burn)"
   
       condition_threshold {
         filter          = "select_slo_burn_rate(\"${google_monitoring_slo.prod_availability.name}\", \"3600s\")"
         duration        = "0s"
         comparison      = "COMPARISON_GT"
         threshold_value = 14.4 # consumes 2% of monthly budget in 1 hour
       }
     }
   }

クリーンアップ