Управление запущенными контейнерами Docker в 2026: полная шпаргалка команд, отладки и мониторинга

Эта шпаргалка отвечает на один практический вопрос: что делать с уже запущенным контейнером. Посмотреть состояние, остановить или перезапустить, прочитать логи, зайти внутрь, ограничить память и CPU, освободить диск. Все примеры — штатный docker CLI (Docker Engine 24 и новее); если поведение команды зависит от версии Engine или отдельного плагина, это отмечено в тексте.

Что изменилось к 2026 году: команда docker scan (интеграция со Snyk) больше не развивается — проверка уязвимостей перешла к плагину docker scout и внешним сканерам (Trivy, Grype). Команда docker system df -v остаётся основным способом понять, куда ушло место, а фильтры --filter по status, name и label стали стандартом для скриптов автоматизации.

Гайд основан на проверенных best practices для современных версий Docker Engine и CLI и предназначен для системных администраторов и DevOps-инженеров, которым нужна точная, рабочая информация для поддержания стабильности, безопасности и эффективности сервисов.

Быстрые ответы: что делать прямо сейчас

• Контейнер упал — нужна причина: начните с docker ps -a и docker logs --tail 50; полный порядок разбора — в чек-листе «Сервис упал: 5 шагов».
• Нужны логи в реальном времени: docker logs -f --tail 20 <container>.
• Нужно залезть внутрь контейнера: docker exec -it <container> /bin/bash, для образов на Alpine Linux — /bin/sh.
• Контейнер съедает память или CPU: docker stats --no-stream, затем лимиты --memory и --cpus при запуске.
• Закончилось место на диске: docker system df -v, затем docker system prune; ключи -a и --volumes — только после проверки, что именно удаляется.
• Нужно проверить образы на CVE: docker scout cves <image> или внешние сканеры Trivy и Grype.

Базовые операции: ваш ежедневный набор команд для управления контейнерами

Этот раздел — быстрый доступ к проверенному списку основных команд. Он решает боль «мне нужно сейчас остановить/перезапустить/посмотреть контейнер, но я не хочу искать синтаксис в документации». Все команды актуальны для Docker версий 2026 года.

Просмотр и идентификация: docker ps и не только

Первое, что нужно сделать — сориентироваться, что запущено. Основная команда — docker ps. По умолчанию она показывает только запущенные контейнеры. Ключевые флаги, которые стоит знать:

• docker ps -a или docker ps --all: показать все контейнеры, включая остановленные. Незаменимо для аудита.
• docker ps -q или docker ps --quiet: вывести только числовые ID контейнеров. Идеально для скриптов, например для массовой остановки: docker stop $(docker ps -q).
• docker ps --filter "status=exited": фильтрация по статусу. Другие значения: running, paused, created.
• docker ps --filter "name=nginx": найти контейнер по имени или его части.
• docker ps --format "table {{.ID}} {{.Names}} {{.Status}} {{.Ports}}": полный контроль над выводом — можно выводить только нужные поля.

Пример поиска всех контейнеров с меткой (label) environment=production:
docker ps --filter "label=environment=production"

Контроль жизненного цикла: stop, restart, rm

Безопасное управление состоянием контейнеров критически важно, чтобы избежать потери данных или неожиданных простоев.

• Остановка: docker stop <container_id_or_name> отправляет сигнал SIGTERM, позволяя приложению корректно завершить работу. Если контейнер не останавливается за 10 секунд (по умолчанию), отправляется SIGKILL. Для немедленной остановки используйте docker kill <container_id_or_name> (SIGKILL).
• Перезапуск: docker restart <container_id_or_name> выполняет последовательность stop и затем start. Полезно для применения изменений в конфигурации, загружаемой при старте.
• Удаление: docker rm <container_id_or_name> удаляет остановленный контейнер. Критически важный флаг -v (или --volumes): удаляет анонимные тома, связанные с контейнером. Без него тома остаются в системе, занимая место.
  Пример безопасного удаления: docker rm -v my_old_container.

Для массовой очистки всех остановленных контейнеров используйте встроенную команду:
docker container prune
Перед выполнением она запросит подтверждение. Это безопаснее, чем ручной цикл с docker rm.

Диагностика и отладка: как быстро найти причину проблемы в контейнере

Когда сервис не работает, нужно срочно понять почему. Методика проста: сначала анализируем логи, затем, при необходимости, инспектируем состояние внутри контейнера.

Сервис упал: 5 шагов

1. Статус. docker ps -a --filter "name=<service>" — ищем status=exited или Restarting.
2. Последние логи. docker logs --tail 100 <container> — последняя ошибка перед падением обычно здесь.
3. Код выхода и признак OOM. docker inspect --format '{{.State.ExitCode}} {{.State.OOMKilled}}' <container>. Код 137 — процесс убит сигналом SIGKILL (частая причина — нехватка памяти), 143 — корректная остановка по SIGTERM.
4. Конфигурация. docker inspect --format '{{.HostConfig.RestartPolicy.Name}} {{.HostConfig.Memory}}' <container> — заданы ли лимиты и политика перезапуска.
5. Ресурсы хоста. docker stats --no-stream и dmesg | grep -i oom — не забрал ли контейнер память всего узла.

