CI/CD с Cloud Build на GCP

TL;DR

Cloud Build — это сервис GCP для автоматизации CI/CD: он получает код из репозитория, выполняет шаги сборки и тестирования, и отправляет артефакты в App Engine, GKE, Cloud Run, Cloud Functions или в Cloud Storage. В статье показано, как написать простой cloudbuild.yaml, настроить триггер в Cloud Build и лучшие практики, чек-листы и варианты отладки.

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

• Writing a Build Configuration

• Setting Up Cloud Source & Cloud Build

Что делает Cloud Build

Continuous Integration/Continuous Delivery (CI/CD) — это автоматизация обновлений приложения: от изменений в системе контроля версий до автоматических сборок и развёртываний на серверах. Cloud Build — это сервис Google Cloud Platform, который принимает исходники, выполняет набор шагов (steps) и производит артефакты или запускает деплой.

Важно: Cloud Build не навязывает способ сборки — вы описываете шаги в 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
    ...
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)
  _MY_VAR: "value"
tags: [string, string, ...]
secrets: object(Secret)
images: # список образов, которые надо запушить
  - "gcr.io/my-project/my-image:tag"
artifacts: object(Artifacts)

Ниже — минимальный пример для NPM-приложения, который устанавливает зависимости, запускает тесты, собирает артефакты и загружает их в bucket:

steps:
  # Install dependencies
  - name: node:18
    entrypoint: npm
    args: ["install"]

  # Run tests
  - name: node:18
    entrypoint: npm
    args: ["test"]

  # Run custom build
  - name: node:18
    entrypoint: npm
    args: ["run", "build"]

artifacts:
  objects:
    location: "gs://mybucket/"
    paths: ["build/**"]

Пояснения:

• steps — последовательность контейнеров (образов), которые выполняются в указанном порядке. Каждый шаг изолирован и может запускать произвольные команды.
• images — список Docker-образов, которые нужно построить и загрузить (если применимо).
• artifacts.objects.location — место, куда положить итоговые файлы (Cloud Storage).
• substitutions — позволяет задать переменные, которые подставляются в конфигурации.

Совет: используйте конкретные теги образов (например node:18) для воспроизводимости.

Примеры вариантов развёртывания

Cloud Build может отдавать артефакты в разные целевые сервисы:

• App Engine — для классических приложений.
• Cloud Run — для контейнерных сервисов.
• GKE — для Kubernetes-кластеров (через kubectl / gcloud).
• Cloud Functions — для функций с триггерами.
• Cloud Storage — для статических сайтов или артефактов.

Выбор зависит от архитектуры приложения: статичный сайт → Cloud Storage; микросервис в контейнере → Cloud Run или GKE.

Настройка Cloud Source и триггеров Cloud Build

Cloud Build получает исходники из Cloud Source (встроенный Git) или из внешних провайдеров (GitHub, Bitbucket). Процесс типичен:

1. Создайте репозиторий в Cloud Source или подключите внешний аккаунт (GitHub/Bitbucket).

2. Перейдите в Cloud Build → Set Up Build Trigger.

3. Задайте имя триггера, источник и условия срабатывания (ветка, теги, pull request, регулярное выражение).

4. Укажите путь к cloudbuild.yaml (если он в нестандартном месте) и определите substitutions для переиспользуемых значений.

5. Создайте триггер. После этого вы сможете запускать его вручную из дашборда для тестирования.

После настройки триггер будет автоматически запускаться при каждом push в указанную ветку или при pull request в зависимости от настроек.

Мини-методология для разработки CI/CD с Cloud Build

1. Определите артефакты и целевые среды (staging, production).
2. Напишите минимальный cloudbuild.yaml, который собирает и сохраняет артефакты.
3. Настройте триггер на ветку разработчиков (например, develop) и отдельный триггер для production (main) с дополнительными проверками.
4. Добавьте шаги тестирования: unit → integration → e2e по мере зрелости.
5. Протестируйте локально (docker, локальные образы) и в тестовом проекте GCP.
6. Добавьте мониторинг и уведомления (Cloud Logging, Cloud Monitoring).

Чек-листы по ролям

Рекомендации, кто за что отвечает при настройке CI/CD:

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

  • Написать cloudbuild.yaml с шагами сборки и тестов.
  • Обеспечить стабильные версии зависимостей.
  • Добавить unit-тесты и предусмотреть тестовые данные.

• DevOps/Инженер по платформе:

  • Настроить репозиторий и триггеры Cloud Build.
  • Создать service account с минимальными правами.
  • Настроить разрешения на bucket/кластеры для деплоя.

• QA:

  • Определить набор интеграционных и e2e тестов.
  • Проверять артефакты на staging перед релизом.

Безопасность и секреты

• Храните секреты в Secret Manager и пробрасывайте их в build через secretEnv.
• Не храните чувствительные данные в репозитории или в substitutions.
• Ограничьте права service account: принцип наименьших привилегий.

Важно: автоматический деплой в production должен проходить дополнительные проверки и требовать одобрения (manual approval) если это возможно.

Когда это ломается — типовые проблемы и отладка

• Ошибка в cloudbuild.yaml: проверьте синтаксис YAML и корректность путей.
• Неверный образ/тег: указывайте стабильные теги контейнеров, проверьте доступ к registry.
• Отсутствие прав на bucket/кластер: проверьте IAM роли у service account.
• Тесты падают: запускайте локально те же команды, которые в steps.
• Медленная сборка: используйте кэширование зависимостей, кэширование docker layers, или более быстрые machineType.

Полезный приём: воспроизводите шаг локально, запуская тот же образ контейнера (docker run –rm -it node:18 /bin/bash) и выполняя команды из steps.

Контроль качества: метрики и зрелость процесса

Maturity levels (упрощённо):

• 0 — нет автоматизации: ручные сборки и деплой.
• 1 — базовый CI: автоматические сборки и unit-тесты.
• 2 — CI + автоматические деплои в staging, интеграционные тесты.
• 3 — CI/CD с канареечным релизом, промышленные SLO/SLI и мониторинг.

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

• Сборка проходит на триггере в develop.
• Unit-тесты не падают, покрытие базовое.
• Артефакты доступны в целевом bucket/registry.
• Доступ к production требует контролируемого процесса ревью/approval.

Малые практические советы

• Используйте substitutions для раздельных конфигураций веток.
• Ограничьте время сборки (timeout) чтобы не тратить кредиты в случае зависших задач.
• Разделяйте шаги на короткие, атомарные контейнеры — легче отлаживать.
• Параллелите независимые шаги через waitFor если нужно.

Короткая галерея крайних случаев

• Когда не подходит Cloud Build: если вам нужен very low-level control над инфраструктурой сборки или вы обязаны использовать on-premise runners.
• Альтернатива: GitHub Actions, GitLab CI, Jenkins — если ваша организация уже привязана к этим инструментам.

1-строчный глоссарий

• CI/CD — автоматизация сборки, тестирования и развёртывания.
• Cloud Build — сервис GCP для выполнения шагов сборки.
• Cloud Source — Git-репозиторий в GCP.
• cloudbuild.yaml — конфигурация сборки.

Итог

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

Важно: проектируйте пайплайн под ваши требования по безопасности и доступности — автоматизация полезна, но должна быть контролируемой.