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

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

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

Обзор

Развертывание, конфигурация и автоматизация в Google Cloud сосредоточены на повторяемой, аудируемой и безопасной доставке изменений. Надежная практика основывается на инфраструктуре как коде (IaC), декларативных шаблонах, неизменяемых артефактах и стандартизированных конвейерах. Операционное совершенство достигается за счет проектирования с учетом идемпотентности, предварительного просмотра изменений, принудительного применения политик и планирования контролируемых выкаток с четкими путями отката. В следующих разделах представлены практические паттерны, примеры команд и обоснование проектных решений, включая распространенные ошибки и компромиссы.

Основы инфраструктуры как кода и конфигурации

Принципы:

Декларативные шаблоны описывают желаемое конечное состояние; инструментарий приводит фактическое состояние в соответствие с ним. Это улучшает идемпотентность, повторяемость и аудируемость.
Неизменяемая (иммутабельная) инфраструктура предполагает развертывание новых экземпляров или ревизий вместо изменения существующих, что упрощает откат и уменьшает дрейф конфигурации.
Разделение ответственности: параметризуйте значения для конкретных сред, повторно используя общие модули или шаблоны.

Terraform в Google Cloud:

Конфигурация: файлы HCL определяют ресурсы, переменные и выходные данные. Используйте модули для инкапсуляции VPC, сервисных аккаунтов или кластеров GKE; публикуйте общие модули внутри компании для стандартизации паттернов.
Состояние (state): Храните состояние удаленно и с версионированием. Используйте бэкенд Cloud Storage с версионированием объектов и, при необходимости, с политикой хранения в бакете.
- Пример блока бэкенда:

undefined

Сценарии сбоев: локальное состояние или бакеты без версионирования несут риск потери данных и проблем с одновременной записью. Обеспечьте доступ к бакету состояния с минимальными привилегиями; предпочитайте кратковременные учетные данные и имперсонацию сервисных аккаунтов вместо ключей.
Планирование и применение: terraform plan предоставляет предварительный просмотр; контролируйте выполнение apply в CI/CD с ручным подтверждением для производственной среды. Используйте -target с осторожностью; частое использование -target увеличивает риск дрейфа.
Модули: версионируйте модули семантически; закрепляйте (пиньте) версии, чтобы избежать незапланированных изменений. Проверяйте конфигурацию с помощью terraform validate и проверок политик перед применением.
Импорт и дрейф: terraform import позволяет взять существующие ресурсы под управление; после этого требуется тщательная проверка состояния. Обнаруживайте дрейф, регулярно запуская terraform plan.
Удаленное выполнение: запускайте Terraform в заданиях Cloud Build или Cloud Run с использованием Workload Identity Federation, чтобы избежать использования ключей сервисных аккаунтов. Кэшируйте провайдеры для сокращения времени сборки.

Deployment Manager:

Хотя многие команды стандартизируют свою работу на Terraform, вы можете столкнуться с Deployment Manager. Чтобы обновить развертывание без простоя, обновите его конфигурацию:

undefined

Стандарты конфигурации:

Именование: используйте последовательные, легко разбираемые имена, включающие среду, регион, назначение и порядковый номер, например, vpc-prod-usw1-core.
Метки (labels): прикрепляйте ко всем ресурсам метки, такие как env, cost_center, owner и app; обеспечивайте их наличие с помощью политик или проверок.
Теги (tags): используйте сетевые теги для определения области действия правил брандмауэра; избегайте перегрузки тегов для идентификации или владения (для этого лучше подходят метки).
Метаданные: используйте метаданные экземпляров для стартовых скриптов и конфигурации; предпочитайте метаданные с контрольной суммой или флагами версий для контроля повторных запусков. Не размещайте секреты в метаданных; используйте Secret Manager.

API, активация сервисов, квоты и сервисные аккаунты:

Активируйте необходимые сервисы на раннем этапе автоматизации:

undefined

