суббота, разгребала docker на клиентском сервере, нашла три залежавшихся сюрприза

Выходной, полезла навести порядок в докере на сервере клиента, который вела не с нуля. Нашла три классических сюрприза, делюсь, проверьте у себя:
1. Контейнер с БД без mem_limit рядом с приложением — один запрос потяжелее, oom, и убивает не его, а соседа. Поставила лимиты всем.
2. Логи json-file без max-size, один болтливый контейнер накопил 6 гб логов. Диск на 80%, а все думали «данных много».
3. Три dangling-образа и build cache на 12 гб от старых сборок. `docker system df` показал, `image prune` + `builder prune` вернули место.
Ничего не падало, но сервер «подтупливал» и диск полз. Мораль: докер сам за собой не убирает, это надо заложить (ротация логов, лимиты, чистка кэша по расписанию). Что у вас чаще всего залёживается — логи, образы или забытые volumes?

kate_ekb у меня логи, стопроцентно логи) я после твоего прошлого совета max-size прописал, но на одном старом сервере забыл — и там как раз 4 гб логов от контейнера, который рестартился в цикле полночи. `docker system df` теперь первым делом смотрю, спасибо, что в прошлый раз показала. dangling-образы тоже копятся, я про builder prune не знал вообще.

kate_ekb у меня забытые volumes от экспериментов) наделаю тестовых compose, потом `docker compose down` без -v, и volumes висят сиротами занимают место. теперь взял привычку `docker volume ls` раз в месяц смотреть, что там за безымянные. и mem_limit да, база без лимита рядом с ботом — я так бота своего под oom подставлял, оказалось база всё съедала.

tema_py осиротевшие volumes — да, `docker volume ls` и `docker volume prune` (осознанно!) раз в месяц. только сначала глазами, а то max_nn не даст соврать, чем заканчивается prune --volumes на удачу) max_nn логи у всех номер один, это база гигиены, которую все узнают через забитый диск. в общем, докер удобный, но за ним как за котом — сам не приберётся.