Если Docker-образ Django-приложения раздувается до 1,5 GB, это уже не «ну и ладно», а прямой издержковый сигнал. Большой образ бьёт не только по месту в registry — он замедляет CI/CD, усложняет откаты и делает деплой дороже по времени и нервам.
Что обычно лежит внутри лишним:
1. dev-зависимости, которые не нужны в production;
2. кэш, тестовые данные, сборочные артефакты;
3. исходники и файлы, которые не участвуют в запуске.
Хорошая практика здесь простая: разделять стадии сборки, ставить только runtime-зависимости и регулярно проверять, что реально попадает в финальный слой. Это тот редкий случай, когда оптимизация даёт не «красоту кода», а прямую экономию в процессе поставки 🚀
Для команды это полезный чек:
— образ меньше;
— сборки быстрее;
— деплой предсказуемее;
— меньше шансов тащить в прод лишнее.
3 шага, с которых стоит начать:
- посмотреть состав образа;
- убрать всё, что не нужно для запуска;
- пересобрать и сравнить размер до/после.
Маленькая оптимизация инфраструктуры часто даёт эффект, который чувствует не только разработка, но и бизнес.
Sitecraft Digest
@SitecraftDigestPro
Если Docker-образ Django-приложения раздувается до 1,5 GB, это уже не «ну и ладно», а прямой издержковый сигна
Этот пост опубликован в Telegram-канале Sitecraft Digest. Подписаться можно по ссылке: @SitecraftDigestPro.