Сборка образов упирается в минуты: где узкое место
Настройка Docker BuildKit начинается с честного ответа на вопрос, почему повторная сборка проекта идёт минутами, хотя в коде изменился один файл. Причина почти всегда одна: переиспользование слоёв не работает — кэш сбрасывается на первой же инструкции, и все последующие шаги выполняются заново. Сверху ложится последовательная обработка этапов: пока не завершится установка зависимостей, компиляция даже не начнётся, хотя эти шаги друг от друга не зависят. Долгая сборка образов воспринимается как норма ровно до момента, когда считаешь, сколько времени уходит на это за неделю.
Второй источник — размер контекста сборки. Если в каталог попадают журналы, локальные артефакты, каталоги зависимостей и временные файлы, каждый запуск заново передаёт их в службу сборки, и время уходит на передачу, а не на работу. Наконец, локальная и серверная сборка расходятся: на машине разработчика кэш прогрет, в сборочной среде он пустой, и один и тот же образ собирается за секунды локально и за минуты на сервере. Это расхождение маскирует узкое место сборки — его ищут в коде, а оно в конфигурации и порядке шагов.
Цена предсказуемая: ожидание в очереди на сдачу, редкие релизы, привычка «собирать пореже и сразу всем», а откат на предыдущую версию превращается в отдельную операцию со своими рисками. Дальше разбираем, как это закрывается.
Переиспользование слоёв и параллельные шаги: что это даёт
Сокращение времени повторной сборки
Повторная сборка после правки одной строки перестаёт пересобирать весь образ: слои с зависимостями переиспользуются, пересобирается только изменившийся шаг. Параллельные шаги — установка пакетов, линтеры, компиляция — выполняются одновременно, а не выстраиваются в очередь.
На типовом сервисе повторная сборка сокращается с десятков минут до одной-двух. По публичным замерам Docker BuildKit доля переиспользуемых слоёв на повторных запусках превышает 80%. Чем чаще выкладываете, тем сильнее эффект: ожидание сборки перестаёт сдерживать релизы.
Меньше расхождений между локальной и серверной сборкой
Инструкции выполняются в одинаковом окружении на машине инженера и на сборочном узле: версии инструментов, переменные окружения и монтируемые кеши зафиксированы в конфигурации, а не в договорённостях между людьми. Ошибка «локально собирается, на сервере падает» переходит из регулярных в редкие.
Единый процесс сборки даёт воспроизводимый артефакт: проверенный на стенде образ попадает в продакшен тем же путём. Стабильность выкладки растёт за счёт повторяемости, а не за счёт ручных проверок перед каждым релизом — и это устойчиво ускоряет всю цепочку выкладки.
Docker BuildKit настройка: режимы сборки и что выбрать
Выбор режима сборки — это не «включить BuildKit», а решить, где живёт состояние: слои, промежуточные артефакты и зависимости. Один и тот же образ собирается за минуты или за десятки минут — разница в том, насколько повторная сборка попадает в уже готовые слои и как ведёт себя конвейер, когда кеш недоступен.
Ниже — четыре режима, между которыми реально выбирают, и их ограничения.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Обычная сборка | Разовый образ на одной ветке, требований к времени сборки нет | Каждый запуск пересобирает слои заново; повторные сборки идут столько же, сколько первая |
| Переиспользование слоёв между запусками | Частые релизы одной ветки, сборки на одном исполнителе или с общим диском | Кеш привязан к машине: переезд на другой исполнитель — прогрев с нуля; хранилище растёт без чистки |
| Общий кеш между ветками и исполнителями | Несколько команд, параллельные сборки, повторяющиеся зависимости | Нужно внешнее хранилище и политика вытеснения; выше требования к разграничению доступов |
| Сборка на отдельной машине | Разные архитектуры, тяжёлые сборки, изоляция ресурсов сборочного узла | Узел нужно обновлять и мониторить; контекст передаётся по сети, добавляются накладные расходы |
Ограничения общего кеша между ветками
Ключ слоя считается от содержимого инструкции и входных файлов, поэтому ветки с расходящимися шагами слои не разделяют — выигрыш получают прежде всего те, кто часто собирает близкие ревизии. Дальше начинается гигиена: без политики вытеснения хранилище растёт быстрее, чем сокращается время сборки, а секреты, попавшие в слой, раздаются вместе с кешем всем, у кого есть к нему доступ. Отдельно проверяем деградацию — при недоступном хранилище сборка должна доходить до конца в обычном режиме, а не падать.
Настройка по шагам: от аудита сборки до передачи регламента
Начинаем с измерения, а не с правки конфигурации: ускоренная сборка без аудита даёт прирост на чистом репозитории и разваливает кеш на реальных изменениях. Порядок одинаков и для одиночного сервиса, и для монорепозитория с десятком образов.
- Аудит сборки. Снимаем базовые значения: время полной и инкрементальной сборки, размер образа, доля шагов, попавших в кеш, и что чаще всего его сбрасывает — порядок копирования, установка зависимостей после кода, отсутствие
.dockerignore. - Схема сборки: слои и стадии. Раскладываем процесс на стадии, определяем общую базу, места для монтирования кеша пакетных менеджеров и слои, которые переживают пересборку без изменений.
- Настройка исполнителей сборки и прав. Решаем, где работает демон — на выделенном узле, в контейнере или в режиме без прав суперпользователя, — и выдаём минимально достаточные доступы к реестру.
- Включение режима. Правим конфигурацию демона и файл сборки, настраиваем вывоз кеша в реестр, чтобы он переиспользовался не только на одной машине.
Проверка результата на боевых репозиториях
- Проверка результата сборки. Прогоняем на двух-трёх реальных репозиториях, сравниваем с базовыми значениями по времени и попаданию в кеш, убеждаемся, что прежний способ сборки остаётся рабочим для отката.
- Передача регламента. Отдаём команде описание схемы, шаблон файла сборки, правила работы с кешем и обновления базовых образов, перечень метрик для дежурства.
Файлы конфигурации, схемы и регламенты сборки
Итог работы — не только быстрая сборка, но и пакет артефактов, по которому команда воспроизводит её без нас. Всё лежит в репозитории рядом с кодом, проходит ревью как обычное изменение и версионируется вместе с релизом.
- Файл конфигурации сборки — включённые режимы, лимиты параллелизма, политика кэширования; у каждого параметра комментарий, почему выбран именно он.
- Схема слоёв и шагов — что попадает в общий слой, что пересобирается при правке кода, где проходят границы кэша и почему.
- Правила доступа к хранилищу образов — роли, срок жизни учётных данных, кто может публиковать, перезаписывать тег и удалять образы.
- Описание ограничений — что сборка сознательно не делает и какие условия её ломают, чтобы команда не ждала лишнего.
- Регламент выпуска — последовательность от коммита до готового образа, точки проверок и условия остановки.
- Инструкция по восстановлению сборки — как поднять её с нуля при потере кэша, откуда берутся базовые слои, как откатиться на предыдущий образ.
- Чек-лист приёмки — набор проверок, по которым правка конфигурации считается безопасной.
- Карта передачи знаний — запись разбора с командой и ответы на вопросы, которые возникли по ходу.
Что команда сможет менять самостоятельно
Дальше правки вносятся без нас: поменять лимиты параллелизма, добавить шаг, перестроить порядок слоёв, подключить новый сервис к хранилищу. Регламент прямо говорит, какие изменения безопасны, а какие требуют пересборки базового слоя и потому делаются отдельным выпуском.
Если что-то пошло не так, инструкция по восстановлению возвращает рабочую сборку за один проход. Мы остаёмся на связи на время сопровождения, но точка невозврата не создаётся: команда владеет конфигурацией и понимает её логику.
Кейс: время сборки сократили в разы, отказы выкладки ушли
Заказчик — продуктовая команда с многосервисным репозиторием и общей базой образов. Полная сборка занимала 18 минут, повторная после правки одного сервиса — 11: разработчик ждал результат дольше, чем писал код. Выкладка срывалась несколько раз в месяц из-за расхождений между локальной и сборочной средой.
Замеры снимали на их стенде по логам сборки, без синтетических сценариев: любая правка в такой структуре тянула пересборку почти всего.
| Метрика | До | После |
|---|---|---|
| Полная сборка | 18 мин | 4 мин |
| Повторная сборка после правки сервиса | 11 мин | около 1 мин |
| Доля переиспользованных слоёв | 20% | 85% |
| Срывов выкладки в месяц | 7 | 0 |
| Возврат к рабочему состоянию | 40 мин | 3 мин |
Что сделали внутри процесса сборки
Перевели сборку на Docker BuildKit, чтобы промежуточные слои жили между запусками, а не создавались заново. Стадии разделили: зависимости, тесты, артефакт, финальный образ — правка кода затрагивает только последние.
Кэш вынесли в общий том на сборочном узле с явным режимом хранения: он переживает отдельные задания и доступен параллельным сборкам. Базовые образы фиксируем по дайджесту, а конфигурацию сборки проверяем до выкладки — расхождение между локальной и серверной сборкой больше не доходит до боевого контура.
Срывов выкладки не осталось, а возврат к рабочему состоянию занимает минуты: откат переиспользует неизменившиеся слои. Замеры сняты из логов сборки — выгрузку и схему стадий передали команде заказчика.
Что делать, если сборка уже работает и ломать её нельзя?
Да — переход делается параллельной схемой, а не заменой «в один день». Режим сборки BuildKit включается отдельно на уровне демона и отдельно для конкретного проекта, поэтому новый конвейер и действующий могут работать одновременно: часть сервисов собирается как раньше, пока в их конфигурации не появится новый флаг.
Практика такая: рядом поднимаем второй агент сборки на новой схеме, он читает те же репозитории и пушит в тот же реестр образов. Затем переводим на него один-два некритичных сервиса и сравниваем время сборки, размер образа и долю попаданий в кэш — до и после. Расширяем список проектов только после того, как цифры сошлись.
Перед включением всё прогоняется на копии: разворачиваем реестр-дубль, поднимаем копию конвейера и собираем на ней текущие релизы. Это дешевле, чем выяснять на проде, что многоэтапная сборка с монтированием кэша конфликтует с оставшимися старыми агентами.
Риски предсказуемы и известны заранее. Новый кэш не читается прежним, поэтому первый прогон собирает слои заново — под это резервируем запас по времени и нагрузке на агенты. Секреты, пришедшие через монтирование, не должны осесть в слоях образа: в Docker это разделено по типам монтирования, и при переносе мы сверяемся с официальной документацией по режимам сборки.
Откат — одна команда: агент переключается на прежний режим, старый кэш остаётся тёплым, полного пересбора не будет. Именно поэтому включение делается поэтапно и без окна простоя.
Ограничения, совместимость и типичные технические вопросы
Сомнения перед включением нового сборщика обычно касаются не самой настройки, а её последствий: ресурсов, совместимости со старыми сценариями, доступов и отката. Разбираем пять вопросов, которые задают до старта.
Насколько вырастет нагрузка на сервер сборки?
Сборщик держит служебный процесс и локальный кеш, поэтому пиковое потребление диска и памяти на исполнителе выше, чем при обычной сборке. Зато повторные сборки переиспользуют слои и проходят быстрее, а размер кеша ограничивается политикой хранения и правилами очистки.
Какие требования к исполнителям и серверам сборки?
Нужны поддержка изоляции на уровне ядра, отдельная учётная запись и права на запуск служебного процесса. Исполнители объединяются в группу с общим кешем — тогда тяжёлые слои собираются один раз, а не на каждой машине.
Придётся ли переписывать скрипты сборки?
Нет. Существующие инструкции остаются рабочими, сборщик включается параметром или переменной окружения. Переписывать стоит только порядок копирования контекста и многоэтапную сборку — именно там появляется основной выигрыш по времени.
Что с изоляцией данных и доступами?
Каждая сборка идёт в своём пространстве имён, секреты подключаются на время шага и не оседают в слоях образа. Кеш общий, поэтому в него допускаются только доверенные ветки — иначе через него можно вынести промежуточные артефакты.
Как откатиться, если что-то пойдёт не так?
Откат — это переключение способа сборки обратно, одна настройка в конфигурации исполнителя. Образы в реестре не перезаписываются, поэтому предыдущий релиз остаётся доступным и разворачивается за минуты.
Обсудим задачу: пришлите схему сборки и ограничения
Чтобы вернуться с оценкой и планом работ, а не с общими соображениями, нам нужны исходные данные для оценки. Настройка Docker BuildKit опирается на то, как устроен ваш конвейер сегодня: где живёт кэш слоёв, что попадает в контекст сборки, какие шаги пересобираются при правке одной строки. Опишите задачу — соберём картину и предложим порядок изменений.
- Схема текущей сборки: какие образы собираются, на каких агентах, из каких базовых слоёв, чем запускается сборка сейчас.
- Состав проектов: один репозиторий или несколько, есть ли общие базовые образы и кто от них зависит.
- Узкие места: что именно тормозит — установка зависимостей, компиляция, выгрузка образа в реестр, повторная сборка при неизменном коде.
- Требования к срокам выпуска: сколько сборок в день, за какое время нужен готовый артефакт, важна ли скорость на ветке разработки отдельно от релизной.
- Ограничения по доступам: куда открыт путь сборочным агентам — внутренний реестр, зеркала пакетов, приватные зависимости.
- Инфраструктурные границы: свои машины или управляемые агенты, сколько места можно отдать под кэш и где он должен переживать перезапуск.
- Инварианты: политики безопасности, проверки артефактов, требования к воспроизводимости сборки и возможности отката на предыдущий релиз.
С этим набором мы назовём, какие изменения дадут эффект в первую очередь, а какие можно отложить, и зафиксируем границы работ по срокам. Опишите задачу в удобном виде — вернёмся с оценкой и планом.