Анализ логов в реальном времени: docker logs и tail

Основной инструмент — docker logs. Вот практические примеры для ежедневного использования:

• docker logs -f <container>: ключ -f (follow) выводит логи в реальном времени, аналогично tail -f.
• docker logs --tail 50 <container>: показать только последние 50 строк. Не заваливает терминал историей.
• Комбинация для эффективной отладки: docker logs -f --tail 20 <container>. Вы увидите последние 20 строк и будете следить за новыми.
• docker logs --since 10m <container>: показать логи только за последние 10 минут. Можно использовать 1h и абсолютные метки времени, например 2026-04-02T10:00:00.
• docker logs <container> 2>&1 | grep -i error: перенаправление stderr в stdout и поиск ошибок.

Для сохранения логов в файл:
docker logs <container> > container_logs_$(date +%Y%m%d).txt 2>&1

Внутренняя инспекция: подключение и выполнение команд через docker exec

Если логи не дали ответа, нужно «залезть внутрь» контейнера. Стандартная команда для входа в интерактивную оболочку:
docker exec -it <container_id_or_name> /bin/bash
Если Bash отсутствует (например, в образах на основе Alpine Linux), используйте /bin/sh.

Что проверять внутри контейнера для диагностики:

1. Сеть: cat /etc/resolv.conf (проверка DNS), netstat -tulpn или ss -tulpn (какие порты слушают).
2. Доступность сервиса: curl -f http://localhost:8080/health (проверка health-check эндпоинта).
3. Переменные окружения: env | grep DB_ (поиск конкретных переменных).
4. Дисковое пространство: df -h (использование внутри контейнера).
5. Процессы: ps aux (проверка запущенных процессов и их потребления ресурсов).

Важное предупреждение: docker exec — инструмент для отладки. Постоянная работа внутри контейнера через exec противоречит принципам неизменяемости инфраструктуры. Все изменения, сделанные таким образом, будут потеряны при пересоздании контейнеров.

Для более глубокого погружения в безопасность и оптимизацию Docker-сред рекомендуем наш гайд «Продвинутый Docker в 2026: безопасность, сети и тонкая оптимизация».

Мониторинг потребления ресурсов: CPU, память, сеть и диск

Контроль за ресурсами предотвращает проблемы, вызванные утечками памяти или избыточной нагрузкой. Встроенный инструмент Docker даёт хорошее представление о текущем состоянии.

Использование docker stats для оперативного контроля

Команда docker stats в реальном времени показывает потребление ресурсов всеми запущенными контейнерами.

• Интерактивный режим: просто выполните docker stats. Вывод обновляется каждую секунду.
• Одноразовый снимок состояния: docker stats --no-stream.
• Мониторинг конкретных контейнеров: docker stats nginx_container redis_cache.
• Только нужные поля: docker stats --no-stream --format "table {{.Name}}\t{{.MemUsage}}\t{{.MemPerc}}" — удобно вызывать из cron и отправлять результат в систему алертинга.

Пример вывода docker stats и как его читать:

CONTAINER ID   NAME      CPU %     MEM USAGE / LIMIT     MEM %     NET I/O           BLOCK I/O
a1b2c3d4e5f6   web_app   2.14%     412MiB / 512MiB       80.47%    1.24GB / 890MB    12MB / 4MB
9f8e7d6c5b4a   redis     0.31%     96MiB / 256MiB        37.50%    340MB / 213MB     0B / 0B
c7d8e9f0a1b2   worker    188.40%   1.82GiB / 2GiB        91.00%    56MB / 12MB       1.1GB / 640MB

Как быстро выявить утечку памяти: смотрите не на абсолютное значение MEM USAGE, а на отношение к LIMIT — колонку MEM %. Если у контейнера без всплесков нагрузки MEM % растёт от снимка к снимку и приближается к 100, память утекает; при достижении лимита ядро убьёт процесс (OOMKilled, код выхода 137). Если в колонке LIMIT указан объём всей памяти хоста, лимит не задан — одна утечка уронит не только сервис, но и узел.

Ключевые метрики и их интерпретация:

• %CPU: процент использования ядер CPU хост-системы. Значение выше 90% для одного контейнера на протяжённом интервале указывает на высокую нагрузку или возможную проблему (например, бесконечный цикл).
• MEM USAGE / LIMIT: потребление оперативной памяти. Опасным считается стабильное приближение к LIMIT (лимиту, заданному при запуске). Если лимит не задан, контейнер может исчерпать всю память хоста.
• NET I/O: сетевая активность. Резкий неожиданный рост может указывать на атаку или сбой в работе приложения.
• BLOCK I/O: дисковая активность.

Анализ использования диска: образы, тома и кэш

