Безопасное удаление Docker сетей и томов в 2026: полное руководство по очистке | AdminWiki
Logo
Timeweb Cloud — сервера, Kubernetes, S3, Terraform. Лучшие цены IaaS.
Попробовать

Безопасное удаление Docker сетей и томов в 2026: полное руководство по очистке

02 апреля 2026 8 мин. чтения
Содержание статьи

Накопившиеся неиспользуемые Docker сети и тома — это не просто «мусор», а потенциальный источник конфликтов, проблем с безопасностью и нерационального использования дискового пространства. Однако поспешное удаление ресурсов командой docker rm -f может привести к остановке критичных сервисов и безвозвратной потере данных. Это практическое руководство предоставляет DevOps-инженерам и системным администраторам полный, проверенный алгоритм безопасной очистки Docker-окружения. Вы получите точные команды для точечного (docker network/volume rm) и массового (prune) удаления, научитесь проводить обязательные проверки, решать частые проблемы и автоматизировать процесс с помощью готовых bash-скриптов, которые можно сразу интегрировать в рабочий процесс или CI/CD.

Почему нельзя просто удалить всё: риски и необходимые проверки

Удаление сетей (network) и томов (volume) в Docker — операция, требующая осознанности. В отличие от остановленных контейнеров, эти ресурсы могут быть невидимо связаны с работающими сервисами. Удаление используемой сети разорвет сетевое взаимодействие между контейнерами, что приведет к сбоям в работе приложений. Удаление используемого тома, особенно с данными базы данных или конфигурациями, — это прямая потеря информации, часто невосполнимая. Флаг принудительного удаления -f существует для крайних случаев (например, зависших endpoint), но его рутинное применение — верный путь к инцидентам. Основа безопасности — всегда проверять, что удаляемый ресурс не используется.

Как проверить, используется ли сеть или том перед удалением

Первый и обязательный шаг — инвентаризация и проверка зависимостей. Начните с общего обзора:

docker network ls
docker volume ls

Обратите внимание на столбцы DRIVER и SCOPE. Для детальной проверки конкретной сети выполните команду инспекции, которая покажет все подключенные контейнеры:

docker network inspect my_app_network

В выводе команды найдите раздел "Containers". Если он пуст или отсутствует, сеть не используется. Для проверки тома можно использовать фильтр, чтобы найти все контейнеры (даже остановленные), которые его монтируют:

docker ps -a --filter volume=my_data_volume

Если команда не выводит ничего — том не используется. Альтернативно, проверьте монтирования у всех запущенных контейнеров: docker inspect --format='{{.Mounts}}' $(docker ps -q).

Что произойдет, если удалить ресурс, который использует контейнер

Последствия зависят от типа ресурса и его роли.

  • Удаление используемой сети: Контейнеры, подключенные к этой сети, мгновенно теряют связь по данному интерфейсу. Если у контейнера остались другие сети, он будет доступен только по ним. Если это была единственная сеть, контейнер окажется изолированным в сети none. Сервис, зависящий от сетевого взаимодействия (например, микросервис, ожидающий запросы от другого), станет неработоспособным, хотя сам процесс контейнера может продолжать работать.
  • Удаление используемого тома: При попытке контейнера обратиться к файлам на удаленном томе операционная система вернет ошибку "No such file or directory" или "Input/output error". Приложение внутри контейнера, скорее всего, упадет с критической ошибкой. Все данные, хранившиеся в томе, будут утеряны безвозвратно, так как Docker управляет жизненным циклом томов независимо от контейнеров.

Важно понимать: контейнер может не завершиться мгновенно при удалении тома, но его функциональность будет нарушена. Это делает подобные ошибки особенно коварными.

Точные команды для удаления: от одиночных ресурсов до массовой очистки

После проверки зависимостей можно приступать к удалению. Docker предоставляет два типа команд: для точечной работы с конкретными ресурсами (rm) и для массовой очистки всего неиспользуемого (prune).

docker network rm и docker volume rm: точечное удаление

Эти команды предназначены для удаления одного или нескольких явно указанных ресурсов.

