Docker Multi-stage Builds: Худеем образы в 10 раз
Суть без длинного чтения
Если нужен быстрый вывод по теме, ниже собрали главное: что это значит, когда проблема уже влияет на бизнес и какой следующий шаг обычно даёт пользу быстрее всего.
О чем статья
Избавляемся от ENOSPC (No space left on device) и ускоряем деплой.
В какой момент это становится проблемой
Проблема созрела, если релизы делаются вручную, production плохо наблюдаем, а сбои превращаются в дорогой и плохо управляемый процесс.
Что делать после прочтения
Следующий практический шаг — зафиксировать текущие риски, целевой результат и первую очередь работ, чтобы не лечить проблему наугад.
#01Проблема толстых образов
Когда вы пишете COPY . . и RUN npm install, в финальный образ попадает папка node_modules с кучей мусора (DevDependencies, исходники TypeScript и т.д.). В итоге образ весит гигабайты, сервер быстро забивается, а деплой длится вечность.
#02Решение: Multi-stage сборка
Мы разделяем Dockerfile на этапы (stages):
Вуаля! В финальном образе нет исходников и тяжелых тулзов для сборки. Размер уменьшается на 80-90%.
- Deps: Устанавливаем все зависимости (включая dev).
- Builder: Копируем исходники, собираем проект (TypeScript -> JS, Next.js build).
- Runner: Берем чистый минималистичный образ (node:alpine), копируем туда только скомпилированные файлы из Builder'а и только production-зависимости.
Редакционная проверка и источники
Материал подготовлен как практический разбор и привязан к рабочим сценариям бизнеса, а не к абстрактной теории.
Готовы внедрить это решение в ваш бизнес?
Закажите индивидуальную консультацию и проектный аудит со сметным договором.