Чем 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.