CI/CD пайплайны на Drone CI: автоматизация сборок и деплоя в Kubernetes

Сборки на Drone CI: что ломается при росте проектов

Пока проектов пять, сборочный контур держится на одном человеке: он помнит порядок шагов, знает, какие секреты подставить, и правит конфигурацию руками. На тридцати проектах и двух десятках инженеров тот же контур начинает тормозить не из-за кода, а из-за организации работ.

Первым проступает узкое место сборки: общий пул исполнителей делится между всеми ветками, и очередь сборочных задач растёт быстрее, чем команда. Сборка приложения, которая вчера занимала минуты, ждёт освобождения исполнителя, а разработчик вместо работы смотрит на статус.

Второй источник сбоев — расхождение окружений и скрытые зависимости. Библиотеки, закешированные артефакты и переменные, которые кто-то задал в интерфейсе и не перенёс в конфигурацию: локально всё зелёное, на чистом исполнителе — падение. Такие зависимости не видны в репозитории, пока не сменится окружение или не отзовут доступ к чужому аккаунту.

Наконец, ручной деплой: выкладка держится на человеке, который «умеет правильно», и в отпуске он превращается в единую точку отказа. Drone CI убирает эту зависимость — сборочный контур описывается как код: шаги, окружения, правила выкладки и допуски живут в репозитории рядом с приложением. Разбираем, как это закрывается.

Автоматизация сборок и деплоя: измеримый эффект

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

Доля параллельных шагов — второй измеримый параметр. Линтеры, модульные и интеграционные тесты, проверки образа идут независимыми ветвями, и критический путь сокращается до самой долгой из них: суммарное машинное время даже растёт, а календарное падает.

Частота релизов поднимается как следствие. Когда выкладка одной кнопкой и откат — тоже одна операция, команда выпускает мелкими порциями по нескольку раз в день вместо одного рискованного релиза в неделю. Мелкая порция быстрее проверяется и дешевле откатывается, аварий становится меньше просто потому, что релиз перестаёт быть событием.

Отдельно про устранённый класс отказов. Уходят расхождения окружений и ручные правки на серверах: Drone CI прогоняет один и тот же набор шагов для тестовой и рабочей среды, а состояние кластера описано декларативно. Класс «на тесте работало, на проде нет» закрывается на этапе сборки, а не на разборе после сбоя, и время восстановления измеряется минутами — откат это повторный запуск зафиксированной версии, а не ручная археология.

Режимы запуска сборок: облако, свои агенты, гибрид

Режим запуска определяет, где физически исполняются шаги сборки, к каким сетям и секретам имеет доступ задача и кто отвечает за узел. В Drone CI каждое задание идёт в отдельном контейнере, поэтому изоляция сборок обеспечивается на уровне шага — но сам агент, который эти контейнеры поднимает, выбирает команда.

Вопросов при выборе обычно два: нужен ли доступ к приватным ресурсам — внутреннему реестру образов, хранилищу секретов, сервисам в закрытом контуре — и насколько строго требуется развести задачи разных команд.

Гибрид на практике берут чаще всего: рядовые сборки не занимают внутренние узлы, а релиз и работа с секретами остаются в контролируемом контуре. Условие одно — одинаковые образы, версии плагинов и правила кэша в обоих пулах, иначе результат перестаёт воспроизводиться. Режим задаётся в конфигурации агента, поэтому сменить схему можно без переписывания сборочных файлов.

Внедрение Drone CI: этапы инженерной работы

Переключение идёт без остановки релизов: пока новый контур проверяется, старый продолжает собирать ветки. Ниже — последовательность этапов, которую проходим при внедрении Drone CI в Kubernetes.

1. Аудит сборочных процессов. Смотрим, что до сих пор собирается вручную, на каких шагах сборки падают чаще всего, сколько занимает путь от коммита до окружения и где разбросаны ключи доступа. На выходе — карта текущего состояния и список сборок, которые переводим первыми.

