Настройка Buildah для сборки OCI-образов без Docker

Buildah: сборка OCI-образов без демона и прав суперпользователя

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

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

Buildah снимает эту зависимость: сборка OCI-образов без Docker идёт отдельными процессами без долгоживущего демона, поэтому не нужно ни прокидывать сокет, ни держать на узле постоянно работающую привилегированную службу. В rootless-режиме сборка выполняется от обычного пользователя — изоляция строится на пользовательских пространствах имён и диапазонах подчинённых идентификаторов, а слои пишутся прямо в хранилище образа.

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

Что даёт сборка образов без привилегированного демона

Сборка без привилегированного демона идёт от имени обычного пользователя: Buildah собирает образ в изолированном пространстве имён, без доступа к сокету и без прав root на узле. Изменения затрагивают только рабочий каталог, поэтому сбой на этапе сборки не выходит за её границы и не роняет соседние задачи.

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

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

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

Где уместен Buildah: сравнение режимов сборки

Buildah собирает OCI-образы напрямую, без постоянно работающего демона, поэтому один и тот же Containerfile можно прогнать в разных режимах — на машине разработчика, на сборочном узле конвейера или внутри изолированного окружения. Отличаются они не синтаксисом, а правами, доступом к сети и тем, кто отвечает за чистоту локального хранилища. Именно поэтому режим выбирают под задачу, а не «на глаз».

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

Как проходит внедрение сборки на Buildah

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

1. Обследование сборок. Собираем инвентарь: какие образы выпускаются, из каких базовых слоёв, где сборка обращается к сети, секретам и правам root. На выходе — карта зависимостей и список мест, которые нельзя переносить «как есть».
2. Целевая схема. Определяем, что остаётся в одном описании, что выносится в многоэтапную сборку, какие слои кешируются между релизами и какие проверки обязательны до публикации.
3. Перенос описаний. Переписываем инструкции под новые команды и монтирования, убираем шаги, которые держались на демоне. Каждый образ проходит сверку состава: те же пакеты, тот же пользователь, тот же набор файлов.
4. Проверка воспроизводимости. Две сборки одного и того же исходного кода должны совпасть по составу и контрольной сумме. Расходится — ищем неявные зависимости: обновление пакетов из сети, порядок слоёв, метки времени.
5. Прогон на конвейере. Подключаем сборку к конвейеру выпуска и смотрим время сборки, публикацию в реестр и откат на предыдущий образ.
6. Передача и регламент. Документируем, как добавить образ, обновить базовый слой и что делать при расхождении сборок.

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

Комплект передачи: описания сборок, роли, регламенты

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

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

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

Кейс: как сборка образов перестала зависеть от привилегий

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

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

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

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

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

Чем отличается сборка без демона от классической сборки?

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

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

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

Сомнения инженеров: кэш, приватные реестры, совместимость

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

Как быть с закрытыми реестрами?

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

Сохранится ли кэш слоёв между сборками?

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

Соберётся ли образ под несколько архитектур?

Одна команда собирает образы под x86-64 и arm64, а в реестр уходит список платформ — среда исполнения сама выбирает нужный вариант. Сборку под чужую архитектуру ускоряем эмуляцией и проверяем обе платформы в одном прогоне.

Обсудим задачу: что уточнить перед стартом работ по сборке

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

• Сборочные описания и скрипты: действующие Dockerfile, entrypoint, шаги заданий — по ним видно, какие инструкции перестают работать при сборке без демона.
• Целевые реестры и доступы: адреса хранилищ, отдельные учётные записи на чтение базовых слоёв и запись результата, требования к подписи образов.
• Матрица платформ: для каких архитектур собираем и нужна ли мультиархитектурная сборка — на одном узле или распределённо.
• Базовые образы: разрешённые источники и внутренние зеркала, требования к минимальному составу пакетов и обновлению уязвимостей.
• Среда сборки: раннеры без прав root, доступ в сеть, лимиты процессора и диска, требования к кэшу слоёв между запусками.
• Политика тегов и хранения: схема версионирования, правила очистки реестра, глубина отката на предыдущие релизы.
• Среда деплоя: кластер или отдельные хосты, проверки работоспособности, требования к откату на прошлую версию.

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