Проверяйте наличие запаса квот на этапе планирования; тесты на масштабирование должны включать проверку квот, чтобы избежать троттлинга.
Используйте выделенные сервисные аккаунты для каждой рабочей нагрузки и среды; предоставляйте IAM-роли с минимальными привилегиями в самом узком возможном скоупе. Для доступа людей предпочитайте членство в группах, а для автоматизации — имперсонацию сервисных аккаунтов.

Конвейеры доставки и продвижение артефактов

Cloud Build:

Определите шаги Cloud Build для сборки, тестирования и упаковки артефактов. Используйте подстановки для динамических значений и Secret Manager для учетных данных.
Запускайте сборки по изменениям в исходном коде; изолируйте сервисные аккаунты сборок по репозиториям или средам и предоставляйте только необходимые разрешения.
Кэшируйте слои Docker и зависимости языков программирования для сокращения времени сборки. Следите за лимитами одновременных сборок и квотами на эфемерные воркеры.

Продвижение артефактов:

Храните образы контейнеров или пакеты в Artifact Registry. Продвигайте их путем:
- Повторного тегирования неизменяемых дайджестов для конкретной среды (например, :qa, :prod) или
- Копирования артефактов в репозиторий, специфичный для данной среды.
Компромиссы: единый репозиторий с тегами упрощает поиск, но требует строгого управления; репозитории для каждой среды усиливают изоляцию и применение политик.

Cloud Deploy:

Смоделируйте конвейер доставки с упорядоченными целями (targets), например, dev → qa → prod. Релизы ссылаются на конкретный дайджест артефакта и манифест развертывания.
Для GKE и Cloud Run сервис Cloud Deploy использует конфигурации Skaffold для рендеринга и применения манифестов. Настройте согласования, проверки и шлюзы (gates).
Выкатка и откат:
- Канареечное развертывание с постепенным переключением трафика уменьшает радиус поражения.
- Сине-зеленое (blue/green) развертывание обеспечивает быстрое переключение и откат ценой дополнительной емкости.
- Выполняйте откат путем закрепления последней удачной версии релиза; избегайте исправлений «на месте», которые создают дрейф.
Сценарии сбоев: несоответствие разрешений в кластере, отсутствующие API и ошибки в схеме манифеста. Обнаруживайте их на ранней стадии, выполняя рендеринг манифестов во время сборки и проверяя их на соответствие политикам кластера.

Планирование безопасных изменений:

Требуйте предварительного просмотра (plan или render), автоматических тестов, проверки политик и ручного подтверждения для производственной среды.
Для управляемых групп экземпляров Compute Engine настраивайте политику обновления maxSurge/maxUnavailable и параметры проверки работоспособности, чтобы избежать избыточного выделения ресурсов при медленной готовности приложения.

Операции в командной строке и управление окружением

Конфигурации Cloud Shell и gcloud:

Cloud Shell предоставляет управляемую среду администрирования с предварительно аутентифицированным gcloud и постоянным домашним каталогом.
Используйте именованные конфигурации для быстрого переключения между аккаунтами, проектами и регионами: gcloud config configurations create prod gcloud config set project my-prod gcloud config set compute/region us-central1 gcloud config set compute/zone us-central1-a gcloud config configurations activate prod
Проверьте активную конфигурацию с помощью gcloud config list. Для GKE получите учетные данные: gcloud container clusters get-credentials my-cluster –region us-central1

Шаблоны команд для Compute:

Создание ВМ с зарезервированным внутренним IP-адресом: gcloud compute addresses create license-ip –region=us-central1 –subnet=default –addresses=10.0.3.21 gcloud compute instances create license-server –zone=us-central1-a –subnet=default –private-network-ip=10.0.3.21 –tags=license
Создание пользовательской VPC, подсети и правила брандмауэра: gcloud compute networks create core –subnet-mode=custom gcloud compute networks subnets create core-us –network=core –range=10.0.0.0/20 –region=us-central1 gcloud compute firewall-rules create allow-https –network=core –allow=tcp:443 –target-tags=web

