Почему multi-stage сборка уменьшает размер Docker-образа?

Чтобы понять, почему multi-stage уменьшает размер, нужно помнить: каждый FROM начинает новую цепочку слоёв, а итоговый образ берётся только из последней стадии. Предыдущие стадии существуют “для сборки”, но не входят в финальный образ напрямую.

Откуда берётся большой размер в обычной сборке

1. Build-инструменты

• gcc, make, build-essential, python-dev и т.п.

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

2. Временные файлы и кэши

• кэш apt

• кэш pip (если не отключать)

• временные файлы сборки пакетов

3. Промежуточные артефакты

• исходники библиотек

• распакованные архивы

• тестовые/документные файлы, которые случайно остались

Что делает multi-stage по-другому

1. Разделяет “сборку” и “запуск”

• стадия builder может быть сколько угодно “толстой”

• стадия runtime остаётся “тонкой”

2. Контролирует, что попадёт в финал
   Финальный образ получает только то, что вы явно скопировали:

COPY --from=builder /install /usr/local

Это означает:

• нет компилятора

• нет кэша apt

• нет временных директорий сборки

• нет лишних пакетов

3. Позволяет минимизировать runtime-библиотеки
   Если нужны системные библиотеки для работы (например, libpq для Postgres), вы ставите только их, а не весь набор для сборки.

Практическая иллюстрация на уровне логики

Обычная сборка:

• поставили build-essential

• собрали зависимости

• build-essential остался в образе навсегда → + десятки/сотни мегабайт

Multi-stage:

• build-essential стоит только в builder

• runtime начинается “с чистого slim”

• копируются только готовые зависимости → образ заметно меньше

Вывод

Multi-stage уменьшает размер потому, что финальный образ не наследует слои со сборочными инструментами и мусором. Он содержит только runtime и необходимые артефакты, которые вы явно перенесли из builder-стадии.