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

Что даёт --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

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.

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) — пропуск второй убирает половину ускорения.

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

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