Что еще нужно очищать в Docker кроме контейнеров

Что проверяют

Эксплуатационную зрелость: понимаете ли вы, что место на диске выедают не контейнеры, а слои образов и кэш сборки. Питонисту это прилетает на своём раннере или на рабочей машине, где образ пересобирается по десять раз в день из-за правки в зависимостях.

Как отвечать

Пройдитесь по объектам Docker и назовите команду к каждому:

• образы: docker image prune убирает только висячие слои без тега, а docker image prune -a все образы, на которые никто не ссылается;
• кэш сборки: docker builder prune, самый частый виновник роста при постоянной пересборке слоя с установкой пакетов;
• тома: docker volume prune, причём в свежих версиях по умолчанию чистятся только анонимные, а именованные удаляются отдельно и осознанно;
• сети: docker network prune;
• логи контейнеров: драйвер json-file пишет без ограничения, лечится опциями max-size и max-file в настройках демона или в compose-файле;
• сводка занятого: docker system df и подробный docker system df -v, общая уборка docker system prune.

Хорошо добавить профилактику вместо уборки: многоступенчатая сборка, чтобы компилятор и сборочные пакеты не ехали в финальный образ, .dockerignore с виртуальным окружением, кэшем байткода и данными, установка пакетов без локального кэша.

Где спотыкаются

Помнят про удаление контейнеров и образов, забывают про кэш сборки. На машине сборки именно он занимает десятки гигабайт, поэтому «почистил всё, места всё равно нет» это почти всегда неубранный кэш слоёв.

Считают prune тотальной командой. docker system prune не трогает тома без отдельного флага и не удаляет образы, занятые контейнерами, а docker volume prune проходит мимо именованных томов. Человек уверен, что убрал всё, а сводка показывает те же цифры.

Чистят рабочий хост, не думая о последствиях. Флаг -a на машине с остановленными сервисами стирает их образы, и следующий запуск тянет всё из реестра; том с данными базы, снесённый заодно, восстанавливается только из резервной копии.