Образы и кэш сборок занимают диск. Использование RAM смотрите отдельно: большой buff/cache в Linux — файловый кэш, который может освобождаться при необходимости. По одному замеру нельзя установить утечку памяти.
Все команды ниже выполняются на машине, которую очищаете. Docker на Mac и Docker на VPS имеют разные данные. Перед очисткой дождитесь завершения CI build/deploy и других операций окружения.
1. Найти основной расход
df -h /
free -h
docker system df
docker buildx du
docker ps -a
docker stats --no-stream
df показывает диск, free — RAM и доступную память, docker system df — образы, volumes и build cache, docker stats — текущий расход контейнеров. На macOS команды free обычно нет. Не суммируйте размеры всех образов: они используют общие слои, которые не освобождаются при удалении каждого тега.
2. Сократить build cache
Кэш ускоряет следующую сборку и не является БД или пользовательскими файлами. В версиях Docker Buildx, поддерживающих этот параметр, можно оставить ему до 2 ГБ:
docker buildx prune --all --max-used-space 2gb
Подтвердите запрос Docker. Проверьте доступные параметры через docker buildx prune --help. Другой вариант — очистить давно не использовавшиеся записи:
docker buildx prune --filter 'until=24h'
Действует выбранный builder. Очистка не меняет процесс обновления, но будущий build может снова скачивать зависимости и компилировать код. Оценка reclaimable — не гарантия такого же прироста свободного места из-за общих слоёв.
3. Образы: сначала сохранить нужные ссылки
Задайте runtime root из своего профиля:
RUNTIME_ROOT=/srv/admingen/PROJECT_NAME/ENV_NAME
jq '{id, backend, admin, ops, services, imageArchive}' "$RUNTIME_ROOT/state/current.json" "$RUNTIME_ROOT/state/previous.json"
docker image ls
docker ps -a
PROJECT_NAME и ENV_NAME здесь — заменяемые части пути. Если previous ещё нет, просмотрите только current. Сохраните образы текущего/предыдущего релизов, сервисные образы всех окружений и всё, что требуется незавершённым операциям.
Имя <none> или флаг dangling сами по себе не означают мусор: приложение или сохранённый релиз могут ссылаться на точный image ID без тега. Массовые image/system prune не учитывают ваши JSON-релизы и могут удалить образы для отката.
Когда конкретный образ действительно не нужен, удалите его явно, без force:
docker image rm OLD_UNUSED_IMAGE_ID
4. Архивы и CI-кандидаты
Source и Archive сохраняют обычные tar-файлы вне Docker. Их не удаляет build-cache prune. В Source CI они находятся и в RUNTIME_ROOT/ci-source/candidates/PIPELINE_ID-JOB_ID/, и в RUNTIME_ROOT/image-archives/. После неуспешных запусков могут остаться incoming, staging и рабочая копия, путь которой указан в логе.
du -h -d 2 "$RUNTIME_ROOT/ci-source" "$RUNTIME_ROOT/image-archives"
du -h -d 2 "$RUNTIME_ROOT/incoming" "$RUNTIME_ROOT/staging"
Это Linux-команды. Сопоставьте архив с imageArchive.file и imageArchive.sha256 в current/previous. Runtime-копия обычно называется SHA256.tar. Сохраните текущий и предыдущий релизы и архивы незавершённых операций; удаляйте только выбранные старые файлы. Не удаляйте целиком runtime root. Автоматического сборщика старых релизов сейчас нет.
5. Volumes и постоянные данные
docker volume ls
docker inspect POSTGRES_CONTAINER --format '{{json .Mounts}}'
Замените POSTGRES_CONTAINER фактическим именем из docker ps. Отсутствие named volumes не означает отсутствие БД: в серверном размещении PostgreSQL может использовать bind mount, например RUNTIME_ROOT/data/postgres. Папки БД, media/files, backups, secrets, pki и state не являются кэшем.
Для остального диска используйте sudo du -xhd1 /, затем раскрывайте найденные крупные каталоги. /var/lib/docker и /var/lib/containerd вручную не чистят. Если место не освободилось после удаления файла, проверьте открытые удалённые файлы через sudo lsof +L1.
После очистки повторите df -h / и docker system df. Состав образов · Резервные копии.