Laboratorio práctico — PCDE Google Cloud Professional Cloud Database Engineer

Descripción general

Requisitos previos

Pasos

1. 1.Proveedor, servicios del proyecto, nomenclatura

   Habilite las API de Cloud Build, Cloud Deploy, Cloud Run, Artifact Registry y Cloud Monitoring.

   Copiar

   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.Crear el destino de la imagen en Artifact Registry

   Aprovisiona:

   • Artifact Registry

   Forma canónica de CI/CD de PCDE: Cloud Build envía las imágenes a Artifact Registry; Cloud Deploy promueve el mismo SHA de imagen a través de los entornos. El repositorio es la única fuente de verdad en todos los entornos: imágenes inmutables, etiquetas mutables.

   Copiar

   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.Definir un disparador de Cloud Build en un repositorio de GitHub

   Aprovisiona:

   • Cloud Build

   Los disparadores de Cloud Build son la primitiva commit-to-build de PCDE. Definimos un disparador en la rama main de un repositorio de GitHub: cada push ejecuta el cloudbuild.yaml en la raíz del repositorio, que realizaría un docker build + docker push en Artifact Registry desde el Paso 2.

   Reemplace github-owner y github-repo con su repositorio real. El disparador se aprovisionará pero no se activará hasta que la aplicación GitHub Cloud Build esté instalada en el repositorio (paso manual único en la consola).

   Copiar

   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.Conectar una canalización de Cloud Deploy con objetivos de Cloud Run de staging → prod

   Aprovisiona:

   • Cloud Deploy
   • Cloud Run

   Cloud Deploy es el servicio de CD gestionado de GCP: promueve un lanzamiento a través de etapas ordenadas (típicamente dev → staging → prod), cada una respaldada por un objetivo (servicio de Cloud Run, clúster GKE o clúster Anthos). El examen PCDE evalúa extensivamente esta forma de lanzar una vez, promover muchas.

   Definimos dos servicios de destino de Cloud Run (uno para staging, uno para prod, ambos con escalado a cero) + una canalización de entrega que los encadena. Un lanzamiento real se activaría mediante gcloud deploy releases create después de una ejecución exitosa de Cloud Build; el laboratorio provisiona el sustrato sin activar un lanzamiento.

   Copiar

   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.Definir una política de SLO + alerta en el servicio de producción

   Aprovisiona:

   • Cloud Monitoring

   El vocabulario de SLO / SLI / presupuesto de errores de PCDE es la forma principal de observabilidad; cada pregunta del examen PCDE etiquetada como Confiabilidad del Sitio (Site Reliability) evalúa esto. Definimos un objetivo de nivel de servicio: «El 99% de las solicitudes HTTP al servicio de producción deben devolver 2xx en un período continuo de 28 días». Luego, una alerta de Cloud Monitoring se dispara cuando la tasa de consumo indica que el presupuesto se está agotando demasiado rápido.

   Con los cinco bloques en su lugar (Artifact Registry, disparador de Cloud Build, dos objetivos de Cloud Run, canalización de Cloud Deploy, SLO + alerta de producción), el ciclo commit → build → deploy → observe de PCDE está provisionado de extremo a extremo.

   Copiar

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

Limpieza