DockerMiddleLive coding

На сервере кончилось место. Какие команды Docker помогут (и какая опасна)?

docker system df -v показывает категории. Чистить точечно: container/image/builder/network prune. docker system prune -a --volumes опасна — удалит unused volumes (включая БД, чей контейнер упал). Настройте log rotation в daemon.json.

Что съело диск

Прежде чем чистить — измерить. Категории: images, stopped containers, writable layers, volumes, build cache, container logs.

df -h /var/lib/docker
du -sh /var/lib/docker/*
docker system df -v
# TYPE         TOTAL  ACTIVE  SIZE     RECLAIMABLE
# Images       42     8       18GB     12GB
# Containers   15     5       2GB      1.2GB
# Local Volumes 9     6       6GB      2GB
# Build Cache  120    0       8GB      8GB

docker ps -a --size --format 'table {{.Names}}\t{{.Size}}'
find /var/lib/docker/containers -name '*-json.log' -size +100M -exec ls -lh {} \;

Безопасный cleanup

# 1. остановленные контейнеры
docker container prune -f

# 2. dangling образы (без тега, висят после rebuild)
docker image prune -f

# 3. весь buildx cache
docker buildx prune -f --keep-storage 2GB

# 4. логи json-file — обрезать, не удаляя файл
truncate -s 0 /var/lib/docker/containers/<id>/<id>-json.log

# 5. неиспользуемые сети
docker network prune -f

Опасная команда

# НЕ запускайте без понимания:
docker system prune -a --volumes
# удалит:
# - ВСЕ не запущенные образы (не только dangling)
# - все stopped containers
# - все unused networks
# - весь build cache
# - ВСЕ volumes без активного контейнера ← данные БД!

Volume считается «unused», если в момент prune нет контейнера, к нему подключённого. Если БД-контейнер упал и не перезапустился — её volume попадёт под удаление.

Профилактика

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "50m",
    "max-file": "5",
    "compress": "true"
  },
  "data-root": "/var/lib/docker"
}

В /etc/docker/daemon.json — ротация логов глобально. Можно переопределять на контейнер через --log-opt.

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

  • Никогда не rm -rf /var/lib/docker/overlay2/* — повредит metadata, daemon не стартует.
  • prune --volumes в одном шаге с -a на проде — частая причина потери данных.
  • BuildKit cache (--mount=type=cache) живёт в buildx prune, не в image prune.
  • Приложения, пишущие в writable layer (логи, uploads, /tmp), раздувают overlay — выносить в volume или tmpfs.
  • На CI-runner добавьте scheduled docker system prune -f --filter "until=24h".
  • Включите --filter "label!=keep" и маркируйте критичные образы/volumes лейблом.
  • На overlay2 размер из docker ps --size учитывает только writable layer, не общие image layers.
  • Сделайте backup volumes (docker run --rm -v vol:/data -v $PWD:/b alpine tar czf /b/vol.tgz /data) до любого prune --volumes.

Common mistakes

  • Запускать docker system prune -a --volumes на production без проверки.
  • Удалять каталоги внутри /var/lib/docker вручную.
  • Не проверять container logs и writable layer growth.

What the interviewer is testing

  • Использует docker system df -v and targeted prune commands.
  • Понимает risk of volumes and stopped state.
  • Учитывает log rotation and prevention.

Sources

Related topics