Налаштування масштабованого CI/CD на Buildkite з власними агентами

Налаштування масштабованого CI/CD пайплайну через Buildkite

Buildkite працює за моделлю, яку більшість CI-платформ так і не реалізували нормально: оркестрація в хмарі, виконання — на вашій інфраструктурі. Buildkite знає, який job запустити і в якому порядку. Але сам код не бачить — він іде тільки на ваш агент, який крутиться у вашій мережі, на вашому залізі або у вашому кластері.

Ми розгортаємо такі пайплайни під ключ з гарантією стабільності та продуктивності. Маємо 5+ років досвіду в DevOps і 50+ успішних впроваджень CI/CD на різних платформах. Зв'яжіться з нами для оцінки вашого проєкту.

Чому Buildkite — найкращий вибір для CI/CD з власними агентами?

Shared runners від GitHub або GitLab — зручний старт. Але як тільки збірки починають займати 15–20 хвилин, а в черзі висить по 10 джобів, стає очевидно: на чужих машинах зі спільним CPU та пам'яттю масштабуватися нікуди. Buildkite вирішує це радикально — агенти ваші, отже, хочете 50 паралельних збірок — піднімайте 50 агентів. Хочете ARM для мобільних збірок і x86 для бекенду — розмічайте агенти тегами і пускайте потрібні джоби на потрібне залізо через agents: { queue: "arm64" }.

Другий кейс — приватні залежності та registry. Коли збірка звертається до внутрішнього npm-registry, приватного Docker Hub або PyPI mirror у VPN, shared runners просто не мають доступу. Агент Buildkite всередині мережі вирішує це без VPN-тунелів та білих списків IP. Економія витрат на інфраструктуру становить 30–50% порівняно з платними CI-рішеннями за рахунок використання власних агентів.

Порівняння: shared runners проти агентів Buildkite

Як влаштований пайплайн у Buildkite?

Конфігурація пайплайну — YAML-файл .buildkite/pipeline.yml у репозиторії. Базова структура виглядає просто, але платформа підтримує динамічні пайплайни: один крок запускає скрипт, який генерує YAML для наступних кроків і завантажує його через buildkite-agent pipeline upload. Це дозволяє будувати матричні збірки, де список компонентів для збірки визначається на льоту за зміненими файлами, а не захардкожений.

---
# .buildkite/pipeline.yml
steps:
  - label: ":docker: Build"
    command: "scripts/build.sh"
    agents:
      queue: "docker-builders"
    plugins:
      - docker#v5.10.0:
          image: "node:20-alpine"
          volumes:
            - "/tmp/cache:/root/.npm"
  - wait
  - label: ":test_tube: Test"
    command: "scripts/test.sh"
    parallelism: 4
    agents:
      queue: "test-runners"
  - block: ":rocket: Deploy to Production"
    branches: "main"
  - label: "Deploy"
    command: "scripts/deploy.sh"
    branches: "main"
    agents:
      queue: "deploy-production"

parallelism: 4 — Buildkite автоматично розіб'є тестову джобу на 4 паралельних шарди. Кожен шард отримує змінні BUILDKITE_PARALLEL_JOB і BUILDKITE_PARALLEL_JOB_COUNT, за якими тестовий скрипт розуміє, яку частину тестів запускати. Jest, RSpec, pytest — всі підтримують такий поділ.

Плагіни — окрема екосистема. docker, ecr, kubernetes, cache, artifacts — кожен плагін обгортає типову логіку в перевикористовувану конфігурацію. Не потрібно писати bash-скрипт для пуша в ECR — підключаєш плагін ecr#v2.7.0 і вказуєш параметри.

Як розгорнути агентів Buildkite?

Buildkite агент — Go-бінарник, який встановлюється за хвилину. Для продакшен-сетапу рекомендую запуск через systemd на виділених VM або через DaemonSet у Kubernetes.

У Kubernetes варіант через Buildkite Agent Stack for Kubernetes (офіційний оператор) дозволяє запускати кожну джобу в окремому pod. Агент не тримає стан між джобами, ізоляція повна. buildkite-agent-stack-k8s розгортається через Helm:

helm repo add buildkite https://buildkite.github.io/helm-charts
helm install buildkite-agent buildkite/agent \
  --set agentToken="$BUILDKITE_AGENT_TOKEN" \
  --set config.tags="queue=k8s-builders,arch=amd64"

Для кешування залежностей між джобами — окремий PVC або S3 bucket, що монтується через плагін cache. На відміну від GitHub Actions, де кеш зберігається на серверах GitHub з обмеженим TTL, тут кеш живе рівно стільки, скільки потрібно.

Що входить в роботу

• Аудит поточних пайплайнів та інфраструктури
• Розгортання агентів (VM або K8s)
• Налаштування пайплайнів, кешування, артефактів
• Паралелізація тестів з шардуванням
• Інтеграція з Slack, GitHub, PagerDuty
• Документація з експлуатації та runbook
• Підтримка протягом місяця після запуску

Етапи роботи

1. Аудит поточних пайплайнів — що зараз є, де вузькі місця за часом, які джоби потребують доступу до внутрішніх ресурсів.
2. Вибір інфраструктури для агентів — VM vs Kubernetes, on-premise vs cloud, вимоги до ізоляції.
3. Розгортання агентів — встановлення, systemd/DaemonSet, налаштування тегів черг.
4. Перенесення пайплайнів — переклад .gitlab-ci.yml або GitHub Actions workflows у .buildkite/pipeline.yml.
5. Налаштування кешу та артефактів — S3/GCS bucket для cache plugin, retention policy.
6. Паралелізація тестів — налаштування шардингу, інтеграція з Test Analytics для аналізу повільних тестів.
7. Нотифікації та інтеграції — Slack, PagerDuty, GitHub commit statuses.

Орієнтири за термінами

Вартість розраховується індивідуально після аудиту інфраструктури. Замовте консультацію для оцінки вашого проєкту.

Buildkite дає повний контроль над CI/CD-інфраструктурою без компромісів у швидкості та безпеці. Власні агенти вирішують проблеми масштабування, доступу до приватних ресурсів та кешування, які не осилюють хмарні аналоги. А динамічні пайплайни та плагіни прискорюють розробку та підтримку.

Зв'яжіться з нами — отримайте попередній план міграції.