Со временем дисковая подсистема засоряется неиспользуемыми образами, остановленными контейнерами и «висячими» (dangling) томами.

Получить детальный отчёт поможет команда:
docker system df -v
Она покажет, сколько места занимают:
- активные и неиспользуемые (dangling) образы;
- контейнеры (если они остановлены, но не удалены, их файловая система всё ещё на диске);
- локальные тома;
- build cache.

Очистка диска: безопасные и опасные команды

Команды очистки стоит разделять по уровню риска. Разница между docker image prune и docker system prune -a --volumes — это разница между «освободить пару гигабайт» и «потерять данные»:

Предупреждение. docker system prune -a --volumes — самая опасная команда в списке: она удаляет образы и тома, которые на момент запуска не примонтированы, и восстановить их из локального кэша не получится. Перед любой очисткой смотрите вывод docker system df -v и список томов (docker volume ls), убеждайтесь, что бекапы данных актуальны, и только затем запускайте prune.

Для production-сред рекомендуется не полагаться только на docker stats, а настроить полноценный мониторинг, например через cAdvisor, собирающий метрики в Prometheus с визуализацией в Grafana. Подробности такого подхода описаны в нашем руководстве «Docker в Production: гайд по безопасному деплою, мониторингу и логированию».

Рекомендации и лучшие практики для стабильной работы в 2026

Эти советы выходят за рамки отдельных команд и критически важны для поддержания порядка, безопасности и предсказуемости Docker-окружения.

Безопасность и обслуживание окружения

• Сканирование образов на уязвимости: docker scan (интеграция со Snyk) больше не развивается, поэтому проверяйте образы плагином docker scout cves <image_name> или внешними сканерами Trivy и Grype. Сканируйте базовые образы и зависимости при каждом обновлении — это дешевле, чем разбираться с CVE в production.
• Ограничение ресурсов: всегда задавайте лимиты памяти (--memory) и CPU (--cpus) при запуске контейнеров, особенно в production. Это предотвращает «захват» ресурсов одним сервисом. Делается через флаги командной строки или, что предпочтительнее, в docker-compose.yml.
• Обновление базовых образов: включите в CI/CD-процесс регулярное обновление базовых образов, например переход с node:20-alpine на актуальный LTS-тег node:22-alpine. Список существующих тегов проверяйте на странице образа в Docker Hub, а для воспроизводимых сборок закрепляйте digest: FROM node:22-alpine@sha256:....
• Резервное копирование томов с данными: данные в томах — ваша ответственность. Настройте регулярный бэкап, например останавливая контейнер и архивируя директорию тома на хосте, и периодически проверяйте восстановление из копии.

Основы создания безопасных образов с нуля разобраны в нашем гайде «Dockerfile 2026: безопасные образы для Python, Node.js, Go».

Автоматизация рутинных операций и скрипты

Выходите за рамки ручного ввода команд. Простые bash-скрипты экономят время и снижают риск ошибки.

Пример 1: массовый перезапуск контейнеров по фильтру (например, все контейнеры с определённой меткой).

#!/bin/bash
# restart_services.sh
for container_id in $(docker ps -q --filter "label=com.example.service=true"); do
    echo "Restarting container: $(docker inspect --format '{{.Name}}' $container_id)"
    docker restart $container_id
    sleep 5 # Небольшая пауза между перезапусками

done

Пример 2: сбор логов с нескольких контейнеров за последний час в один файл.

#!/bin/bash
# gather_logs.sh
LOG_FILE="combined_logs_$(date +%Y%m%d_%H%M).log"
echo "--- Logs collected at $(date) ---" > $LOG_FILE
for container_name in web_app database cache; do
    if docker ps --format "{{.Names}}" | grep -q "^${container_name}$"; then
        echo "\n=== Logs from $container_name ===" >> $LOG_FILE
        docker logs --since 1h $container_name 2>&1 | head -100 >> $LOG_FILE
    fi
done
echo "Logs saved to $LOG_FILE"

Для сложных сценариев управления множеством контейнеров на нескольких хостах рассмотрите системы оркестрации. Если Kubernetes кажется избыточным, простой альтернативой остаётся Docker Swarm. Наше практическое руководство по Docker Swarm 2026 поможет быстро развернуть отказоустойчивый кластер.

Чек-лист действий на сегодня:

1. Проверить состояние всех контейнеров: docker ps -a
2. Оценить использование диска: docker system df -v
3. Настроить лимиты памяти для production-контейнеров через docker-compose.yml или флаги --memory.
4. Просканировать базовые образы на уязвимости: docker scout cves <your_image> (или trivy image <your_image>).
5. Создать скрипт для автоматического сбора логов по шаблону из примера выше.

Помните, что экосистема контейнеризации постоянно развивается. Регулярно проверяйте changelog новых версий Docker Engine на предмет изменений в поведении команд и появления новых best practices. Актуальность — залог стабильной работы вашей инфраструктуры в 2026 году и позже.