Лабораторная работа — PCDE Google Cloud Professional Cloud Database Engineer

Обзор

Предварительные требования

Шаги

1. 1.Провайдер, службы проекта, именование

   Включите API Cloud Build, Cloud Deploy, Cloud Run, Artifact Registry и Cloud Monitoring.

   Копировать

   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.Создание целевого репозитория Artifact Registry для образов

   Создаваемые ресурсы:

   • Artifact Registry

   Канонический вид CI/CD для PCDE: Cloud Build выводит образы в Artifact Registry; Cloud Deploy продвигает тот же SHA-хеш образа через среды. Репозиторий является единственным источником истины для всех сред — неизменяемые образы, изменяемые теги.

   Копировать

   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.Определение триггера Cloud Build для репозитория GitHub

   Создаваемые ресурсы:

   • Cloud Build

   Триггеры Cloud Build — это примитив фиксации-в-сборку в PCDE. Мы определяем триггер для ветки main репозитория GitHub — каждое изменение запускает cloudbuild.yaml в корне репозитория, который выполнит docker build + docker push в Artifact Registry из Шага 2.

   Замените github-owner и github-repo на ваш фактический репозиторий. Триггер будет создан, но не сработает, пока приложение GitHub Cloud Build не будет установлено в репозитории (одноразовый ручной шаг в консоли).

   Копировать

   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.Настройка конвейера Cloud Deploy с целевыми объектами Cloud Run для промежуточной → производственной среды

   Создаваемые ресурсы:

   • Cloud Deploy
   • Cloud Run

   Cloud Deploy — это управляемый сервис CD от GCP, который продвигает релиз через упорядоченные стадии (обычно dev → staging → prod), каждая из которых поддерживается целевым объектом (сервисом Cloud Run, кластером GKE или кластером Anthos). Экзамен PCDE активно проверяет эту модель один релиз, много продвижений.

   Мы определяем две целевые службы Cloud Run (одну для промежуточной среды, одну для производственной, обе масштабируются до нуля) + один конвейер доставки, связывающий их. Реальный релиз запускался бы с помощью gcloud deploy releases create после успешного выполнения Cloud Build; эта лабораторная работа предусматривает создание основы без запуска релиза.

   Копировать

   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.Определение SLO + политики оповещений для производственной службы

   Создаваемые ресурсы:

   • Cloud Monitoring

   Лексика SLO / SLI / бюджета ошибок в PCDE — это основной элемент наблюдаемости; каждый вопрос экзамена PCDE с меткой Надежность сайта проверяет это. Мы определяем цель уровня обслуживания: «99% HTTP-запросов к производственной службе должны возвращать 2xx в течение 28-дневного скользящего окна». Затем оповещение Cloud Monitoring срабатывает, когда скорость выгорания указывает на слишком быстрое исчерпание бюджета.

   После размещения пяти блоков (Artifact Registry, триггер Cloud Build, два целевых объекта Cloud Run, конвейер Cloud Deploy, SLO и оповещение для производственной среды) цикл PCDE фиксация → сборка → развертывание → наблюдение полностью подготовлен.

   Копировать

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

Очистка ресурсов