Что такое multi-stage build в Docker и зачем он используется?

Question

Multi-stage build — это сборка Docker-образа в несколько этапов, где на ранних этапах собираются зависимости и артефакты, а в финальный образ попадает только то, что нужно для запуска. Это уменьшает размер образа и снижает количество лишних инструментов внутри контейнера. Обычно на первом этапе ставят компиляторы и build-зависимости, а на последнем — только runtime. Такой подход ускоряет доставку и снижает поверхность атаки.

YeaHub · Accepted Answer

Multi-stage build — это техника, когда один Dockerfile содержит несколько “стадий” (этапов) сборки, а итоговый образ формируется из результатов предыдущих стадий. Идея простая: “строим тяжёлым образом, запускаем лёгким”.Зачем это нужноУменьшение размера образаbuild-зависимости (gcc, make, headers) не попадают в production-образменьше слоёв с мусором и временными файламиПовышение безопасностив финальном контейнере меньше инструментов, которыми можно злоупотребитьменьше пакетов → меньше потенциальных уязвимостейУскорение доставки и деплоямаленькие образы быстрее пушатся в registry и быстрее скачиваются на серверРазделение ответственностиотдельная стадия “сборка” и отдельная “рантайм” упрощают поддержку DockerfileКак это выглядит в DockerfileПример для Python-проекта, где есть зависимости, которые требуют сборки (условно psycopg, lxml, и т.п.). Суть: в builder ставим всё тяжёлое, а в runtime — только установленное.# 1) Стадия сборки (builder)
FROM python:3.11-slim AS builder

WORKDIR /app

# build-зависимости (примерно)
RUN apt-get update && apt-get install -y --no-install-recommends \
    build-essential \
    # ... другие пакеты, если нужны ...
    && rm -rf /var/lib/apt/lists/*

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt --prefix=/install

# 2) Финальная стадия (runtime)
FROM python:3.11-slim AS runtime

WORKDIR /app

# копируем только установленные зависимости
COPY --from=builder /install /usr/local

COPY . .
CMD ["python", "app.py"]
Что важно в этом примере:builder содержит компиляторы и build-инструменты, но они не переходят в финальный образзависимости устанавливаются в отдельный путь (/install), который затем копируется в runtimeТипичные схемы использованияPython + зависимости, которые компилируютсясборка wheel/бинарников на этапе builderперенос только wheels или готовой site-packages в runtimeFrontend + backendна этапе builder собирается frontend (npm ci, npm run build)в финальный образ копируется только dist/backend остаётся лёгкимГенерация артефактовмиграции, схемы, статические файлы, бинарники CLI — всё можно собрать отдельно и копироватьЧастые ошибки и нюансы“Случайно” тащат весь проект из builderесли сделать COPY --from=builder /app /app, можно перетащить мусор (кэш, временные файлы)Ломают зависимости на runtimeесли на builder стоит один набор системных библиотек, а в runtime их нет, бинарные зависимости могут не запуститьсярешение: либо ставить нужные runtime-либы, либо использовать одинаковую базу (например, оба python:3.11-slim) и аккуратно добавлять только runtime-пакетыПереиспользование кэшапорядок инструкций важенобычно COPY requirements.txt и установка зависимостей делается до COPY ., чтобы при изменении кода не пересобирать зависимостиВыводMulti-stage build стоит использовать, когда в сборке участвуют тяжёлые зависимости или отдельные артефакты (сборка пакетов, фронтенда, бинарников). Он помогает сделать production-образ меньше, безопаснее и проще в доставке.