נבדק לאחרונה: מאי 2026
בנו את שירותי AWS של בחינת PCDE עם Terraform פשוט — בלוק אחד בכל פעם, כאשר כל אחד מהם מקושר בחזרה לתחום במבחן. אותו הקוד עובד גם ב-OpenTofu.
בסיום מעבדה זו תצייד, באמצעות Terraform רגיל, תשתית CI/CD + ניטור תצורה (observability) בצורת PCDE — רפוזיטורי Artifact Registry לתמונות בנויות, טריגר Cloud Build העוקב אחר מקור GitHub דמה, צינור אספקה של Cloud Deploy עם שני יעדי Cloud Run (הכנה + ייצור), ו-Cloud Monitoring SLO + מדיניות התראה על יעד הייצור. חמישה בלוקים; לולאת ביצוע → בנייה → פריסה → תצפית הנבדקת ב-PCDE.
העתק את הקטעים לקובץ main.tf יחיד, הרץ terraform init, ולאחר מכן terraform apply צעד אחר צעד.
>= 1.5 או OpenTofu >= 1.6.your-project-id (ואופציונלית github-owner / github-repo בשלב 3) בקטעי הקוד.חינם או כמעט חינם בהיקף המעבדה:
min_instances = 0: $0 במצב סרק.~$0 לחודש בהיקף המעבדה.
אפשר את ממשקי ה-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
}צורת 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]
}טריגרים של Cloud Build הם הפרימיטיב של PCDE התחייבות לבנייה. אנו מגדירים טריגר על ענף ה-main של רפוזיטורי GitHub — כל push מפעיל את קובץ 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]
}Cloud Deploy הוא שירות ה-CD המנוהל של GCP — הוא מקדם גרסה דרך שלבים מסודרים (בדרך כלל פיתוח → הכנה → ייצור), כאשר כל שלב מגובה על ידי יעד (שירות 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]
}אוצר המילים של PCDE בנושא SLO / SLI / תקציב שגיאות הוא צורת הניטור התצורה העיקרית — כל שאלה בבחינת PCDE המסומנת Site Reliability בוחנת זאת. אנו מגדירים יעד רמת שירות (SLO): "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
}
}
}terraform destroy מפרק הכל. ה-Cloud Deploy pipeline + targets נהרסים בצורה נקייה (אין גרסאות בתהליך שיחסמו). שני שירותי Cloud Run נהרסים (min_instances = 0 ← אין חיוב על סרק במהלך המעבדה בכל מקרה). טריגר Cloud Build מתנתק. SLO + התראה + שירות ניטור נהרסים בצורה נקייה.
PCDE מכסה משטחים רבים שמעבדה זו אינה יכולה להכיל — צלילה עמוקה ב-Cloud Logging (ניתוב יומנים, כיורי יומנים, דליי יומנים, אינטגרציה של ניתוח יומנים ↔ BigQuery), Cloud Trace + Cloud Profiler + Cloud Debugger (ביצועי יישומים), Error Reporting, לוחות מחוונים של Cloud Monitoring + מדדים מותאמים אישית + בדיקות זמינות, מאגרי עובדים פרטיים של Cloud Build, כללי אישור של Cloud Build, אסטרטגיות canary + blue-green של Cloud Deploy, שלבי רינדור / אימות מותאמים אישית של Cloud Deploy, צינור הרינדור של Cloud Deploy מבוסס Skaffold, Binary Authorization לאכיפת אישור תמונות, Container Threat Detection, הגנת יישומי אינטרנט ו-API (WAAP) / Cloud Armor, Anthos Config Management + Policy Controller, GKE Backup, כל הספר של Google SRE / שיטות עבודה של SRE Workbook שבחינת PCDE מתייחסת אליהן לעתים קרובות.
אנו נצמדים לפרימיטיבים של Artifact Registry + Cloud Build + Cloud Deploy + Cloud Run + SLO/Alert מכיוון שהם לולאת CI/CD/Operate הקנונית של PCDE. Logging / Trace / Profiler / Debugger / Error Reporting כולם מתחברים לאותו שירות יעד ייצור. Binary Authorization שומר על שלב הקידום של Cloud Deploy. SLO-ים של Cloud Monitoring הם הפרימיטיב העיקרי לאמינות — יש להבין את הצורה נכון; ולשלב עוד משטחי טלמטריה ככל שהארכיטקטורה מבשילה.
לכיסוי קונספטואלי לפי שירות, עיין בקטעים עיון, מדריך, ו-Editorial בדף הסמכה זה.