Google PCD: Непрерывная доставка, конфигурация и автоматизация инфраструктуры — Руководство по подготовке

By Laurynas Brazys · 4 September 2026 · #google #PCD #certification #exam-prep #study-guide

Часть Google Professional Cloud Developer — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Google, или пройдите тесты на время на ExamRoll.io.

Обзор

Непрерывная поставка в Google Cloud объединяет автоматизацию сборок, управление артефактами, оркестрацию развертываний, инфраструктуру как код (IaC) и строгий контроль для многократной и безопасной доставки изменений. Надежные конвейеры сочетают неизменяемые артефакты и декларативную конфигурацию с политиками и возможностями аудита. В этом разделе рассматриваются проектные решения, операционные практики и распространенные сценарии сбоев при комплексной реализации Cloud Build, Cloud Deploy, Artifact Registry, Terraform, Kubernetes, флагов функций и механизмов управления.

Оркестрация сборки и развертывания

Cloud Build

Триггеры: Связывают сборки с событиями в исходном коде (пуши в ветки, теги, PR) или с расписаниями. Предпочтительнее использовать регулярные выражения для веток или тегов, чтобы гарантировать запуск только для целевых ссылок (refs). Триггеры могут выполняться от имени определенного сервисного аккаунта для соблюдения принципа наименьших привилегий; не полагайтесь на аккаунт по умолчанию, если сборкам требуется широкий доступ к API.
Шаги сборки: Каждый шаг выполняется в контейнере. Используйте специализированные сборщики (docker, gcloud) или кастомные, если стандартного набора инструментов недостаточно. Разделяйте шаги для компиляции, юнит-тестов, интеграционных тестов, линтинга, сканирования безопасности и упаковки артефактов, чтобы сбои можно было легко отследить, а результаты шагов — эффективно кэшировать.
Подстановки: Используйте встроенные переменные (PROJECT_ID, SHORT_SHA) и пользовательские подстановки (с префиксом $_) для параметризованных сборок. Не храните значения для конкретных сред в логике сборки; передавайте их через подстановки или определяйте позже на этапе развертывания.
Сервисные аккаунты: Сервисному аккаунту Cloud Build (PROJECT_NUMBER@cloudbuild.gserviceaccount.com) требуются явно назначенные роли (например, права на запись в Artifact Registry, администратор релизов Cloud Deploy). Назначайте минимальные роли и ограничивайте их область действия рамками проекта. Для доступа к частным ресурсам используйте частные пулы (Private Pools) с подключением к VPC.
Артефакты: Публикуйте неизменяемые образы в Artifact Registry и, при необходимости, загружайте неконтейнерные артефакты в Cloud Storage через секцию artifacts. Тегируйте образы как семантической версией, так и дайджестом коммита; используйте дайджесты образов в развертываниях, чтобы избежать расхождения тегов (tag drift).

Пример конфигурации Cloud Build:

cloudbuild.yaml: steps:
- name: gcr.io/cloud-builders/docker args: [“build”,"-t","$REGION-docker.pkg.dev/$PROJECT_ID/app/app:${SHORT_SHA}","."]
- name: gcr.io/cloud-builders/docker args: [“push”,"$REGION-docker.pkg.dev/$PROJECT_ID/app/app:${SHORT_SHA}"]
- name: gcr.io/cloud-builders/gcloud args: [“deploy”,“releases”,“create”,“app-${SHORT_SHA}”,"–delivery-pipeline=app-pipeline","–images=app=$REGION-docker.pkg.dev/$PROJECT_ID/app/app@sha256:${COMMIT_SHA}"] substitutions: _REGION: us-central1 serviceAccount: projects/$PROJECT_ID/serviceAccounts/cb-deployer@$PROJECT_ID.iam.gserviceaccount.com
Пример триггера: gcloud builds triggers create cloud-source-repositories –repo=my-repo –branch-pattern=^main$ –build-config=cloudbuild.yaml –service-account=cb-deployer@$PROJECT_ID.iam.gserviceaccount.com

Cloud Deploy

