Сбой Docker Engine в рабочей среде - это критическая ситуация, которая приводит к простою сервисов и потере данных. В 2026 году основные причины остаются прежними: падение демона, нехватка дискового пространства и повреждение локальных образов. Это руководство содержит проверенные алгоритмы диагностики и восстановления для каждой из этих проблем. Вы получите конкретные команды для анализа логов, безопасной очистки диска, переустановки Docker с сохранением данных и настройки профилактики. Инструкции написаны для практикующих системных администраторов и DevOps-инженеров и позволяют восстановить работоспособность контейнерной инфраструктуры с минимальным временем простоя.
Экстренная диагностика: определяем тип сбоя Docker
Первое действие при любой ошибке Docker - точное определение её типа. Неправильная диагностика ведет к потере времени и риску усугубить проблему. Используйте этот алгоритм для быстрой классификации.
Анализ логов и ошибки запуска демона Docker
Если команды docker ps или docker info возвращают ошибку подключения к демону, проблема в работе Docker Engine. Запустите проверку статуса службы и просмотр логов.
systemctl status dockerКоманда покажет, активна ли служба. Ключевые состояния: active (running), failed, inactive (dead). Если служба неактивна, попробуйте её запустить и сразу посмотреть логи за последний час:
sudo systemctl start docker
journalctl -u docker --since "1 hour ago" -fВ логах ищите критические сообщения:
- "Failed to start Docker Application Container Engine." - общая ошибка запуска.
- "Error starting daemon: error initializing graphdriver" - проблема с драйвером хранения (overlay2, devicemapper). Часто связана с повреждением файловой системы в
/var/lib/docker. - "Cannot connect to the Docker daemon" - демон не запущен или недоступен через сокет.
- Указания на конкретный конфигурационный файл, например,
/etc/docker/daemon.json. Ошибка синтаксиса в этом файле блокирует запуск демона. Проверьте его валидность командойsudo docker --config /etc/docker daemon --validateили временно переименуйте файл для теста.
Если демон запускается, но контейнеры не работают, переходите к следующему шагу.
Как проверить, что проблема в нехватке дискового пространства
Ошибка "No space left on device" - самая распространенная причина сбоев в долго работающих средах. Сначала проверьте общую заполненность диска, на котором расположен каталог Docker (обычно /var/lib/docker).
df -h /var/lib/dockerЕсли использование близко к 100%, проанализируйте, что именно занимает место в подсистеме Docker. Для этого используйте встроенную утилиту:
docker system df -vКоманда выведет детальный отчет по четырем категориям:
- Images: Загруженные образы и их слои. Ищите образы без тегов (помечены как
<none>), которые часто остаются после сборок. - Containers: Запущенные и остановленные контейнеры. Остановленные контейнеры сохраняют свою файловую систему и могут занимать гигабайты.
- Local Volumes: Тома, не привязанные к контейнерам. Их размер нужно проверять отдельно.
- Build Cache: Кэш сборки образов. Может разрастаться до десятков гигабайт в активных CI/CD-средах.
Сочетание этих двух проверок (df -h и docker system df) точно укажет, является ли нехватка места корневой причиной сбоя. Для комплексного управления контейнерами, включая их остановку, перезапуск и мониторинг ресурсов, обратитесь к нашему практическому руководству по управлению Docker-контейнерами.
Безопасная очистка диска: освобождаем место без потери данных
После подтверждения нехватки места начинайте очистку с наименее рискованных действий, постепенно переходя к более агрессивным. Цель - освободить пространство, не удалив нужные volumes или образы.
Пошаговое использование docker system prune и docker image prune
Команда docker system prune - основной инструмент очистки. Она удаляет остановленные контейнеры, образы без тегов (dangling images) и неиспользуемые сети. По умолчанию тома не затрагиваются. Перед выполнением любой команды очистки всегда используйте флаг --dry-run, чтобы увидеть, что будет удалено.
docker system prune --dry-runЕсли список удаляемых объектов безопасен, выполните очистку:
docker system prune -fДля более глубокой очистки, включающей все неиспользуемые образы (не только dangling), а также кэш сборки, используйте команды с флагом -a и --all.
# Удалить все неиспользуемые образы
docker image prune -a
# Удалить кэш сборщика
docker builder pruneВнимание: Флаг --volumes для команды docker system prune удалит все тома, не используемые хотя бы одним контейнером. Это потенциально опасная операция. Используйте её только если вы уверены в том, какие тома можно удалить, или после создания бэкапа. Полную инструкцию по безопасной очистке всех компонентов Docker вы найдете в нашем отдельном руководстве: Полная очистка Docker: удаление контейнеров, образов и томов.
Что делать, если очистка не помогла: ищем "тяжелые" volumes и логи
Если стандартный prune не освободил достаточно места, проблема может быть в больших файлах внутри volumes или в разросшихся логах контейнеров. Сначала определите, какие тома самые объемные. Прямого способа посмотреть размер тома через Docker CLI нет, но можно найти его каталог в файловой системе:
sudo du -sh /var/lib/docker/volumes/* | sort -hr | head -10Эта команда покажет десять самых больших каталогов с томами. Для анализа содержимого конкретного тома смонтируйте его во временный контейнер:
docker run -it --rm -v имя_тома:/data alpine sh -c "du -sh /data/*"Второй источник - логи контейнеров. По умолчанию Docker использует драйвер журналирования json-file, который не ограничивает размер лог-файлов. Проверьте размер логов:
sudo find /var/lib/docker/containers -type f -name "*.log" -exec du -ch {} + | tail -1Для ротации логов настройте драйвер json-file с ограничениями в /etc/docker/daemon.json или переключитесь на драйвер local, который по умолчанию выполняет ротацию.
Восстановление после падения демона Docker и повреждения данных
Когда демон не запускается из-за критической ошибки или образы повреждены, требуется более глубокое вмешательство. Главный принцип - сохранить пользовательские данные (volumes) любой ценой.
Полная переустановка Docker Engine с сохранением volumes
Если логи демона указывают на неустранимую ошибку графдрайвера или повреждение метаданных, переустановка - самый быстрый путь. Следуйте этому чек-листу.
- Остановите службу Docker:
sudo systemctl stop docker. Убедитесь, что все контейнеры остановлены:docker ps -a(если демон частично отвечает). - Создайте резервную копию volumes: Это самый важный шаг. Все пользовательские данные хранятся в
/var/lib/docker/volumes/. Скопируйте этот каталог в безопасное место.sudo cp -rp /var/lib/docker/volumes /backup/path/docker_volumes_backup_$(date +%Y%m%d) - Удалите пакеты Docker: Команды зависят от дистрибутива. Для Ubuntu/Debian:
Используйтеsudo apt-get purge -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-pluginpurge, а неremove, чтобы удалить файлы конфигурации. - Очистите остаточные файлы (опционально, но рекомендуется): Удалите каталог Docker. Внимание: Это удалит все образы, контейнеры и сети. Данные в volumes уже скопированы.
sudo rm -rf /var/lib/docker - Установите Docker заново: Следуйте официальной инструкции для вашего дистрибутива или используйте скрипт установки.
- Восстановите volumes из бэкапа: Остановите демон (
sudo systemctl stop docker), скопируйте сохраненные volumes обратно в/var/lib/docker/, убедитесь, что права доступа корректны (обычноroot:root), и запустите демон снова. - Проверьте целостность данных: Запустите контейнер, использующий восстановленный том, и убедитесь, что данные на месте.
Как восстановить поврежденные образы и реестр данных
Повреждение образа проявляется ошибками вида "Error response from daemon: layer does not exist" или "failed to register layer" при запуске контейнера. Решение - принудительно удалить проблемный образ и загрузить его заново.
# Найти ID проблемного образа
docker images
# Принудительно удалить его
docker rmi -f <image_id>
# Загрузить заново из registry
docker pull <image_name:tag>Если повреждение затрагивает множество образов или реестр данных, можно очистить всё хранилище образов. Это удалит все локальные образы и контейнеры. Предварительно убедитесь, что у вас есть Dockerfile или известны точные теги образов для последующей загрузки.
sudo systemctl stop docker
sudo rm -rf /var/lib/docker/image
sudo systemctl start dockerПосле этого вам потребуется заново выполнить docker pull для всех необходимых образов. Для эффективного управления этим процессом в продакшене, включая политики хранения и обновления образов, изучите наше руководство по управлению Docker-образами в продакшене.
Профилактика сбоев: настройка мониторинга и регулярное обслуживание
Лучшее лечение - профилактика. Настройка мониторинга и автоматической очистки избавит от неожиданных сбоев из-за нехватки места.
Настройка алертов на нехватку места и скрипты автоматической очистки
Создайте простой скрипт для cron, который будет проверять заполненность раздела с Docker и выполнять безопасную очистку, если свободного места осталось меньше заданного порога (например, 10%).
#!/bin/bash
THRESHOLD=90
USAGE=$(df /var/lib/docker | awk 'NR==2 {print $5}' | sed 's/%//')
if [ $USAGE -gt $THRESHOLD ]; then
echo "[$(date)] Disk usage for Docker is at ${USAGE}%. Running prune." >> /var/log/docker-clean.log
docker system prune -a -f --filter "until=24h"
docker builder prune -a -f
fiЭтот скрипт удалит все остановленные контейнеры и образы, которые не использовались последние 24 часа, а также кэш сборки. Добавьте его в планировщик cron для ежедневного выполнения. Для более продвинутого мониторинга интегрируйте метрики Docker (доступные через docker system df --format='{{json .}}') в Prometheus и настройте алерты в Grafana или Alertmanager.
Чек-лист для подготовки к возможным сбоям
Подготовьте эти артефакты заранее, чтобы ускорить восстановление:
- Документация расположения данных: Знайте, где хранятся volumes (
/var/lib/docker/volumes/), образы и конфигурация демона (/etc/docker/). - Актуальные docker-compose.yml файлы: Храните их в системе контроля версий (Git). Они содержат точные спецификации ваших сервисов.
- Настроенные бэкапы volumes: Реализуйте регулярное резервное копирование каталогов volumes или используйте специализированные утилиты. Автоматизируйте этот процесс.
- Документация нестандартной конфигурации: Зафиксируйте все изменения в
/etc/docker/daemon.json, настройки драйверов хранения или сети. - Политики хранения образов в registry: Настройте автоматическое удаление старых тегов в вашем container registry (Harbor, GitLab, Nexus) чтобы предотвратить накопление.
Следование этим практикам, наряду с базовым пониманием работы Docker, которое можно получить из нашего полного практического руководства по Docker, создаст устойчивую контейнерную среду. Для комплексной проверки безопасности вашей инфраструктуры после восстановления используйте чек-лист аудита безопасности Docker и Kubernetes.
Автоматизация рутинных задач администрирования, включая мониторинг и очистку, высвобождает время для решения более сложных проблем. Для интеграции ИИ-моделей в ваши процессы разработки и администрирования рассмотрите использование агрегатора API, такого как AiTunnel, который предоставляет единый доступ к множеству моделей, включая GPT, Gemini и Claude, с удобным управлением и оплатой в рублях.