Шаблоны для IAM:

Предоставление роли на уровне проекта: gcloud projects add-iam-policy-binding my-project –member=group:ops@example.com –role=roles/logging.viewer
Копирование пользовательских ролей между проектами: gcloud iam roles copy myCustomRole –source=my-dev –destination=my-prod

Шаблоны для Storage:

Создание бакета и загрузка объектов: gcloud storage buckets create gs://backups-prod –location=us-central1 –class=coldline –uniform-bucket-level-access gcloud storage cp ./backup.tar.gz gs://backups-prod/
Настройте жизненный цикл через файл и примените с помощью gcloud storage buckets update –lifecycle-file=policy.json

Включение и проверка API:

Включение Pub/Sub для приложения: gcloud services enable pubsub.googleapis.com
Вывод списка включенных сервисов: gcloud services list –enabled

Управление, дрейф и автоматизация

Дрейф конфигурации и применение политик:

Обнаруживайте дрейф, запуская terraform plan по расписанию; прерывайте сборки при непредвиденных изменениях.
Применяйте ограничения политик организации (например, запрет на внешние IP-адреса) и проверяйте конфигурации ресурсов с помощью политик как кода (policy-as-code) перед применением.
Для Kubernetes используйте Config Sync и Policy Controller, чтобы непрерывно сверять состояние и блокировать несоответствующие изменения.
Аудит: используйте журналы Admin Activity и Data Access; направляйте их в BigQuery для анализа. Используйте Cloud Asset Inventory для запросов о состоянии на определённый момент времени и за прошлые периоды.

Квоты и лимиты:

Проверяйте квоты для каждого региона и проекта; планируйте запас для автомасштабирования и развёртываний: gcloud compute regions describe us-central1 --format="yaml(quotas)"
Запрашивайте увеличение заблаговременно до планируемого роста или крупных развёртываний.

Автоматизация операционных задач:

Cloud Scheduler запускает по cron-расписанию HTTP-эндпоинты, темы Pub/Sub или Workflows. Обеспечьте идемпотентность обработчиков; настройте повторные попытки и темы для недоставленных сообщений (dead-letter topics).
Workflows оркестрируют многошаговую автоматизацию через API Google с повторными попытками, параллельными шагами и логикой компенсации.
Задания Cloud Run выполняют контейнеризированные пакетные или административные задачи по запросу или через Scheduler. Предпочитайте задания для одноразовых или итеративных рабочих нагрузок; используйте минимальные права для сервисного аккаунта задания.

Безопасность развёртывания и наблюдаемость:

Встраивайте проверки работоспособности (health checks) и готовности (readiness probes) в сервисы. Для MIG с медленным запуском увеличьте начальную задержку, чтобы предотвратить преждевременные действия по масштабированию.
Собирайте метрики развёртывания и бюджеты ошибок; приостанавливайте или автоматически отменяйте развёртывания при ухудшении SLO.

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

Компании Altostrat Media необходимо стандартизировать развёртывания в нескольких средах для сервиса на базе GKE, устранить дрейф конфигурации и обеспечить возможность быстрого отката. Они также должны зарезервировать статический внутренний IP-адрес для устаревшего сервера лицензий, не перенастраивая приложение.

Создайте базовые модули Terraform и удалённое состояние

Реализуйте модули для VPC, подсетей, GKE, сервисных аккаунтов и правил брандмауэра. Настройте бэкенд в Cloud Storage с версионированием и политикой хранения для бакета состояния.
Обоснование: Модуляризация способствует повторному использованию и единообразию; удалённое версионируемое состояние обеспечивает совместную работу, восстанавливаемость и блокировки.

Включите необходимые сервисы и создайте учётные данные для автоматизации с минимальными привилегиями