2. Схема контура. Определяем, где размещаются сервер управления и агенты, как они получают доступ к кластеру, какие ветки соответствуют каким окружениям и кто видит секреты. Схему фиксируем до настройки — она задаёт все остальные решения.

3. Настройка агентов и политик. Разводим агенты по типам задач, включаем кэш слоёв сборки и лимиты по ресурсам, прописываем правила запуска: что собирается на каждый коммит, что — на тег, что ждёт ручного подтверждения перед боевым контуром.

4. Перенос сборок. Репозитории переводим постепенно, по одному сервису, с параллельной работой старого контура. Команда видит результат на первой же сборке, а не после полного переключения.

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

6. Передача документации. Отдаём схему контура, конфигурации агентов, политики запуска и инструкции для дежурных: как разобрать упавшую сборку, как перезапустить шаг, как выдать доступ новому инженеру.

Что остаётся у вас: конфигурации, схемы, регламенты

Мы не оставляем заказчика с работающим, но непонятным конвейером: конвейер на Drone CI целиком описывается как код в вашем репозитории, рядом лежат схемы и документация. Инженер вашей команды сможет изменить шаг сборки, добавить окружение или откатить релиз, не обращаясь к нам.

• Конфигурации сборки — описания шагов и условий запуска: по тегу, по ветке, вручную. С комментариями, почему порядок именно такой и где точка отката.
• Политики доступа — кто запускает сборки, кто меняет конфигурацию и кто деплоит в продуктив; роли разработчика и дежурного разведены.
• Схемы инфраструктуры — контур целиком: репозиторий, сборочные агенты, реестр образов, кластер и окружения, места хранения секретов.
• Регламент восстановления — порядок действий при падении агента, потере доступа к реестру или неудачном релизе, с временем на каждый шаг.
• Инструкции для команды — как повторить сборку локально, добавить новый сервис в конвейер, что делать с упавшей сборкой ночью.
• Карта секретов и переменных — где лежит значение, кто владелец, как и когда ротировать, чтобы не искать это в момент сбоя.
• Чек-лист приёмки — проверки, по которым вы сами убеждаетесь, что сборка и откат работают уже без нас.

Кейс: сократили сборку и убрали ручные выкладки

К нам пришёл контур продукта: несколько сервисов, общий сборочный сервер и регламент выкладки в вики. Релиз запускался вручную с локальной машины дежурного, поэтому сборка и выкатка растягивались больше чем на час, а результат зависел от того, у кого из команды «работает».

Контур до изменений

Медианная сборка занимала около 38 минут: шаги шли последовательно и каждый раз заново тянули зависимости. Автоматических выкладок было меньше пятой части, остальное — руками, с ручным же откатом. Неудачный релиз означал ночное дежурство: возврат предыдущей версии занимал часы, потому что никто точно не помнил, какие шаги при выкладке были пропущены.

Что изменили и что получили

Сборку и выкладку перевели в Drone CI: конвейер описывается декларативно и лежит рядом с кодом. Добавили кеш зависимостей между запусками, распараллелили независимые шаги, образы стали неизменяемыми и попадают в реестр под конкретный коммит. Перевод между окружениями идёт тем же конвейером, выкладка стартует по тегу, а не по кнопке.

Медианная сборка сократилась с 38 до 9 минут, доля автоматических выкладок выросла до 95%. Откат — это повторный запуск предыдущего успешного конвейера: пара минут вместо часов. Если падает проверка тестов или проверка готовности подов после развёртывания, выкладка не доходит до продакшена и окружение остаётся на прежней версии — класс отказов «разъехались конфигурации между средами» ушёл совсем.

Технические сомнения: секреты, кэш, свои агенты

Перед стартом обычно всплывает один и тот же набор прикладных вопросов: где лежат секреты, не ломает ли кэш воспроизводимость, нужны ли собственные агенты и что делать с уже работающим конвейером. Ниже — короткие ответы о том, как мы решаем это в проектах на Drone CI.

Кэш ускоряет сборку — не ломает ли он воспроизводимость?

