На хосте с множеством контейнеров внезапно заканчивается место на диске, хотя образы и volumes небольшие. Как диагностировать и какие причины наиболее вероятны?

Короткий ответ

Частая причина — неограниченный рост лог-файлов контейнеров при драйвере логирования json-file по умолчанию без настроенной ротации; диагностируется через du -sh /var/lib/docker/containers//.json.log, лечится настройкой log-opts с max-size/max-file или сменой log driver.

Как это работает подробнее

по умолчанию Docker пишет весь stdout/stderr контейнера в файл *-json.log на хосте без ограничения размера, если явно не настроены опции ротации. Приложение, которое интенсивно логирует (особенно в debug-уровне или при цикле ошибок с повторными попытками), может за короткое время накопить гигабайты в одном лог-файле, незаметные через обычный просмотр docker images/docker system df, который не всегда явно выделяет логи как отдельную категорию.

Пример кода

config.jsonКопировать

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Что использовать на практике

• Практика. диагностику начинают с docker system df для общей картины, затем смотрят du -sh по директориям /var/lib/docker/containers/, /var/lib/docker/overlay2/, /var/lib/docker/volumes/ отдельно, чтобы понять, какая категория реально расходует место. Для предотвращения повторения настраивают ротацию логов на уровне демона (daemon.json) или конкретного контейнера.

Подводные камни

• Риск. включают избыточное debug-логирование в production без настроенной ротации; считают, что docker system prune решит проблему растущих логов активных (не остановленных) контейнеров — prune не трогает логи работающих контейнеров, только неиспользуемые образы/сети/остановленные контейнеры.