Синтаксис удаления сетей:

docker network rm [OPTIONS] NETWORK [NETWORK...]

Пример: Удаление двух тестовых сетей.

docker network rm test_network_1 test_network_2

Синтаксис удаления томов (аналогичный):

docker volume rm my_old_volume

Ключевой флаг -f (force): Его применение заставляет Docker удалить ресурс, даже если он помечен как используемый. Оправданное использование: удаление сети, в которой остались «висячие» endpoint от давно удаленных контейнеров (ошибка "network has active endpoints"). Категорически не рекомендуется использовать -f для томов или сетей, к которым есть явно работающие подключения, — это гарантированный сбой сервиса.

Типичная ошибка при попытке удалить используемый ресурс:

Error response from daemon: network my_bridge is in use

Это сигнал к возврату на этап проверки с помощью docker network inspect.

docker network prune и docker volume prune: очистка всего лишнего

Команды prune — мощный инструмент для поддержания порядка. Они автоматически находят и удаляют все ресурсы, которые не используются ни одним контейнером (даже остановленным).

Базовая очистка сетей и томов:

docker network prune
WARNING! This will remove all custom networks not used by at least one container.
Are you sure you want to continue? [y/N] y
Deleted Networks:
testnet_old
project_x_backend

Total reclaimed space: 0B

docker volume prune
WARNING! This will remove all local volumes not used by at least one container.
Are you sure you want to continue? [y/N] y
Deleted Volumes:
project_postgres_data_old
anonymous_volume_abc123

Total reclaimed space: 1.24GB

По умолчанию команды запрашивают подтверждение ([y/N]). Для автоматизации можно добавить флаг -f или --force.

Важные дополнительные флаги для docker volume prune:

  • -a или --all: Удаляет все неиспользуемые тома, включая анонимные (anonymous), а не только именованные (named).
  • --filter: Позволяет задать критерии. Например, удалить только тома, созданные более недели назад: docker volume prune --filter "until=168h" -f.

Команда docker system prune -a --volumes — еще более агрессивный вариант, который удалит также остановленные контейнеры, все образы без тегов и билд-кэш. Используйте ее с крайней осторожностью в production.

Практические сценарии: как удалить ресурс, если он всё же используется

Что делать, если проверка показала, что сеть или том необходимы работающему контейнеру, но удалить их нужно? Алгоритм зависит от критичности сервиса.

Аккуратное отключение контейнера и перенос данных

Этот метод подходит для production-сервисов, где downtime должен быть минимальным, а данные — сохранены.

Алгоритм для тома с данными БД:

  1. Остановите контейнер: docker stop postgres_container.
  2. Создайте новый том: docker volume create postgres_data_new.
  3. Скопируйте данные со старого тома на новый с помощью утилитарного контейнера: 
    docker run --rm -v postgres_data_old:/from -v postgres_data_new:/to \
alpine ash -c "cd /from ; cp -a . /to"
  4. Пересоздайте контейнер, указав в его конфигурации новый том postgres_data_new.
  5. Запустите контейнер и убедитесь в его работоспособности.
  6. Удалите старый том: docker volume rm postgres_data_old.

Для сетей логика аналогична: создайте новую сеть, перезапустите связанные контейнеры с подключением к новой сети, после чего удалите старую.

Что делать с "осиротевшими" (dangling) ресурсами

Dangling-ресурсы — это тома, которые не привязаны ни к одному контейнеру, но не удаляются стандартным prune, потому что когда-то были созданы без явного имени (анонимные тома). Они часто остаются после сборок образов или неудачных запусков контейнеров.

Оценка масштаба: Команда docker system df покажет общий объем данных в категории Build Cache и Reclaimable.

Очистка dangling-томов: Можно использовать специальный фильтр (хотя в последних версиях Docker volume prune удаляет их по умолчанию).

docker volume prune --filter "dangling=true" -f

Ручное удаление: Если фильтр не сработал, найдите их через docker volume ls -f dangling=true, проверьте inspect и удалите по одному.

Автоматизация очистки: готовые bash-скрипты для интеграции в CI/CD

