Модуль 2.11: Cloud Build та CI/CD

Складність: [MEDIUM] | Час на виконання: 2 год | Передумови: Модуль 2.6 (Artifact Registry), Модуль 2.7 (Cloud Run)

Чому цей модуль важливий

У вересні 2022 року процес деплою в одному швидкозростаючому стартапі виглядав так: старший інженер заходив по SSH на сервер, робив git pull, збирав Docker-образ вручну і перезапускав контейнер. Поки в команді було 3 людини, це працювало. Коли стало 15 — це перетворилося на катастрофу. Одного разу “деплой-інженер” випадково залишив прапорець дебагу, і всі паролі користувачів почали писатися відкритим текстом у логи. Помилку помітили лише через три дні.

CI/CD (Continuous Integration / Continuous Deployment) — це не розкіш, а фундамент надійної розробки. Це механізм, який робить доставку коду автоматичною, перевіреною та безпечною. Cloud Build — це безсерверна платформа Google, яка збирає, тестує та деплоїть ваш код, не вимагаючи від вас управління жодним сервером.

У цьому модулі ви навчитеся писати конфігурації cloudbuild.yaml, налаштовувати автоматичні запуски (triggers) з GitHub та будувати конвеєри, які самі деплоять код у Cloud Run після успішних тестів.

Архітектура Cloud Build

Кожен запуск Cloud Build відбувається в новому, ефемерному середовищі. Ваш конвеєр складається з кроків (steps). Кожен крок — це окремий Docker-контейнер, який виконує одну задачу (напр. “зібрати код” або “запустити тести”). Всі кроки мають доступ до спільної папки /workspace.

Основні поняття:

Build: Один запуск вашого конвеєра.
Step: Окрема дія всередині білда.
Builder: Docker-образ, який надає інструменти для кроку (напр. gcr.io/cloud-builders/docker).
Trigger: Автоматика, що запускає білд (наприклад, при кожному git push у гілку main).

cloudbuild.yaml: Серце конвеєра

Ось приклад простого конвеєра для Cloud Run:

steps:
  # 1. Збірка образу
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-t', 'us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/app:$SHORT_SHA', '.']

  # 2. Пуш у реєстр
  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', 'us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/app:$SHORT_SHA']

  # 3. Деплой у Cloud Run
  - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
    entrypoint: gcloud
    args:
      - 'run'
      - 'deploy'
      - 'my-app'
      - '--image=us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/app:$SHORT_SHA'
      - '--region=us-central1'

Тригери: Автоматизація з GitHub/GitLab

Ви можете підключити ваш репозиторій до Cloud Build.

Push triggers: Кожен коміт автоматично запускає білд.
PR triggers: Запускає тільки тести, щоб перевірити код перед злиттям у main.
Tag triggers: Запускає деплой у продакшн тільки коли ви створюєте тег версії (напр. v1.2.0).

Безпека в конвеєрі

Cloud Build працює від імені сервісного акаунта. За замовчуванням у нього мало прав. Порада: Завжди створюйте власний SA для білдів і надавайте йому тільки ті права, які йому потрібні (напр. run.admin та artifactregistry.writer). Ніколи не зберігайте паролі в cloudbuild.yaml — підключайте їх із Secret Manager.

Типові помилки

Помилка	Чому це стається	Як виправити
Послідовні кроки для всього	Це дефолтна поведінка	Використовуйте `waitFor`, щоб запускати незалежні кроки (напр. лінтинг та білд) паралельно
Жорстке прописання ID проєкту	Заважає перевикористанню	Використовуйте вбудовану змінну `$PROJECT_ID`
Відсутність тестів у CI	”Ми тестуємо локально”	Конвеєр — це єдине джерело істини. Якщо тести не пройшли в CI, деплой має зупинитися
Низький таймаут для важких білдів	Дефолт — 10 хвилин	Встановіть `timeout: 1200s` (20 хв) для великих проєктів

Тест

1. Що таке /workspace в Cloud Build?

Це спільна папка, яка автоматично монтується в кожен контейнер-крок під час одного білда. Це дозволяє одному кроку створити файл (напр. бінарник), а наступному — використати його.

2. Чи можна використовувати будь-який Docker-образ як крок у Cloud Build?

Так. Ви не обмежені образами від Google. Ви можете вказати будь-який образ із Docker Hub або Artifact Registry як name для вашого кроку.

Практична вправа: Мій перший конвеєр

Створіть репозиторій на GitHub із простим Python-додатком та Dockerfile.
Напишіть cloudbuild.yaml, який збирає образ і пушить його в Artifact Registry.
Налаштуйте Trigger у консолі Cloud Build, підключивши ваш GitHub.
Зробіть push у GitHub і спостерігайте за білдом у консолі GCP.

Наступний модуль

Переходьте до Модуля 2.12: Архітектурні патерни GCP — ви дізнаєтеся про Landing Zones, Identity-Aware Proxy та отримаєте огляд Anthos та GKE для масштабування ваших контейнерів.