DockerMiddleCoding

Чем BuildKit отличается от старого билдера? Что даёт --mount=type=cache?

BuildKit параллелит stages, добавляет расширенный синтаксис RUN --mount, поддерживает secrets/SSH и cache export в registry. --mount=type=cache даёт persistent директорию для package manager downloads, которая не записывается в image layer.

BuildKit vs старый builder

Классический Docker builder выполняет Dockerfile линейно, строго последовательно. BuildKit строит DAG (directed acyclic graph) инструкций и параллелит независимые ветки. Ключевые отличия:

  • Параллельная сборка multi-stage Dockerfile: независимые stages выполняются одновременно.
  • Расширенный синтаксис RUN: --mount=type=cache|secret|ssh|bind|tmpfs.
  • Cache export/import: --cache-to type=registry / --cache-from для CI.
  • Secrets и SSH mounts: передача чувствительных данных без записи в layer.
  • Build провенанс и SBOM: attestations через --attest type=provenance.
  • Inline cache: кэш может быть встроен в сам image manifest.

Активируется через DOCKER_BUILDKIT=1 (по умолчанию включён с Docker 23+) или через docker buildx build.

Что даёт --mount=type=cache

Cache mount создаёт persistent директорию на стороне builder, которая переиспользуется между сборками, но не попадает в итоговый image layer. Это решает проблему package manager: скачанные пакеты не нужно удалять из image, потому что они никогда в него не записывались.

# syntax=docker/dockerfile:1
FROM python:3.13-slim
WORKDIR /app
COPY requirements.txt ./
RUN --mount=type=cache,target=/root/.cache/pip \
    pip install --requirement requirements.txt
COPY . .
# syntax=docker/dockerfile:1
FROM node:22-alpine
WORKDIR /app
COPY package.json package-lock.json ./
RUN --mount=type=cache,target=/root/.npm \
    npm ci
COPY src ./src
# syntax=docker/dockerfile:1
FROM golang:1.23 AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN --mount=type=cache,target=/go/pkg/mod \
    --mount=type=cache,target=/root/.cache/go-build \
    go mod download
COPY . .
RUN --mount=type=cache,target=/go/pkg/mod \
    --mount=type=cache,target=/root/.cache/go-build \
    go build -o /bin/api ./cmd/api

Scope и sharing

По умолчанию cache mount scope — shared: несколько параллельных builds могут обращаться к нему одновременно. Для package managers это безопасно (read-mostly). Если нужна эксклюзивность — sharing=locked или sharing=private.

Подводные камни

  • Cache mount не является частью image: сборка не должна зависеть от файлов, которые есть только в кэше. На новом builder кэша нет.
  • Если внутри RUN команда копирует что-то из cache mount в image (например, бинарник pip-downloaded wheel) — эти байты попадут в layer. Это нормально; опасно копировать credentials.
  • Не кладите токены или private keys в cache mount: он shared между сборками на одном builder.
  • В CI без persistent builder (ephemeral runners) cache mount даёт нулевой выигрыш при первом запуске; нужен BuildKit cache export в registry для реального ускорения.
  • Комбинирование --mount=type=cache и rm -rf /root/.cache в том же RUN уничтожает накопленный кэш — не делайте так.
  • Строка # syntax=docker/dockerfile:1 в первой строке обязательна для активации расширенного синтаксиса (без BuildKit она игнорируется, с BuildKit — указывает версию frontend).
  • В Docker Desktop cache mount работает «из коробки»; в rootless Docker и некоторых CI агентах может потребоваться дополнительная настройка builder.
  • Go требует двух cache директорий: /go/pkg/mod (module cache) и /root/.cache/go-build (build cache) — пропуск второй убирает половину ускорения.

Common mistakes

  • Думать, что cache mount добавляет файлы в финальный image.
  • Использовать cache mount как источник обязательных runtime файлов.
  • Передавать секреты через ARG вместо BuildKit secrets.

What the interviewer is testing

  • Называет конкретные возможности BuildKit.
  • Объясняет назначение --mount=type=cache.
  • Понимает CI cache export/import и ограничения ephemeral runners.

Sources

Related topics