Что такое мультистейджинг в рамках сборки?

Мультистейджинг в Docker и контейнерной сборке

Мультистейджинг (multi-stage builds) — это ключевая оптимизация процесса сборки Docker образов, позволяющая использовать несколько промежуточных образов (stage) в одном Dockerfile для создания финального, минимального и безопасного контейнера. Это решает классическую проблему, когда итоговый образ содержал не только конечное приложение, но и все инструменты сборки, исходный код и временные файлы, что приводило к огромному размеру и потенциальным уязвимостям.

Как работает муталистейджинг

В одном Dockerfile вы определяете несколько stage с помощью ключевого слова FROM. Каждый stage имеет свою базу (базовый образ) и выполняет свою часть работы. Финальный stage (обычно последний) копирует только необходимые артефакты из предыдущих stage, исключая все инструменты и промежуточные данные.

Пример Dockerfile с мультистейджингом для Go приложения:

# Первый стейдж: сборка приложения (builder)
FROM golang:1.21-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN go build -o myapp ./cmd/main.go

# Второй стейдж: финальный, минимальный образ
FROM alpine:latest AS runtime
WORKDIR /root/
# Копируем только бинарник из стейджа builder, ничего больше
COPY --from=builder /app/myapp .
RUN chmod +x /app/myapp
EXPOSE 8080
CMD ["./app/myapp"]

Преимущества мультистейджинга

• Значительное уменьшение размера финального образa: В примере выше финальный образ основан на alpine (~5MB) и содержит только бинарник, вместо полного golang образa (~300MB) со всеми компиляторами и исходным кодом.
• Улучшение безопасности: Финальный образ не содержит инструментов сборки (компиляторов, утилит), исходного кода, временных файлов, что снижает поверхность для атак и устраняет риск утечки кода.
• Оптимизация процесса CI/CD: Упрощается pipeline. Вся сборка происходит в одном Dockerfile, нет необходимости в отдельных скриптах для очистки или передачи артефактов между этапами.
• Сохранение эффективности сборки: Каждый stage может использовать оптимальный базовый образ для своей задачи (например, golang для компиляции, node для установки npm пакетов).

Практическое применение в DevOps

В реальных DevOps процессах мультистейджинг интегрируется в CI/CD pipelines (GitHub Actions, GitLab CI, Jenkins):

# Пример этапа в GitLab CI .gitlab-ci.yml
build:
  stage: build
  script:
    - docker build --target builder --tag $CI_REGISTRY_IMAGE/builder:$CI_COMMIT_SHA .
    - docker build --tag $CI_REGISTRY_IMAGE/app:$CI_COMMIT_SHA .

Часто используется стратегия, где первый stage (builder) используется для запуска unit-тестов или линтеров прямо в процессе сборки, а финальный образ уже гарантированно содержит проверенный код.

Важные детали реализации

• Имена stage (например, AS builder) используются для ссылок при копировании (COPY --from=builder).
• Можно использовать несколько промежуточных stage для разных задач (компиляции фронтенда, бекенда, генерации документации).
• Финальный stage может быть основан на совершенно другом базовом образе, оптимизированном для runtime (например, distroless образы от Google для полного минимализма).

Мультистейджинг — это не просто техническая особенность Docker, а принцип разделения ответственности в контейнерной сборке, напрямую влияющий на безопасность, стоимость хранения образов в registry и скорость их передачи в production. Современные DevOps практики практически всегда требуют его использования для production-образов.