Полное руководство по BuildKit: революция в сборке Docker-образов

BuildKit — это не просто улучшенный сборщик образов, это принципиально новая архитектура, которая превращает Docker-сборки из последовательных операций в высокооптимизированный граф параллельных вычислений.

BuildKit стал стандартным движком для сборки Docker-образов в Docker Desktop и Docker Engine версии 23.0 и выше, предлагая значительные улучшения в производительности, безопасности и гибкости по сравнению с legacy-сборщиком. В этой статье мы подробно разберем, как полностью раскрыть потенциал этой технологии.

Содержание

Архитектура BuildKit: как работает современный сборщик образов

LLB — низкоуровневое промежуточное представление

В основе BuildKit лежит Low-Level Build (LLB) — бинарный формат промежуточного представления, который определяет контентно-адресуемый граф зависимостей для сборки сложных определений. Если провести аналогию с миром компиляторов, то LLB для Dockerfile — это то же, что LLVM IR для языка C.

Ключевые преимущества LLB:

Прямое отслеживание контрольных сумм графов сборки и контента
Более быстрая и точная система кэширования
Портативность кэша между разными хостами
Поддержка прямого монтирования данных и вложенных вызовов

Фронтенды и плагинная архитектура

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

Настройка и начало работы с BuildKit

Активация BuildKit

Для Docker Desktop и Docker Engine ≥23.0 BuildKit активирован по умолчанию. Для более ранних версий:

bash

# Включение для конкретной сборки
DOCKER_BUILDKIT=1 docker build .

# Постоянное включение через daemon.json
{
  "features": {
    "buildkit": true
  }
}

Важно: Buildx всегда использует BuildKit, поэтому при работе с Buildx дополнительная активация не требуется.

Конфигурация BuildKit через TOML

Для кастомизации поведения BuildKit используется конфигурационный файл в формате TOML:

toml

# /etc/buildkitd.toml
debug = true  # Включение отладки

# Настройка зеркал реестров
[registry."docker.io"]
  mirrors = ["mirror.gcr.io"]

# Настройка сертификатов для приватных реестров  
[registry."myregistry.com"]
  ca=["/etc/certs/myregistry.pem"]
  [[registry."myregistry.com".keypair]]
    key="/etc/certs/myregistry_key.pem"
    cert="/etc/certs/myregistry_cert.pem"

Применение конфигурации при создании builder:

bash

docker buildx create --use --name mybuilder \
  --driver docker-container \
  --buildkitd-config /etc/buildkitd.toml

Продвинутые возможности BuildKit

1. Монтирование секретов (Secret Mounts)

Проблема: Секреты (API-ключи, SSH-ключи) не должны попадать в финальный образ.

Решение BuildKit: Использование --mount=type=secret для временного монтирования секретов только на этапе сборки.

dockerfile

# syntax=docker/dockerfile:1.4
FROM alpine
RUN --mount=type=secret,id=mysecret \
    cat /run/secrets/mysecret > /secret_output.txt

Сборка с передачей секрета:

bash

echo "super-secret-token" > mysecret.txt
echo "mysecret.txt" >> .dockerignore  # Исключаем из контекста

docker build --secret id=mysecret,src=mysecret.txt -t secret-demo .

2. Кэширование через монтирование (Cache Mounts)

Важное уточнение: При использовании --mount=type=cache кэшировать нужно не целевые каталоги, а промежуточные.

Неправильно (кэш теряется):

dockerfile

RUN --mount=type=cache,target=/pip-packages \
    pip install --target=/pip-packages uwsgi

Правильно (кэшируется директория pip):

dockerfile

RUN --mount=type=cache,target=/root/.cache \
    pip install --target=/pip-packages uwsgi

3. Многостадийные сборки с оптимизацией

BuildKit автоматически определяет и пропускает неиспользуемые стадии сборки, что особенно эффективно в сочетании с многостадийными сборками.

Пример для Go-приложения:

dockerfile

# Стадия сборки
FROM golang:1.19 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp

# Финальная стадия (только она попадает в образ)
FROM alpine:latest
WORKDIR /root/
COPY --from=builder /app/myapp .
CMD ["./myapp"]

4. Параллельное выполнение независимых стадий

BuildKit анализирует зависимости между инструкциями Dockerfile и выполняет независимые стадии параллельно, что значительно ускоряет сборку.

BuildKit в CI/CD системах

GitLab CI: Rootless-режим

GitLab предлагает несколько методов интеграции BuildKit:

Метод	Требования безопасности	Команды	Когда использовать
BuildKit rootless	Без привилегированных контейнеров	`buildctl-daemonless.sh`	Максимальная безопасность, замена Kaniko
Docker Buildx	Требуется `docker:dind`	`docker buildx`	Знакомый workflow Docker
Native BuildKit	Требуется `docker:dind`	`buildctl`	Продвинутый контроль над BuildKit

Пример rootless-сборки в GitLab:

yaml

