Backgroud
Вину за проблему можно разделить между неправильной конфигурацией томов контейнера и проблемой с утечкой (невозможностью освобождения) временных данных, записанных в эти тома докера. Мы должны сопоставить (либо с папками хоста, либо с другими требованиями к постоянному хранилищу) все временные папки / журналы / рабочие папки нашего контейнера, в которые наши приложения часто и / или часто пишут. Docker не несет ответственности за очистку всех автоматически создаваемых так называемых EmptyDirs, расположенных по умолчанию в /var/lib/docker/overlay2/*/diff/*. Содержимое этих "непостоянных" папок должно автоматически очищаться докером после остановки контейнера, но, по-видимому, этого не происходит (их может быть даже невозможно очистить со стороны хоста, если контейнер все еще работает - и он может работать в течение нескольких месяцев вовремя).
Обходной путь
Обходной путь требует тщательной ручной очистки, и хотя он уже описан в другом месте, вы все же можете найти некоторые подсказки из моего тематического исследования, которое я попытался сделать как можно более поучительным и обобщаемым.
Итак, что случилось, так это то, что приложение-виновник (в моем случае clair-scanner) сумело записать за несколько месяцев сотни гигабайт данных во /diff/tmpвложенную папку докера.overlay2
du -sch /var/lib/docker/overlay2/<long random folder name seen as bloated in df -haT>/diff/tmp
271G total
Так как все эти подпапки в /diff/tmpбыли довольно понятны (все имели форму clair-scanner-*и устаревшие даты создания), я остановил связанный контейнер ( docker stop clair) и осторожно удалил эти устаревшие подпапки diff/tmp, начиная с одной (самой старой), и тестирование влияния на движок докеров (которое потребовало перезапуска [ systemctl restart docker] для освобождения дискового пространства):
rm -rf $(ls -at /var/lib/docker/overlay2/<long random folder name seen as bloated in df -haT>/diff/tmp | grep clair-scanner | tail -1)
Я освободил сотни гигабайт дискового пространства без необходимости переустанавливать докер или очищать все его папки. Все запущенные контейнеры должны были быть остановлены в какой-то момент, потому что для освобождения дискового пространства потребовался перезапуск демона докера, поэтому сначала убедитесь, что ваши отказоустойчивые контейнеры правильно работают на / другом узле / ах). Я бы хотел, чтобы docker pruneкоманда также могла охватывать устаревшие /diff/tmp(или даже /diff/*) данные (с помощью еще одного переключателя).
Этой проблеме уже 3 года, вы можете прочитать ее богатую и красочную историю на форумах Docker, где в 2019 году был предложен вариант, нацеленный на журналы приложений вышеуказанного решения, и, похоже, работал в нескольких настройках: https: // Forums.docker.com/t/some-way-to-clean-up-identify-contents-of-var-lib-docker-overlay/30604