Включите compute.googleapis.com, container.googleapis.com, clouddeploy.googleapis.com, artifactregistry.googleapis.com.
Создайте сервисные аккаунты для каждой среды для Terraform, Cloud Build и Cloud Deploy; предоставьте минимальные роли (например, roles/container.admin для тех, кто развёртывает, а не для сборщиков).
Обоснование: Предварительное включение сервисов и точное определение ролей уменьшают количество сбоев при развёртывании и ограничивают радиус поражения.

Подготовьте сеть и зарезервируйте IP-адрес для устаревшего сервера

С помощью Terraform создайте кастомную VPC, региональные подсети и правила брандмауэра на основе сетевых тегов.
Зарезервируйте внутренний IP-адрес: gcloud compute addresses create license-ip --region=us-central1 --subnet=core-us --addresses=10.0.3.21
Обоснование: Декларативное управление сетью обеспечивает воспроизводимость; резервирование IP-адреса сохраняет допущения, заложенные в приложении.

Соберите артефакты с помощью Cloud Build и опубликуйте их в Artifact Registry

Определите cloudbuild.yaml для запуска тестов, сборки контейнера, сканирования и отправки неизменяемого дайджеста в Artifact Registry.
Обоснование: Неизменяемые, просканированные артефакты — основа для безопасных повышений и отслеживания происхождения.

Настройте конвейер Cloud Deploy с целевыми средами dev → qa → prod

Определите конвейер доставки и целевые среды; укажите ссылку на конфигурацию Skaffold для рендеринга манифестов. Настройте обязательное ручное подтверждение для prod и проверки (verifications).
Обоснование: Структурированное продвижение по средам обеспечивает контроль; политики для каждой целевой среды предотвращают случайное развёртывание в прод.

Выполните развёртывание обновлений в GKE с использованием канареечной стратегии и проверок работоспособности (health gates)

Используйте политику канареечного развёртывания для переключения 10%, затем 50%, затем 100% трафика в зависимости от проверок SLO и уровня ошибок.
Обоснование: Постепенная доставка снижает риски и предоставляет естественные точки для отката.

Устраните дрейф с помощью плановых запусков и проверок политик

Еженощное задание запускает terraform plan и валидатор политик как кода; отправляет оповещения о непредвиденных расхождениях или нарушениях.
Обоснование: Раннее обнаружение предотвращает накопление дрейфа и сбои будущих применений конфигурации.

Введите в эксплуатацию ВМ с сервером лицензий, используя зарезервированный IP

Создайте ВМ, привязанную к зарезервированному адресу и с соответствующими тегами: gcloud compute instances create license-server --zone=us-central1-a --subnet=core-us --private-network-ip=10.0.3.21 --tags=license
Обоснование: Обеспечивает доступность без изменения приложения; теги позволяют создавать узконаправленные правила брандмауэра.

Автоматизируйте повторяющиеся задачи с помощью Scheduler, Workflows и заданий

Cloud Scheduler запускает Workflow для ротации ключей сервисных аккаунтов (где это неизбежно) и для запуска задания Cloud Run для еженедельной очистки базы данных.
Обоснование: Централизованное планирование в сочетании с оркестрацией обеспечивает надёжность и наблюдаемость с повторными попытками и компенсацией.

Спланируйте откаты и проверьте пороги готовности

Определите сценарии отката (playbooks) для повторного развёртывания последнего удачного релиза. Настройте проверки готовности и для любых рабочих нагрузок на базе MIG увеличьте начальные задержки проверок работоспособности, чтобы они соответствовали времени прогрева приложения.
Обоснование: Заранее спланированный откат и настроенные проверки работоспособности предотвращают каскадные сбои и избыточное выделение ресурсов во время инцидентов.

Этот подход объединяет неизменяемые артефакты, декларативную инфраструктуру, контролируемые повышения по средам и автоматизацию с минимальными привилегиями для обеспечения безопасных, аудируемых и воспроизводимых операций в Google Cloud.

← Хранилища · Все домены · Мониторинг →

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