Конвейеры поставки (delivery pipelines) определяют упорядоченные этапы и цели (targets). Цели ссылаются на кластеры GKE, сервисы Cloud Run или другие поддерживаемые среды выполнения. Отметьте производственные этапы параметром requireApproval, чтобы контролировать продвижение.
Выкаты (rollouts) сопоставляют релиз с целью; продвижение (promotion) перемещает релиз по целям. Используйте прогрессивную доставку (канареечное, сине-зеленое развертывание) и хуки для проверок до и после развертывания.
Сценарии сбоев: Использование изменяемых тегов приводит к непреднамеренным обновлениям; всегда закрепляйте дайджесты. Отсутствие IAM-прав у аккаунта развертывания блокирует выкаты. Нерендерируемые манифесты или расхождение конфигураций для конкретных сред приводят к сбоям продвижения; проверяйте манифесты на этапе сборки.

Примеры определений для Cloud Deploy:

delivery-pipeline.yaml: apiVersion: deploy.cloud.google.com/v1 kind: DeliveryPipeline metadata: name: app-pipeline serialPipeline: stages:
- targetId: dev
- targetId: prod strategy: standard: verify: true requireApproval: true
targets.yaml: apiVersion: deploy.cloud.google.com/v1 kind: Target metadata: name: dev gke: cluster: projects/PROJECT/locations/REGION/clusters/DEV_CLUSTER
Определение производственной цели
apiVersion: deploy.cloud.google.com/v1 kind: Target metadata: name: prod gke: cluster: projects/PROJECT/locations/REGION/clusters/PROD_CLUSTER
Релиз и продвижение: gcloud deploy releases create app-20260903-1 –delivery-pipeline=app-pipeline –region=us-central1 –images=app=us-central1-docker.pkg.dev/PROJECT/app/app@sha256:IMAGE_DIGEST gcloud deploy releases promote –delivery-pipeline=app-pipeline –release=app-20260903-1 –region=us-central1

Артефакты и целостность цепочки поставок

Artifact Registry

Репозитории: Создавайте отдельные репозитории для каждой команды или среды, чтобы разграничить IAM-права и упростить очистку. Используйте региональные репозитории, расположенные рядом со сборщиками и средами выполнения, чтобы сократить исходящий трафик и задержки. Форматы пакетов включают образы Docker и пакеты для языков программирования (Maven, npm, PyPI).
Хранение: Определите политики очистки для удаления тегов, на которые нет ссылок, или старых тегов, сохраняя безопасное окно для отката. Избегайте агрессивных политик, которые могут удалить последнюю заведомо рабочую версию.
Происхождение и SBOM: Включите отслеживание происхождения сборок (provenance), чтобы образы содержали аттестации, соответствующие стандарту SLSA. Генерируйте SBOM (Software Bill of Materials) во время сборки и храните их как аттестации, улучшая процесс анализа уязвимостей.
Сканирование на уязвимости: Включите анализ контейнеров и прерывайте сборку или блокируйте продвижение при обнаружении CVE высокой степени серьезности, для которых нет исправлений или исключений в политике.
Компромиссы: Централизация всех артефактов в одном проекте упрощает управление, но может создать большой радиус поражения (blast radius); репозитории для каждой среды или приложения снижают риск, но увеличивают накладные расходы на управление.

Обеспечение целостности цепочки поставок

Binary Authorization в GKE может требовать аттестации (например, «собрано с помощью Cloud Build в проекте X», «нет критических CVE»). Интегрируйте его с контрольными точками Cloud Deploy, чтобы останавливать релизы, не соответствующие требованиям.
Сценарии сбоев: Опора на изменяемые теги, отключенное сканирование или неаутентифицированные запросы на получение образов может привести к попаданию непроверенного ПО в производственную среду. Закрепляйте дайджесты и требуйте аттестации.

Инфраструктура как код и GitOps

Terraform

