BuildKit и buildx: multi-arch сборки, секреты сборки, экспорт кэша

[Marina_DevOps]

BuildKit давно не опция, а штатный сборщик: начиная с Docker Engine 23.0 команда docker build на Linux по умолчанию идёт через него. А buildx, плагин CLI, открывает остальное: сборку под несколько архитектур, секреты сборки, экспорт кэша. Если вы до сих пор собираете "как в главе 4", то теряете заметный кусок скорости и оставляете пару дыр в безопасности.

Билдеры и драйверы:

По умолчанию buildx работает через драйвер docker, встроенный в демон. Он быстрый, но с классическим image store не умеет ни multi-platform, ни экспорт кэша в registry. Для серьёзных задач создаём билдер на драйвере docker-container, он крутится в отдельном контейнере с полноценным BuildKit:

Код: Выделить всё

docker buildx create --name ci --driver docker-container --use
docker buildx inspect --bootstrap
docker buildx ls

Multi-arch сборка:

Типичная картина 2026 года: разработчики на Apple Silicon (arm64), прод на amd64, плюс пара дешёвых ARM-виртуалок под фоновые задачи. Один тег обязан работать везде. Это решает OCI image index: под одним тегом лежат манифесты для каждой платформы, и docker pull сам выбирает нужный.

Код: Выделить всё

docker run --privileged --rm tonistiigi/binfmt --install arm64
docker buildx build --platform linux/amd64,linux/arm64 \
  -t cr.yandex/crp1abc/app:1.4.0 --push .

Первая команда ставит QEMU-эмуляцию через binfmt_misc, без неё RUN-инструкции под чужую архитектуру не выполнятся. Эмуляция медленная, поэтому для компилируемых языков правильнее кросс-компиляция: сборочная стадия работает на родной архитектуре билдера, а целевую платформу получает через автоматические ARG:

Код: Выделить всё

# syntax=docker/dockerfile:1
FROM --platform=$BUILDPLATFORM golang:1.25-alpine AS build
ARG TARGETOS TARGETARCH
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=$TARGETOS GOARCH=$TARGETARCH \
    go build -o /out/app ./cmd/app

FROM gcr.io/distroless/static-debian12
COPY --from=build /out/app /app
USER nonroot
ENTRYPOINT ["/app"]

Секреты сборки:

ARG для токенов не годится: значения остаются в docker history и в метаданных образа. BuildKit монтирует секрет в RUN на время одной инструкции, в слои он не попадает:

Код: Выделить всё

RUN --mount=type=secret,id=npmrc,target=/root/.npmrc \
    npm ci --omit=dev

При сборке секрет передаём из файла или переменной окружения:

Код: Выделить всё

docker buildx build --secret id=npmrc,src=$HOME/.npmrc -t app:dev .
docker buildx build --secret id=token,env=NPM_TOKEN -t app:dev .

Для приватных git-репозиториев есть --ssh default и RUN --mount=type=ssh, агент пробрасывается внутрь сборки без копирования ключей.

Экспорт кэша:

На ноутбуке кэш слоёв живёт сам по себе. В CI раннеры обычно эфемерные, и каждая сборка стартует с нуля. Лечится экспортом кэша во внешнее хранилище, чаще всего в тот же registry:

Код: Выделить всё

docker buildx build \
  --cache-from type=registry,ref=cr.yandex/crp1abc/app:buildcache \
  --cache-to type=registry,ref=cr.yandex/crp1abc/app:buildcache,mode=max \
  --platform linux/amd64,linux/arm64 \
  -t cr.yandex/crp1abc/app:1.4.1 --push .

mode=max выгружает слои всех стадий, включая промежуточные, mode=min только финальные. Для multi-stage почти всегда нужен max, иначе тяжёлая build-стадия будет пересобираться каждый раз. Кроме registry есть type=local (каталог), type=gha (кэш GitHub Actions), type=s3. Inline-кэш (--cache-to type=inline) пишется прямо в образ, но умеет только mode=min.

Типичные грабли:

Секрет через ARG. Прогоните по старым образам docker history --no-trunc, токены там лежат открытым текстом. Такие токены надо перевыпускать, чистка Dockerfile не поможет, образ уже скачали.

--load с несколькими платформами падает на классическом image store: локальный Docker не умеет хранить image index. Либо --push сразу в registry, либо включайте containerd image store (галка в настройках Docker Desktop, в Engine опция containerd-snapshotter в daemon.json).

RUN --mount=type=cache не выгружается через --cache-to. Кэш-маунты живут только внутри конкретного билдера, на эфемерном раннере от них толку нет.

QEMU-эмуляция замедляет сборку в 5-10 раз, а отдельные рантаймы под ней просто зависают. Если arm64-сборка стала узким местом, берите нативный ARM-раннер вместо эмуляции.

Итог:

buildx это не экзотика, а нормальный режим работы docker build. Multi-platform через image index, секреты через mount вместо ARG, кэш в registry с mode=max. В следующей главе соберём из этих кусков конвейер CI/CD: автосборка по коммиту, сканирование Trivy и публикация по тегу.

[kube_ninja]

Прогоните по старым образам docker history --no-trunc, токены там лежат открытым текстом.

прогнал. нашел гитлабовский deploy token в образе двухлетней давности, который до сих пор в registry висит. пошел перевыпускать. неприятно, но лучше так чем через инцидент узнать

[torch123]

про type=gha дополню: у гитхаба лимит кэша 10 гигов на репозиторий, с mode=max и двумя-тремя образами он забивается за пару дней и старое начинает вытесняться. мы в итоге переехали на registry-кэш рядом с самими образами, и лимитов нет, и работает одинаково что в actions что на self-hosted

[bashuser]

полчаса долбился с ошибкой docker exporter does not currently support exporting manifest lists, пока не дочитал до граблей. включил containerd store в Docker Desktop, и --load с двумя платформами заработал. читайте главу до конца, короче

[klaus18]

а я долго не понимал зачем вообще buildx create, если build и так через BuildKit идет. ответ в начале главы: на дефолтном драйвере --cache-to type=registry просто ругается, что cache export не поддерживается. создал билдер на docker-container и все поехало