Настройка масштабируемого 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-инфраструктурой без компромиссов в скорости и безопасности. Собственные агенты решают проблемы масштабирования, доступа к приватным ресурсам и кэширования, которые не осиливают облачные аналоги. А динамические пайплайны и плагины ускоряют разработку и поддержку.

Свяжитесь с нами — получите предварительный план миграции.