Atelier pratique — PCD Google Cloud Professional Cloud Developer

Présentation

Prérequis

Étapes

1. 1.Fournisseur, services de projet, nommage

   Activez les API Cloud Run, Artifact Registry, Pub/Sub et Secret Manager.

   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-pcd"
       managed_by = "terraform"
     }
   }
   
   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" "pubsub" {
     service            = "pubsub.googleapis.com"
     disable_on_destroy = false
   }
   
   resource "google_project_service" "secretmanager" {
     service            = "secretmanager.googleapis.com"
     disable_on_destroy = false
   }

2. 2.Créez un dépôt Artifact Registry pour les images conteneur

   Déploie :

   • Artifact Registry

   Artifact Registry est le registre de conteneurs + paquets de GCP — le remplacement moderne du Container Registry (gcr.io) déprécié. L'examen PCD teste ce modèle de poussée vers Artifact Registry → déploiement depuis Artifact Registry comme forme canonique de CI/CD.

   Nous créons un dépôt régional au format Docker. Poussez-y après terraform apply via :

   gcloud auth configure-docker us-central1-docker.pkg.dev
   docker tag my-app:latest us-central1-docker.pkg.dev/$PROJECT/certlabpro-pcd-images/my-app:latest
   docker push us-central1-docker.pkg.dev/$PROJECT/certlabpro-pcd-images/my-app:latest
   

   Copier

   resource "google_artifact_registry_repository" "images" {
     repository_id = "certlabpro-pcd-images"
     location      = "us-central1"
     format        = "DOCKER"
     description   = "PCD lab Docker images"
   
     labels = local.labels
   
     depends_on = [google_project_service.artifactregistry]
   }

3. 3.Provisionnez un sujet + abonnement Pub/Sub (l'épine dorsale asynchrone)

   Déploie :

   • Pub/Sub

   Pub/Sub est le service de messagerie géré de GCP — le fondement de toute application événementielle suivant le modèle PCD. Les sujets sont des cibles de publication ; les abonnements sont des points de terminaison de consommateur (pull ou push). L'examen PCD teste la livraison au moins une fois + les consommateurs idempotents comme sémantique principale.

   Nous créons :

   1. Un sujet orders — où les producteurs publient.
   2. Un abonnement pull orders-worker — les consommateurs tirent de celui-ci. Les déploiements en production utilisent souvent des abonnements push vers des points de terminaison Cloud Run à la place (la forme événementielle canonique PCD : Pub/Sub push → Cloud Run) ; nous restons en mode pull ici pour simplifier IAM.

   ack_deadline_seconds = 60 donne aux consommateurs 60 secondes pour accuser réception ; plus long que le délai d'attente de requête par défaut de Cloud Run et un paramètre de réglage récurrent de l'examen PCD.

   Copier

   resource "google_pubsub_topic" "orders" {
     name = "orders"
   
     labels = local.labels
   
     depends_on = [google_project_service.pubsub]
   }
   
   resource "google_pubsub_subscription" "orders_worker" {
     name  = "orders-worker"
     topic = google_pubsub_topic.orders.id
   
     ack_deadline_seconds       = 60
     message_retention_duration = "604800s" # 7 days (max)
   
     retry_policy {
       minimum_backoff = "10s"
       maximum_backoff = "600s"
     }
   
     labels = local.labels
   }

4. 4.Déployez un service Cloud Run avec un compte de service à privilèges minimaux

   Déploie :

   • Cloud Run

   Cloud Run est le "conteneur en tant que service" de GCP — il exécute des conteneurs Docker sur l'infrastructure serverless de Google et se met à l'échelle jusqu'à zéro. Modèle recommandé par le PCD : chaque service Cloud Run s'exécute en tant que son propre compte de service, jamais le compte de service Compute par défaut.

   Nous déployons un service exécutant l'image publique hello comme substitut, attachons un compte de service par service avec roles/pubsub.subscriber sur le sujet de l'étape 3, et accordons roles/run.invoker à allUsers pour un accès non authentifié. Passez à un invocateur contrôlé par IAM pour la production — l'examen PCD teste cette bascule allUsers ↔ identité spécifique.

   Copier

   resource "google_service_account" "worker" {
     account_id   = "certlabpro-pcd-worker"
     display_name = "PCD lab Cloud Run worker"
   }
   
   resource "google_pubsub_subscription_iam_member" "worker_subscriber" {
     subscription = google_pubsub_subscription.orders_worker.name
     role         = "roles/pubsub.subscriber"
     member       = "serviceAccount:${google_service_account.worker.email}"
   }
   
   resource "google_cloud_run_v2_service" "worker" {
     name     = "certlabpro-pcd-worker"
     location = "us-central1"
   
     template {
       service_account = google_service_account.worker.email
   
       scaling {
         min_instance_count = 0 # scale-to-zero — no idle billing
         max_instance_count = 5
       }
   
       containers {
         image = "us-docker.pkg.dev/cloudrun/container/hello"
   
         resources {
           limits = {
             cpu    = "1"
             memory = "512Mi"
           }
         }
       }
     }
   
     labels = local.labels
   
     depends_on = [google_project_service.run]
   }
   
   resource "google_cloud_run_v2_service_iam_member" "public_invoker" {
     name     = google_cloud_run_v2_service.worker.name
     location = google_cloud_run_v2_service.worker.location
     role     = "roles/run.invoker"
     member   = "allUsers" # lab-only; production = specific identity
   }

5. 5.Stockez les identifiants d'application dans Secret Manager + accordez l'accès en lecture à Cloud Run

   Déploie :

   • Secret Manager

   Secret Manager est le magasin de secrets de GCP — valeurs versionnées, accès contrôlé par IAM, crochets de rotation automatique. Modèle recommandé par le PCD : la configuration d'application qui n'est pas un secret va dans les variables d'environnement ; la configuration d'application qui est un secret (clés API, mots de passe de base de données, jetons OAuth) va dans Secret Manager, référencée par le service Cloud Run.

   Nous créons un secret + une version initiale, puis accordons au compte de service Cloud Run de l'étape 4 le rôle roles/secretmanager.secretAccessor sur celui-ci. Pour intégrer le secret dans Cloud Run en tant que variable d'environnement, vous ajouteriez un bloc env { name = "..."; value_source { secret_key_ref { ... } } } dans le modèle de service (délibérément omis pour maintenir l'objectif de cette étape).

   Copier

   resource "google_secret_manager_secret" "db_password" {
     secret_id = "certlabpro-pcd-db-password"
   
     replication {
       auto {}
     }
   
     labels = local.labels
   
     depends_on = [google_project_service.secretmanager]
   }
   
   resource "google_secret_manager_secret_version" "db_password_v1" {
     secret      = google_secret_manager_secret.db_password.id
     secret_data = "lab-placeholder-rotate-me"
   }
   
   resource "google_secret_manager_secret_iam_member" "worker_reader" {
     secret_id = google_secret_manager_secret.db_password.id
     role      = "roles/secretmanager.secretAccessor"
     member    = "serviceAccount:${google_service_account.worker.email}"
   }

Nettoyage