Atelier pratique — PCDE Google Cloud Professional Cloud Database Engineer

Présentation

Prérequis

Étapes

1. 1.Fournisseur, services de projet, dénomination

   Activez les API Cloud Build, Cloud Deploy, Cloud Run, Artifact Registry et Cloud Monitoring.

   Copier

   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.Créer la destination d'images Artifact Registry

   Déploie :

   • Artifact Registry

   Forme CI/CD canonique PCDE : Cloud Build envoie les images dans Artifact Registry ; Cloud Deploy promeut le même SHA d'image à travers les environnements. Le dépôt est la source unique de vérité pour tous les environnements — images immuables, tags mutables.

   Copier

   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.Définir un déclencheur Cloud Build sur un dépôt GitHub

   Déploie :

   • Cloud Build

   Les déclencheurs Cloud Build sont la primitive PCDE de commit-à-build. Nous définissons un déclencheur sur la branche main d'un dépôt GitHub — chaque push exécute le cloudbuild.yaml à la racine du dépôt, qui effectuerait un docker build + docker push vers Artifact Registry à partir de l'étape 2.

   Remplacez github-owner et github-repo par votre dépôt réel. Le déclencheur sera provisionné mais ne se déclenchera pas tant que l'application GitHub Cloud Build ne sera pas installée sur le dépôt (étape manuelle unique via la console).

   Copier

   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.Connecter un pipeline Cloud Deploy avec des cibles Cloud Run de staging → prod

   Déploie :

   • Cloud Deploy
   • Cloud Run

   Cloud Deploy est le service CD géré de GCP — il promeut une release à travers des étapes ordonnées (généralement dev → staging → prod), chacune soutenue par une cible (service Cloud Run, cluster GKE ou cluster Anthos). L'examen PCDE teste abondamment cette forme release unique, promotion multiple.

   Nous définissons deux services cibles Cloud Run (un pour le staging, un pour la production, tous deux avec mise à l'échelle à zéro) + un pipeline de livraison les enchaînant. Une vraie release serait déclenchée via gcloud deploy releases create après une exécution réussie de Cloud Build ; le laboratoire provisionne le substrat sans déclencher de release.

   Copier

   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.Définir une politique d'alerte + SLO sur le service de production

   Déploie :

   • Cloud Monitoring

   Le vocabulaire SLO / SLI / budget d'erreur du PCDE est la forme d'observabilité porteuse — chaque question d'examen PCDE étiquetée Fiabilité du Site teste cela. Nous définissons un objectif de niveau de service : "99 % des requêtes HTTP vers le service de production devraient retourner 2xx sur une fenêtre glissante de 28 jours." Ensuite, une alerte Cloud Monitoring se déclenche lorsque le taux de consommation indique que le budget est consommé trop rapidement.

   Avec les cinq blocs en place (Artifact Registry, déclencheur Cloud Build, deux cibles Cloud Run, pipeline Cloud Deploy, SLO de production + alerte), la boucle commit → build → deploy → observe du PCDE est provisionnée de bout en bout.

   Copier

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

Nettoyage