build-rootless:
  image:
    name: moby/buildkit:rootless
    entrypoint: [""]
  variables:
    BUILDKITD_FLAGS: --oci-worker-no-process-sandbox
  before_script:
    - mkdir -p ~/.docker
    - echo '{"auths":{"$CI_REGISTRY":{"username":"$CI_REGISTRY_USER","password":"$CI_REGISTRY_PASSWORD"}}}' > ~/.docker/config.json
  script:
    - |
      buildctl-daemonless.sh build \
        --frontend dockerfile.v0 \
        --local context=. \
        --local dockerfile=. \
        --output type=image,name=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA,push=true

Azure Pipelines

В Azure Pipelines BuildKit активируется через переменную окружения:

yaml

variables:
  DOCKER_BUILDKIT: 1

steps:
- task: Docker@2
  displayName: Build with BuildKit
  inputs:
    repository: $(imageName)
    command: build
    Dockerfile: app/Dockerfile

Kubernetes с GitLab Runners

Для экономичных сборок в Kubernetes можно использовать прерываемые ноды (preemptible) со скидкой до 60%:

terraform

resource "yandex_kubernetes_node_group" "node-group-runner" {
  instance_template {
    boot_disk {
      type = "network-ssd-nonreplicated"
      size = 186  # Удвоенная скорость при кратности 93 ГБ
    }
    
    scheduling_policy {
      preemptible = true  # Основная экономия
    }
    
    maintenance_policy {
      auto_repair = true  # Автовосстановление после прерывания
    }
  }
}

Практические рекомендации и best practices

Оптимизация Dockerfile для BuildKit

Используйте .dockerignore — BuildKit интеллектуально анализирует изменения и передает только измененные файлы
Сортируйте многострочные аргументы — для лучшей читаемости и поддержки
Объединяйте RUN-команды — уменьшение количества слоев и размера образа
Регулярно пересобирайте образы с --pull для обновления базовых образов

Управление кэшем

BuildKit предлагает несколько стратегий кэширования:

Локальный кэш — быстрый, но не расшаренный
Registry-кэш — расшаренный между хостами
Inline-кэш — встроенный в образ (экспериментальный)

Пример экспорта/импорта кэша через registry:

bash

docker buildx build --push \
  --cache-to type=registry,ref=myregistry/cache-image:latest \
  --cache-from type=registry,ref=myregistry/cache-image:latest \
  -t myapp:latest .

BuildKit на Windows (экспериментально)

BuildKit поддерживает Windows контейнеры в экспериментальном режиме:

Требования:

Docker Desktop ≥4.29
Windows Server 2019/2022 или Windows 11
Базовые образы: ServerCore:ltsc2019, ServerCore:ltsc2022, NanoServer:ltsc2022

Настройка:

powershell

# Скачивание и установка BuildKit
$version = "v0.22.0"
curl.exe -LO https://github.com/moby/buildkit/releases/download/$version/buildkit-$version.windows-amd64.tar.gz
tar.exe xvf .\buildkit-$version.windows-amd64.tar.gz

# Создание remote builder
docker buildx create --name buildkit-win --use --driver=remote npipe:////./pipe/buildkitd

Мониторинг и отладка

Включение отладочного режима

toml

# buildkitd.toml
debug = true

Анализ производительности сборки

BuildKit предоставляет детальную информацию о времени выполнения каждой стадии через флаг --progress=plain:

bash

docker build --progress=plain -t myapp .

Для анализа графа сборки можно использовать buildctl:

bash

buildctl debug dump-llb | jq .

Заключение

BuildKit — это не просто «более быстрый сборщик Docker-образов». Это принципиально новая архитектура, которая меняет подход к созданию контейнерных образов. От параллельного выполнения стадий и интеллектуального кэширования до безопасной работы с секретами — BuildKit предоставляет инструменты для профессиональной, безопасной и эффективной сборки.

Ключевые преимущества, которые вы получаете:

До 2-5 раз ускорение сборки за счет параллелизации
Безопасная работа с секретами и чувствительными данными
Портативный кэш между разными средами
Поддержка multi-arch сборок «из коробки»
Экстенсибильность через фронтенды и LLB

Начните использовать BuildKit уже сегодня — большинство возможностей доступны без изменения существующих Dockerfile, только за счет активации движка. Для максимального эффекта постепенно внедряйте многостадийные сборки, кэш-монтирования и другие продвинутые функции.

Статья подготовлена для dockerhosting.ru на основе официальной документации Docker , практического опыта внедрения в production-средах и интеграционных гайдов для CI/CD систем .

Полное руководство по BuildKit: революция в сборке Docker-образов

Архитектура BuildKit: как работает современный сборщик образов

LLB — низкоуровневое промежуточное представление

Фронтенды и плагинная архитектура

Настройка и начало работы с BuildKit

Активация BuildKit

Конфигурация BuildKit через TOML

Продвинутые возможности BuildKit

1. Монтирование секретов (Secret Mounts)

2. Кэширование через монтирование (Cache Mounts)

3. Многостадийные сборки с оптимизацией

4. Параллельное выполнение независимых стадий

BuildKit в CI/CD системах

GitLab CI: Rootless-режим

Azure Pipelines

Kubernetes с GitLab Runners

Практические рекомендации и best practices

Оптимизация Dockerfile для BuildKit

Управление кэшем

BuildKit на Windows (экспериментально)

Мониторинг и отладка

Включение отладочного режима

Анализ производительности сборки

Заключение

Добавить комментарий Отменить ответ