Конфигурация и модули: Создавайте переиспользуемые модули с чёткими входами/выходами и семантическим версионированием. Публикуйте модули в общем репозитории или реестре; закрепляйте (pin) версии, чтобы избежать неожиданных изменений.
Состояние (state): Используйте бэкенд GCS для удалённого хранения состояния с IAM на уровне бакета, версионированием объектов и CMEK. Защищайте состояние от ручных правок и обеспечивайте его шифрование. Избегайте хранения секретов в состоянии, считывая их из Secret Manager во время применения (apply) и экономно используя источники данных (data sources).

undefined

Планирование и применение (Plans and applies): Запускайте terraform plan с флагом -out и проверяйте diff с помощью человека или автоматизированного шлюза; применяйте только ранее утверждённый план. Используйте -refresh-only или -detailed-exitcode в задачах по обнаружению расхождений (drift detection).
Разделение сред: Используйте отдельные проекты, бакеты для состояния и сервисные аккаунты для каждой среды. Для сложных организаций предпочитайте структуру «каталог на среду» с файлами переменных вместо использования рабочих пространств (workspaces). Никогда не используйте общее состояние для разных сред.
Сценарии сбоев: Одновременные применения (applies) повреждают состояние; обеспечивайте сериализацию с помощью CI/CD и блокировок (GCS использует object preconditions). Ручные изменения в консоли вызывают расхождения (drift); ограничивайте прямые изменения и запускайте периодические задачи plan.

Декларативная конфигурация Kubernetes

Манифесты: Сохраняйте декларативный подход к объектам Kubernetes; избегайте императивных команд kubectl в производственных процессах. Закрепляйте (pin) дайджесты образов и запросы/лимиты ресурсов (requests/limits).
Kustomize: Используйте base + overlays для применения специфичных для среды патчей без создания форков чартов. kustomization.yaml (наложение):

undefined

Helm: Используйте файлы values для каждой среды; документируйте порядок приоритетов (значения из командной строки переопределяют файлы values, которые, в свою очередь, переопределяют значения по умолчанию в чарте). Шаблонизируйте и рендерьте в CI (skaffold render или helm template), чтобы конфигурации на момент развёртывания были неизменяемыми.
GitOps: Храните желаемое состояние в Git. Используйте Cloud Deploy или Config Sync для приведения кластеров в соответствие с состоянием в Git (reconciliation). PR (Pull Requests) становятся основной поверхностью для управления изменениями, обеспечивая аудиторский след и проверку политик. Избегайте изменений через kubectl exec, которые не зафиксированы в Git.

Безопасность релизов, конфигурация и управление

Функциональные флаги и конфигурация времени выполнения

Функциональные флаги отделяют развертывание от релиза; поставляйте неактивный код и включайте его для определенных когорт, процентов пользователей или регионов. Храните определения флагов в системе с высокой доступностью и низкой задержкой (Firestore, Memorystore) и кэшируйте их с коротким TTL. Логируйте оценки флагов для прослеживаемости.
Постепенное развертывание: комбинируйте разделение трафика (Cloud Run) или канареечные подмножества (GKE) с флагами, чтобы минимизировать радиус поражения. Используйте метрики работоспособности и автоматические триггеры отката на основе SLO.
Безопасный откат: предпочитайте быстрое отключение через функциональные флаги. Для отката бинарного файла продвиньте последний заведомо рабочий релиз или повторно примените дайджест предыдущего манифеста.

Переменные окружения, приоритет, секреты

Приоритет обычно следующий: флаги времени выполнения > переменные окружения > файлы конфигурации > значения по умолчанию в коде. Документируйте и стандартизируйте этот порядок во всех сервисах.
Внедряйте конфигурацию с помощью ConfigMaps и переменных окружения; используйте Secret Manager или Kubernetes Secrets для конфиденциальных значений. Регулярно ротируйте секреты и избегайте их «запекания» в образы.
Примеры внедрения секретов:
- Переменная окружения в Cloud Run: gcloud run services update api –update-secrets=DB_PASSWORD=projects/PROJECT/secrets/db_password:latest
- CSI-драйвер Secret Manager в GKE: apiVersion: v1 kind: Pod metadata: name: app spec: volumes:
  - name: sm csi: driver: secrets-store.csi.k8s.io readOnly: true volumeAttributes: secretProviderClass: gsm-secrets containers:
  - name: app volumeMounts:
    - name: sm mountPath: /secrets

