Praxislabor — PCDE Google Cloud Professional Cloud Database Engineer

Übersicht

Voraussetzungen

Schritte

1. 1.Provider, Projektdienste, Benennung

   Aktivieren Sie die APIs für Cloud Build, Cloud Deploy, Cloud Run, Artifact Registry und Cloud Monitoring.

   Kopieren

   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.Erstellen des Artifact Registry-Zielorts für Images

   Ressourcen:

   • Artifact Registry

   PCDE-kanonische CI/CD-Form: Cloud Build gibt Images in Artifact Registry aus; Cloud Deploy befördert denselben Image-SHA durch verschiedene Umgebungen. Das Repository ist die einzige Quelle der Wahrheit über alle Umgebungen hinweg – unveränderliche Images, veränderliche Tags.

   Kopieren

   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.Definieren eines Cloud Build-Triggers für ein GitHub-Repository

   Ressourcen:

   • Cloud Build

   Cloud Build-Trigger sind das PCDE-Commit-zu-Build-Primitiv. Wir definieren einen Trigger für den main-Zweig eines GitHub-Repositorys – jeder Push führt die cloudbuild.yaml im Repository-Root aus, die dann docker build + docker push in das Artifact Registry aus Schritt 2 durchführen würde.

   Ersetzen Sie github-owner und github-repo durch Ihr tatsächliches Repository. Der Trigger wird bereitgestellt, aber erst ausgelöst, wenn die GitHub Cloud Build App im Repository installiert ist (manueller einmaliger Konsolenschritt).

   Kopieren

   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.Verdrahtung einer Cloud Deploy-Pipeline mit Staging → Prod Cloud Run-Zielen

   Ressourcen:

   • Cloud Deploy
   • Cloud Run

   Cloud Deploy ist GCPs verwalteter CD-Dienst – er befördert einen Release durch geordnete Stufen (typischerweise Dev → Staging → Prod), die jeweils durch ein Ziel (Cloud Run-Dienst, GKE-Cluster oder Anthos-Cluster) unterstützt werden. Die PCDE-Prüfung testet diese einmal releasen, mehrfach befördern-Form ausgiebig.

   Wir definieren zwei Cloud Run Ziel-Dienste (einen für Staging, einen für Prod, beide mit Skalierung auf null) + eine Bereitstellungspipeline, die sie miteinander verbindet. Ein echter Release würde nach einem erfolgreichen Cloud Build-Lauf über gcloud deploy releases create ausgelöst; das Lab stellt die Basis bereit, ohne einen Release auszulösen.

   Kopieren

   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.Definieren einer SLO + Benachrichtigungsrichtlinie für den Prod-Dienst

   Ressourcen:

   • Cloud Monitoring

   Das SLO / SLI / Fehlerbudget-Vokabular von PCDE ist die tragende Observability-Form – jede PCDE-Prüfungsfrage, die als Site Reliability gekennzeichnet ist, testet dies. Wir definieren ein Service-Level Objective: „99 % der HTTP-Anfragen an den Prod-Dienst sollten über ein gleitendes 28-Tage-Fenster 2xx zurückgeben.“ Anschließend wird ein Cloud Monitoring-Alert ausgelöst, wenn die Burn Rate anzeigt, dass das Budget zu schnell verbraucht wird.

   Mit den fünf Blöcken (Artifact Registry, Cloud Build-Trigger, zwei Cloud Run-Ziele, Cloud Deploy-Pipeline, Prod-SLO + Alert) ist der PCDE-Commit → Build → Deploy → Observe-Zyklus durchgängig bereitgestellt.

   Kopieren

   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
       }
     }
   }

Bereinigung