Docker: занимает всё место на диске — причины и решение

MAATRIX

Диск внезапно забился под ноль, и виновник — Docker занимает всё место на диске. Это очень частая проблема: Docker копит образы, остановленные контейнеры, неиспользуемые тома и раздутые логи, и без уборки они съедают десятки гигабайт. Хорошая новость — почистить это безопасно и быстро, если знать, что именно занимает место. Разберём, как найти пожирателя и вернуть диск, не удалив нужное.

Первое действие: посмотрите, что занял Docker

Прежде чем чистить, оцените, где именно осел объём. У Docker есть встроенная команда, которая показывает расход по категориям:

docker system df

Она выведет, сколько места занимают образы (Images), контейнеры (Containers), тома (Local Volumes) и кэш сборки (Build Cache), и сколько из этого можно освободить (RECLAIMABLE). Это сразу показывает главного виновника: часто это старые образы и кэш сборки, иногда — забытые тома с данными, иногда — гигантские логи контейнеров. Дополнительно проверьте общий диск через df -h, чтобы понимать масштаб. Определив категорию, вы почистите именно её, не трогая нужное. Не бросайтесь сразу удалять всё подряд — сначала посмотрите картину, а потом выбирайте безопасный способ уборки.

Причина 1: накопились неиспользуемые образы и контейнеры

Самый частый пожиратель — старые образы и остановленные контейнеры. Каждая пересборка оставляет предыдущие слои, каждый запуск — контейнер, который после остановки не удаляется сам. Со временем это гигабайты «мусора». Безопасная уборка неиспользуемого одной командой:

docker system prune

Она удалит остановленные контейнеры, неиспользуемые сети и висячие (dangling) образы — то, на что ничего не ссылается. Это безопасно для работающих сервисов. Чтобы удалить и все неиспользуемые образы (не только висячие), добавьте флаг -a, но осторожно — уйдут образы, которые сейчас не запущены, даже если они вам нужны позже:

docker system prune -a

prune -a освобождает больше всего, но перечитайте, что удаляется, прежде чем подтверждать. Для регулярной жизни обычно достаточно docker system prune без -a. Эта уборка возвращает основную часть места в большинстве случаев переполнения.

Причина 2: забытые тома с данными

Тома (volumes) — коварная категория: в них лежат данные (базы, загрузки), и при удалении контейнера тома по умолчанию остаются, чтобы не потерять данные. Но забытые тома от давно удалённых контейнеров копятся и занимают место. Посмотрите список и найдите неиспользуемые:

docker volume ls
docker volume prune

docker volume prune удалит тома, не связанные ни с одним контейнером. Здесь нужна осторожность: убедитесь, что среди них нет тома с важными данными, который просто временно не подключён. В отличие от образов, тома часто содержат то, что нельзя терять, — поэтому именно по томам действуйте вдумчиво, а не автоматически. Если сомневаетесь в конкретном томе, сначала проверьте его содержимое. Удаляйте только те тома, о которых точно знаете, что данные в них не нужны. Забытые тома — частая причина, когда system prune почистил, а место всё равно занято.

Причина 3: раздутые логи контейнеров

Очень частая и незаметная причина — логи контейнеров. По умолчанию Docker пишет вывод контейнера в json-файл без ограничения размера, и «болтливый» контейнер за недели способен сгенерировать десятки гигабайт логов. Найдите крупнейшие лог-файлы контейнеров:

du -sh /var/lib/docker/containers/*/*-json.log | sort -rh | head

Если увидели гигантские *-json.log — вот пожиратель. Разово обнулить лог конкретного контейнера можно, но правильное решение — ограничить размер логов через драйвер логирования. Задайте лимит в настройках демона или в compose:

logging:
  driver: json-file
  options:
    max-size: "10m"
    max-file: "3"

Это заставит Docker ротировать логи, храня, например, три файла по 10 МБ. Без такого лимита логи будут расти бесконечно. Настройка ограничения логов — обязательная гигиена для любого боевого Docker-хоста, иначе переполнение диска логами повторится.

Причина 4: кэш сборки образов

Если вы часто собираете образы на сервере, кэш сборки (build cache) разрастается — особенно с современным сборщиком BuildKit, который агрессивно кэширует слои для скорости. docker system df покажет объём в строке Build Cache. Почистить именно его:

docker builder prune

Команда удалит кэш сборки, освободив место, но следующая сборка пойдёт медленнее, так как кэш придётся набрать заново — это нормальный компромисс. Если сборки идут на отдельном CI-сервере, кэш там особенно склонен разрастаться. Регулярная очистка кэша сборки по расписанию или лимит его размера решают проблему. Для серверов, которые только запускают образы, а не собирают их, эта категория обычно невелика, и основное место занимают образы, тома и логи из предыдущих разделов.

Как безопасно освободить место прямо сейчас

Если диск переполнен и сервисы под угрозой, действуйте по нарастающей безопасности. Сначала безопасная общая уборка, затем логи и кэш, и только в конце — тома с проверкой:

docker system prune
docker builder prune

Этой пары обычно достаточно, чтобы вернуть заметный объём без риска для данных. Затем разберитесь с логами (ограничьте их размер, чтобы проблема не вернулась) и, вдумчиво, с забытыми томами. Проверяйте результат через docker system df и df -h после каждого шага. Ключевой принцип: образы и кэш восстанавливаемы (пересоберутся или скачаются заново), а тома могут содержать невосстановимые данные — поэтому к ним относитесь как к последней и самой аккуратной цели уборки.

Профилактика: чтобы Docker не забивал диск

Чтобы переполнение не повторялось, встройте гигиену в настройку хоста. Обязательно ограничьте размер логов контейнеров через max-size и max-file в конфиге демона — это снимает самую незаметную причину роста. Настройте регулярную автоматическую уборку неиспользуемого (docker system prune по расписанию) и очистку кэша сборки, особенно на серверах, где часто пересобираются образы. Мониторьте свободное место с оповещением на 80–85% заполнения, чтобы реагировать заранее, а не в аврале.

Наводите порядок в томах: удаляйте тома вместе с контейнерами, когда данные больше не нужны, и документируйте, где лежат важные данные, чтобы случайно не удалить их при уборке. Держите на сервере под Docker разумный запас диска — контейнеризация по своей природе накапливает слои и артефакты, и запас места избавляет от постоянной борьбы за гигабайты. Настроенные лимиты логов и регулярный prune вместе делают переполнение диска Docker'ом проблемой, о которой вы просто забываете.

Частые вопросы