Контрольные точки качества в CI/CD

Модульные тесты (unit tests) запускаются при каждом коммите; первостепенное значение имеет быстрая обратная связь.
Интеграционные тесты запускаются в эфемерных средах или песочницах с предварительно заполненными данными.
Проверки безопасности: SAST, сканирование зависимостей, сканирование уязвимостей контейнеров, проверки политик IaC (Conftest, Policy Controller). Блокируйте слияния или продвижения релизов при обнаружении критических уязвимостей.
Проверки развертывания: действия predeploy и postdeploy в Cloud Deploy проверяют готовность, безопасность миграций базы данных и выполняют дымовые тесты (smoke tests).

Ветвление, ревью кода, версионирование, прослеживаемость

Предпочитайте разработку на основе транка (trunk-based development) с короткоживущими ветками функций и обязательными ревью PR. Применяйте обязательные проверки и линейную историю для возможности аудита.
Версионирование: теги семантического версионирования для релизов; дайджесты образов и SHA коммитов для неизменяемости. Избегайте использования перемещаемых тегов, таких как latest, в производственных развертываниях.
Прослеживаемость: аннотируйте сборки и релизы идентификаторами коммита, PR и тикета. Отправляйте события развертывания в Logging; прикрепляйте метки к ресурсам для отслеживания затрат и владения.

Дрейф инфраструктуры, политики, аудит, контроль изменений

Обнаружение дрейфа: запланированный запуск terraform plan -detailed-exitcode; оповещение при ненулевом коде возврата. Для кластеров Config Sync обеспечивает итоговую сходимость с состоянием в Git.
Применение политик: используйте Organization Policy для установки ограничительных барьеров (например, ограничение внешних IP), Policy Controller для ограничений KRM и Binary Authorization для политик образов.
Журналы аудита: включите журналы Admin Activity и Data Access; направляйте их в централизованные проекты с приемниками (sinks) и сроками хранения, соответствующими требованиям комплаенса. Cloud Asset Inventory предоставляет историю изменений и анализ доступа.
Контроль изменений: ручные утверждения при продвижении в производственную среду с обоснованиями, зафиксированными в аннотациях. Окна заморозки (freeze windows) можно закодировать как проверки политик в CI/CD. Убедитесь, что пути экстренного отката задокументированы и отработаны.

Практический сценарий

Компании Acme Retail необходимо развернуть новый сервис order-service в GKE для сред dev и prod с безопасными канареечными выкатками, строгим применением политик и полной прослеживаемостью релизов. Команда должна стандартизировать управляемую через Terraform инфраструктуру, декларативную конфигурацию Kubernetes с Kustomize и аудируемый CI/CD с использованием Cloud Build и Cloud Deploy.

Подход:

Создание репозиториев артефактов и идентификаторов

Создайте региональные репозитории Artifact Registry order-docker-dev и order-docker-prod. Предоставьте сервисному аккаунту Cloud Build в проекте приложения роли roles/artifactregistry.writer, а узлам GKE — roles/artifactregistry.reader для соответствующего репозитория.
Обоснование: Раздельные репозитории уменьшают радиус поражения и упрощают политики жизненного цикла. Явное назначение IAM позволяет избежать избыточных прав по умолчанию.

Определение инфраструктуры с помощью Terraform с разделением сред

Создайте директории terraform/envs/dev и terraform/envs/prod. Каждая конфигурация включает бэкенд в GCS с отдельными бакетами для состояния, модуль кластера GKE и привязки IAM для сервисного аккаунта Cloud Deploy. Выполняйте terraform init, plan -out=plan.bin и apply plan.bin в CI-задании с контролем доступа для каждой среды.
Обоснование: Состояние и проекты для каждой среды предотвращают случайное взаимное влияние; файлы планов поддерживают ревью и аудируемый контроль изменений.

