Laboratório prático — PCDE Google Cloud Professional Cloud Database Engineer

Visão geral

Pré-requisitos

Passos

1. 1.Provedor, serviços do projeto, nomenclatura

   Habilite as APIs do Cloud Build, Cloud Deploy, Cloud Run, Artifact Registry e 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.Crie o destino da imagem no Artifact Registry

   Provisiona:

   • Artifact Registry

   Formato CI/CD canônico do PCDE: o Cloud Build envia imagens para o Artifact Registry; o Cloud Deploy promove o mesmo SHA de imagem através dos ambientes. O repositório é a única fonte da verdade em todos os ambientes — imagens imutáveis, tags mutáveis.

   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.Defina um gatilho do Cloud Build em um repositório GitHub

   Provisiona:

   • Cloud Build

   Gatilhos do Cloud Build são a primitiva commit-to-build do PCDE. Definimos um gatilho no branch main de um repositório GitHub — cada push executa o cloudbuild.yaml na raiz do repositório, que faria docker build + docker push para o Artifact Registry da Etapa 2.

   Substitua github-owner e github-repo pelo seu repositório real. O gatilho será provisionado, mas não será acionado até que o aplicativo GitHub Cloud Build seja instalado no repositório (etapa manual única no console).

   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.Configure um pipeline do Cloud Deploy com alvos Cloud Run de staging → prod

   Provisiona:

   • Cloud Deploy
   • Cloud Run

   Cloud Deploy é o serviço de CD gerenciado do GCP — promove um release através de estágios ordenados (tipicamente dev → staging → prod), cada um suportado por um alvo (serviço Cloud Run, cluster GKE ou cluster Anthos). O exame PCDE testa extensivamente este formato release-uma-vez, promova-muitas-vezes.

   Definimos dois serviços alvo do Cloud Run (um para staging, um para prod, ambos com escala para zero) + um pipeline de entrega que os encadeia. Um release real seria acionado via gcloud deploy releases create após uma execução bem-sucedida do Cloud Build; o laboratório provisiona a infraestrutura sem acionar um release.

   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.Defina um SLO + política de alerta no serviço de produção

   Provisiona:

   • Cloud Monitoring

   O vocabulário SLO / SLI / orçamento de erro do PCDE é o pilar da observabilidade — toda questão do exame PCDE marcada como Site Reliability testa isso. Definimos um objetivo de nível de serviço: "99% das requisições HTTP para o serviço de produção devem retornar 2xx em uma janela de 28 dias consecutivos." Então um alerta do Cloud Monitoring é disparado quando a taxa de consumo indica que o orçamento está sendo consumido muito rapidamente.

   Com os cinco blocos em vigor (Artifact Registry, gatilho do Cloud Build, dois alvos do Cloud Run, pipeline do Cloud Deploy, SLO + alerta de produção), o ciclo commit → build → deploy → observe do PCDE é provisionado de ponta a ponta.

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

Limpeza