Ручной запуск команд prune — неэффективен. Гораздо надежнее настроить автоматическую очистку по расписанию или как часть пайплайна.

Скрипт для безопасной еженедельной очистки (cron)

Этот скрипт выполняет «умную» очистку раз в неделю, логируя свои действия. Он удаляет только те неиспользуемые ресурсы, которые созданы более 7 дней назад, что защищает от удаления томов от недавно остановленных контейнеров.

#!/bin/bash
# /usr/local/bin/docker-cleanup-weekly.sh

LOG_FILE="/var/log/docker-cleanup.log"
TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')

echo "[$TIMESTAMP] Начало очистки Docker." >> "$LOG_FILE"

# 1. Анализ текущего состояния
echo "[$TIMESTAMP] Текущее использование:" >> "$LOG_FILE"
docker system df >> "$LOG_FILE" 2>&1

# 2. Очистка сетей и томов старше 168 часов (7 дней)
echo "[$TIMESTAMP] Запуск очистки неиспользуемых ресурсов старше 7 дней..." >> "$LOG_FILE"
DELETED_OUTPUT=$(docker system prune -a --volumes --filter "until=168h" -f 2>&1)
echo "$DELETED_OUTPUT" >> "$LOG_FILE"

TIMESTAMP_END=$(date '+%Y-%m-%d %H:%M:%S')
echo "[$TIMESTAMP_END] Очистка завершена." >> "$LOG_FILE"
echo "---" >> "$LOG_FILE"

Настройка в cron (crontab -e):

# Запускать каждое воскресенье в 03:00
0 3 * * 0 /usr/local/bin/docker-cleanup-weekly.sh

Скрипт для очистки тестового окружения после прогона пайплайна

В CI/CD (GitLab CI, GitHub Actions) после тестов остаются десятки временных сетей и томов. Лучшая практика — помечать их при создании специальными labels и удалять по этому признаку.

Пример этапа в .gitlab-ci.yml:

cleanup_docker:
  stage: .post
  script:
    - echo "Удаление тестовых ресурсов Docker с label=ci-job=$CI_JOB_ID"
    # Удаление сетей
    - for network in $(docker network ls --filter "label=ci-job=$CI_JOB_ID" -q); do
        docker network rm -f $network || true;
      done
    # Удаление томов
    - for volume in $(docker volume ls --filter "label=ci-job=$CI_JOB_ID" -q); do
        docker volume rm -f $volume || true;
      done
  when: always # Выполнять даже при падении предыдущих этапов

При создании тестовых ресурсов в пайплайне добавляйте метку: docker run -d --label ci-job=$CI_JOB_ID --network-alias test ... или docker volume create --label ci-job=$CI_JOB_ID ....

Для более глубокого понимания основ контейнеризации, которые лежат в основе управления этими ресурсами, рекомендуем наше полное руководство по Docker для системных администраторов и DevOps.

Итог: стратегия поддержания порядка в Docker-окружении

Безопасное управление жизненным циклом сетей и томов сводится к нескольким ключевым принципам, которые остаются актуальными и в 2026 году:

  1. Проверяйте перед удалением. Всегда используйте inspect и фильтры для ps, чтобы убедиться в отсутствии зависимостей.
  2. Используйте правильный инструмент. Для плановой уборки неиспользуемого — prune с фильтрами по времени. Для точечного удаления конкретного, проверенного ресурса — rm.
  3. Автоматизируйте рутину. Внедрите скрипты еженедельной очистки через cron и обязательный этап очистки в CI/CD-пайплайнах с использованием меток (labels).
  4. Избегайте флага -f без крайней необходимости. Рассматривайте его как аварийный инструмент, а не стандартную практику.

Следование этим правилам позволит поддерживать ваше Docker-окружение в чистоте и порядке, минимизируя риски для работоспособности сервисов и сохранности данных. Для решения более сложных задач оркестрации, таких как отладка пользовательских ресурсов в Kubernetes, вам может пригодиться наш гайд по полной диагностике Custom Resources.

Поделиться:
Сохранить гайд? В закладки браузера