Создание базовой декларативной конфигурации Kubernetes и оверлеев Kustomize

Разместите манифесты Kubernetes в k8s/base для Deployment, Service и HPA с образами, закрепленными по дайджесту. Создайте k8s/overlays/dev и k8s/overlays/prod с патчами для количества реплик, запросов ресурсов и конфигурации. Используйте класс CSI-драйвера Secret Manager для учетных данных базы данных.
Обоснование: Единый источник истины с оверлеями устраняет дрейф и сохраняет конфигурации по принципу DRY, позволяя при этом безопасно вносить специфичные для среды различия.

Реализация Cloud Build с отдельными шагами тестирования и упаковки

cloudbuild.yaml включает шаги: линтинг и модульные тесты, интеграционные тесты в одноразовом пространстве имен dev, сборка и отправка контейнера в репозиторий среды, генерация SBOM и сканирование на уязвимости, а также генерация сведений о происхождении. Триггер запускается на PR в main для тестов и на слияниях для упаковки. Сборки выполняются от имени сервисного аккаунта cb-deployer с минимальными привилегиями.
Обоснование: Раннее обнаружение ошибок обходится дешевле; разделение задач улучшает наблюдаемость и позволяет выполнять целевые повторные запуски. Принцип минимальных привилегий снижает риск для цепочки поставок.

Настройка конвейера доставки Cloud Deploy с ручным утверждением для prod и канареечной стратегией

Определите DeliveryPipeline с целевыми средами dev и prod. Этап prod требует утверждения и использует канареечную стратегию (например, 10%, затем 100%). Используйте хуки predeploy для проверки совместимости схем и дымовых тестов; postdeploy проверяет SLO.
Обоснование: Прогрессивная доставка ограничивает радиус поражения и вводит автоматизированные контрольные точки качества, в то время как ручное утверждение обеспечивает участие человека в процессе для prod-среды.

Настройка GitOps и принудительного применения политик

Защитите ветку main обязательными ревью и прохождением проверок. Используйте ограничения Policy Controller, чтобы блокировать привилегированные поды и запрещать изменяемые теги. Включите Binary Authorization, чтобы требовать сведения о происхождении от Cloud Build и аттестации «нет высоких CVE» перед допуском (admission).
Обоснование: Политика как код (Policy-as-code) предотвращает попадание рискованных конфигураций в кластер и обеспечивает последовательное применение правил.

Управление конфигурацией и функциональными флагами для безопасного релиза

Храните несекретную конфигурацию времени выполнения в ConfigMaps; секреты предоставляются через CSI-драйвер Secret Manager. Введите функциональный флаг order_new_flow, считываемый из Firestore, с начальной выкаткой на 1% в prod; флаги кэшируются с коротким TTL и логируются.
Обоснование: Флаги отделяют релиз от развертывания, позволяя мгновенно отключить функциональность при возникновении проблем без отката бинарного файла.

Обеспечение наблюдаемости, обнаружения дрейфа и прослеживаемости

Аннотируйте сборки и релизы SHA коммита, номером PR и идентификатором тикета на изменение. Направляйте события Cloud Deploy и журналы аудита GKE в центральный проект Logging. Еженощные задания terraform plan оповещают о дрейфе; Config Sync отслеживает расхождение с KRM, приводя состояние в соответствие с Git.
Обоснование: Полные сведения о происхождении и журналы аудита ускоряют реагирование на инциденты; непрерывное обнаружение дрейфа поддерживает целостность инфраструктуры.

Выполнение откатов и контроль изменений

При инцидентах сначала отключите order_new_flow с помощью флага. При необходимости продвиньте предыдущий успешный релиз в Cloud Deploy в среды dev и prod. Все продвижения в prod требуют указания ссылки на тикет в аннотациях релиза и утверждения от дежурного SRE.
Обоснование: Флаги обеспечивают мгновенное устранение последствий; неизменяемые релизы обеспечивают предсказуемый откат. Утверждения и аннотации удовлетворяют требованиям операционного управления и комплаенса.

← Идентификация · Все домены · Наблюдаемость →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →