CI/CD с Cloud Build: конфигурация и триггеры

Быстрые ссылки

• Writing a Build Configuration

• Setting Up Cloud Source & Cloud Build

CI/CD (непрерывная интеграция и непрерывная доставка) — это процесс автоматизации обновлений приложения: от фиксаций в системе контроля версий до автоматических сборок и развертываний на целевые окружения. В GCP эту задачу решает Cloud Build.

Что делает Cloud Build

Cloud Build получает исходники (из Cloud Source или внешнего Git), выполняет последовательность шагов (build steps) — тесты, сборка, упаковка — и отправляет артефакты в App Engine, GKE, Cloud Run, Cloud Functions или в Cloud Storage.

Важно: конфигурация сборки задаётся в YAML-файле, чаще всего называемом cloudbuild.yaml.

Структура cloudbuild.yaml — краткий обзор

Ниже — схема полей, которые можно указать в cloudbuild.yaml. Не все поля обязательны; большинство проектов используют небольшой набор.

steps:

• name: string

  args: [string, string, …]

  env: [string, string, …]

  dir: string

  id: string

  waitFor: [string, string, …]

  entrypoint: string

  secretEnv: string

  volumes: object(Volume)

  timeout: string (Duration format)

• name: string

…

• name: string

…

timeout: string (Duration format)

queueTtl: string (Duration format)

logsBucket: string

options:

env: [string, string, …]

secretEnv: string

volumes: object(Volume)

sourceProvenanceHash: enum(HashType)

machineType: enum(MachineType)

diskSizeGb: string (int64 format)

substitutionOption: enum(SubstitutionOption)

logStreamingOption: enum(LogStreamingOption)

logging: enum(LoggingMode)

substitutions: map (key: string, value: string)

tags: [string, string, …]

secrets: object(Secret)

images:

• [string, string, …]

artifacts: object (Artifacts)

Вы не обязаны заполнять всё — в простых проектах хватает секции steps и artifacts.

Простой пример cloudbuild.yaml для NPM-приложения

steps:

# Install dependencies

- name: node

  entrypoint: npm

  args: ['install']

# Run tests

- name: node

  entrypoint: npm

  args: ['test']

# Run custom commands

- name: node

  entrypoint: npm

  args: ['run', 'build']

artifacts:

  objects:

    location: 'gs://mybucket/'

    paths: ['build']

Пояснение: сначала устанавливаются зависимости, затем выполняются тесты, затем запускается сборка. Готовые файлы из папки build будут выгружены в gs://mybucket/. Вместо Cloud Storage вы можете настроить деплой в GKE, Cloud Run, Cloud Functions или App Engine.

Локальные сокращения и переменные

• substitutions: позволяют параметризовать конфигурацию (например, ветка, версия). Используйте ключи вида _TAG или _ENV.
• secretEnv и secrets: храните секреты (пароли, ключи) вне репозитория и передавайте в контейнер на этапе выполнения.

Совет: для многоцелевых pipeline используйте substitutions + мульти-триггеры (один cloudbuild.yaml, разные значения substitution для dev/prod).

Подключение репозитория и создание триггера

Cloud Build обычно получает исходники из Cloud Source — GCP-репозитория с поддержкой Git. Если вы используете GitHub или Bitbucket, можно привязать внешний аккаунт.

1. Создайте или импортируйте репозиторий в Cloud Source.

2. В Cloud Build на дашборде выберите Set Up Build Trigger.

3. Дайте триггеру имя, выберите репозиторий и укажите условие запуска: коммиты в ветку, теги, pull request. Можно использовать регулярные выражения для веток.

4. Укажите путь до cloudbuild.yaml (по умолчанию root). Задайте substitutions, если нужно.

5. Создайте триггер и протестируйте его ручным запуском.

После создания триггер будет автоматически запускаться по настроенному условию (push, PR, tag).

Частые задачи и рекомендации

• Логирование: используйте logsBucket или стандартные логи Cloud Build. Для отладки включите пошаговую отправку логов (log streaming).
• Ресурсы: для тяжёлых сборок указывайте machineType и diskSizeGb в options.
• Кэширование: используйте внутренний кэш или внешний (например, кеш npm в корне контейнера), чтобы сократить время сборки.
• Параллельные шаги: указывайте waitFor чтобы управлять зависимостями между шагами.

Отладка неудачных сборок