Кэш ключуется по слепку файла зависимостей и целевой ветке: поменялся манифест — кэш пересобирается с нуля. Кэшируем только сторонние зависимости и не кэшируем результаты своей сборки, иначе в артефакт может утечь устаревший код. Для релизных сборок кэш отключается принудительно: дольше, зато результат проверяемо повторяем на той же ревизии.

Нужны ли свои агенты или хватит облачных?

Облачных агентов хватает для типовых задач: сборка, тесты, публикация образов. Свои нужны, когда шагу требуется доступ во внутреннюю сеть, специфичное окружение или когда объём зависимостей делает выгоднее держать кэш рядом с кодом. Начинаем с одного-двух агентов и добавляем по мере роста параллельных задач.

Уже работает другой контур — переносить всё сразу?

Нет. Работающий контур не выключаем: переносим по одному репозиторию, оба существуют параллельно, результаты сборок сравниваются на одних и тех же изменениях кода. Откат — вернуть триггер на прежнюю систему, история и артефакты остаются на месте. Так переход не блокирует релизы.

Обсудим задачу: что прислать для быстрой оценки

Чтобы оценка была предметной, а не «на глаз», нам достаточно короткого набора входных данных. Смотрим на текущий конвейер сборки и доставки, окружения и то, как сегодня выкатываются изменения, — из этого складывается состав работ, этапы и сроки.

Что прислать:

• Ссылки на репозитории и права на чтение настроек конвейера — увидим, как организованы сборка, тесты и публикация образов.
• Конфигурации сборки и развёртывания: файлы сборки образов, манифесты Kubernetes, схемы окружений и переменных.
• Описание окружений — сколько кластеров, какие среды (разработка, предпродакшн, продакшн), кто и как получает доступ.
• Схему работы с секретами и реестром образов: где хранятся ключи, как выдаются права, есть ли разделение по средам.
• Текущий ручной процесс релиза: сколько времени занимают сборка, проверки и выкатка, на каком шаге чаще всего ломается.
• Требования безопасности: проверки уязвимостей, подпись образов, разграничение прав, журналирование действий.
• Ожидаемый режим релизов: частота выкаток, окна обновлений, требования к откату и допустимому простою.

Отдельно нужен инженер, который проведёт по инфраструктуре и ответит на вопросы по ходу разбора — это экономит недели переписки. По этим данным мы вернёмся с оценкой задачи и планом внедрения: перевод сборок и выкатки на Drone CI в Kubernetes, разбитый на этапы, с ответственными и сроками по каждому.

Чем свои агенты сборки отличаются от управляемых?

Управляемые агенты — чужая инфраструктура: вы получаете образ, который вам выдали, и очередь, которой не управляете. Свои агенты — узлы под вашим контролем, где образ, доступы и политику утилизации задаёте вы. Разница проявляется не в удобстве, а в том, что именно вы можете починить, когда сборка встала, и кто отвечает за простой.

Изоляция определяет, что переживает одну сборку. Одноразовый агент в отдельном пространстве имён уносит с собой всё: кэш пакетов, временные файлы, промежуточные слои образа — следующая задача стартует с чистого состояния, и подменить результат чужой сборкой невозможно. Переиспользуемый пул быстрее за счёт прогретого кэша, но требует дисциплины: очистка томов и рабочих каталогов становится вашей задачей.

Контроль над окружением решает, дотянется ли сборка до внутренних сервисов. На управляемых агентах приватный реестр и база доступны только через публичный вход, а секреты живут в чужом хранилище. Свои узлы в кластере видят внутренние адреса напрямую, ключи лежат в вашем хранилище, версия системных библиотек фиксируется вашим образом, а не чужой политикой обновления.

Обратная сторона — нагрузка на команду. Свой контур требует обновлений рантайма, ротации ключей, масштабирования под пиковые часы и уборки диска после падений; управляемый снимает это, но забирает гибкость. Цена поддержания измеряется часами инженеров, а не числом узлов. На практике в Drone CI держат гибрид: управляемые агенты — для проверок и сборки, собственные — для выката и задач с доступом к внутренней сети.