• Просмотрите логи в Cloud Build — ошибки в шагах обычно очевидны.
• Запустите локально Docker-образ того шага (тот же образ, что указан в name) и воспроизведите команду.
• Проверьте права сервисного аккаунта Cloud Build: доступ к репозиторию, GCS, GKE, Cloud Run и т.д.
• Если артефакты не загружаются — убедитесь в корректности пути gs:// и прав на бакет.

Когда этот подход не подходит

• Очень чувствительные данные: если политика компании запрещает внешний CI в облаке.
• Требуются специфичные хостированные агенты или лицензированное ПО, которое нельзя запускать в контейнере.
• Сильные требования к времени отклика сборки; в этом случае локальные или self-hosted раннеры иногда быстрее.

Альтернативы Cloud Build

• GitHub Actions — удобная интеграция для проектов на GitHub.
• GitLab CI — если исходники хранятся в GitLab.
• Jenkins/TeamCity — для self-hosted и гибкой интеграции с существующей инфраструктурой.

Плейбук: быстрый сценарий настройki и тестирования

1. Создайте cloudbuild.yaml в корне репозитория с простым pipeline.
2. Создайте тестовый бакет в GCS для артефактов (gs://mybucket-test).
3. Добавьте репозиторий в Cloud Source или подключите GitHub/Bitbucket.
4. В Cloud Build создайте триггер на ветку feature/ci-test.
5. Сделайте коммит и проверяйте логи сборки; исправьте ошибки.
6. Когда pipeline стабилен, добавьте проверки и деплой в staging.
7. Настройте production-триггер (можно по tag или merge в main).

Рольные чек-листы

Разработчик:

• Написать и закоммитить cloudbuild.yaml.
• Проверить, что сборка запускается локально в контейнере.

DevOps-инженер:

• Создать GCS-бакет для артефактов и настроить права.
• Настроить триггер и сервисный аккаунт с минимальными правами.

QA:

• Добавить тесты в pipeline и проверить их стабильность.
• Определить критерии приёмки перед деплоем в staging.

Критерии приёмки

• Сборка проходит без ошибок на триггере для target-ветки.
• Артефакты доступны в указанном хранилище и имеют ожидаемую структуру.
• Автоматизированные тесты выполняются и покрытие не падает ниже порога (определите порог в проекте).
• Деплой в staging выполняется автоматически после успешной сборки.

Мини‑глоссарий (1 строка на термин)

• build step — отдельный шаг в pipeline, выполняющий одну команду/образ.
• substitution — переменная, подставляемая в cloudbuild.yaml во время триггера.
• artifact — артефакт сборки: файл или папка, предназначенные для деплоя.
• logsBucket — GCS-бакет для хранения логов сборки.

Decision flowchart: куда деплоить?

flowchart TD
  A[Нужен ли контейнер?] -->|Да| B[GKE или Cloud Run]
  A -->|Нет| C[Cloud Functions или App Engine]
  B --> D{Требуется управление кластером}
  D -->|Да| E[GKE]
  D -->|Нет| F[Cloud Run]
  C --> G{Функция с коротким временем исполнения}
  G -->|Да| H[Cloud Functions]
  G -->|Нет| I[App Engine]

Контроль безопасности и права доступа

• Минимизируйте права сервисного аккаунта Cloud Build: выдавайте доступ только к тем ресурсам, которые нужны (GCS, GKE, Cloud Run и т.д.).
• Используйте Secret Manager для секретов и передавайте их через secrets/secretEnv.
• Логи и артефакты должны храниться в проекте с ограниченным доступом.

Принятые практики и чеклист перед релизом

• В cloudbuild.yaml: разбивайте долгие шаги на мелкие, чтобы легче было отлаживать.
• Автоматизируйте тесты уровня unit и интеграции в pipeline.
• Непродакшн сборки запускайте в изолированных средах.
• Документируйте substitutions и ожидаемые переменные для каждого триггера.

Резюме

Cloud Build — мощный инструмент для CI/CD в GCP. Правильная конфигурация cloudbuild.yaml и корректная настройка триггеров позволяют автоматизировать сборки, тесты и деплой в разные среды. Начните с простого pipeline, добавляйте шаги и проверки по мере взросления проекта, держите права сервисного аккаунта минимальными и храните секреты в Secret Manager.

Важное: перед внедрением в production прогоните несколько итераций в staging и заведите playbook на случай отката.