Работа с Docker на практике начинается после запуска контейнеров. Это руководство содержит все необходимые команды для повседневного управления: от просмотра всех контейнеров (docker ps) до их остановки, перезапуска и удаления. Вы научитесь оперативно отлаживать приложения, анализируя логи (docker logs) и подключаясь к работающим контейнерам для выполнения команд (docker exec). Мы подробно рассмотрим мониторинг потребления ресурсов (CPU, память, сеть) и дадим практические рекомендации для поддержания стабильной работы ваших сервисов в 2026 году.
Материал основан на проверенных практиках для современных версий Docker Engine и CLI (актуальных на 2026 год) и предназначен для системных администраторов и DevOps-инженеров, которым нужна готовая шпаргалка для ежедневной работы.
Базовые операции: ваш ежедневный набор команд для управления контейнерами
Этот раздел — ваш быстрый доступ к проверенному списку основных команд. Он решает боль «мне нужно сейчас остановить/перезапустить/посмотреть контейнер, но я не хочу искать синтаксис в документации». Все команды проверены на актуальность для 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}}\t{{.Names}}\t{{.Status}}\t{{.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.
Диагностика и отладка: как быстро найти причину проблемы в контейнере
Когда сервис не работает, нужно срочно понять почему. Методика проста: сначала анализируем логи, затем, при необходимости, инспектируем состояние внутри контейнера.
Анализ логов в реальном времени: 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.
Что проверять внутри контейнера для диагностики:
- Сеть:
cat /etc/resolv.conf(проверка DNS),netstat -tulpnилиss -tulpn(какие порты слушают). - Доступность сервиса:
curl -f http://localhost:8080/health(проверка health-check эндпоинта). - Переменные окружения:
env | grep DB_(поиск конкретных переменных). - Дисковое пространство:
df -h(использование внутри контейнера). - Процессы:
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.
Ключевые метрики и их интерпретация:
- %CPU: Процент использования ядер CPU хост-системы. Значение выше 90% для одного контейнера на протяженном интервале указывает на высокую нагрузку или возможную проблему (например, бесконечный цикл).
- MEM USAGE / LIMIT: Потребление оперативной памяти. Опасным считается стабильное приближение к LIMIT (лимиту, заданному при запуске). Если лимит не задан, контейнер может исчерпать всю память хоста.
- NET I/O: Сетевая активность. Резкий неожиданный рост может указывать на атаку или сбой в работе приложения.
- BLOCK I/O: Дисковая активность.
Анализ использования диска: образы, тома и кэш
Со временем дисковая подсистема засоряется неиспользуемыми образами, остановленными контейнерами и «висячими» (dangling) томами.
Получить детальный отчет поможет команда: Для безопасной очистки (после обязательной проверки вывода Для production-сред рекомендуется не полагаться только на Эти советы выходят за рамки отдельных команд и критически важны для поддержания порядка, безопасности и предсказуемости Docker-окружения. Основы создания безопасных образов с нуля разобраны в нашем гайде «Dockerfile 2026: безопасные образы для Python, Node.js, Go». Выходите за рамки ручного ввода команд. Простые bash-скрипты экономят время и снижают риск ошибок. Пример 1: Массовый перезапуск контейнеров по фильтру (например, все контейнеры с определенной меткой). Пример 2: Сбор логов с нескольких контейнеров за последний час в один файл. Для сложных сценариев управления множеством контейнеров на нескольких хостах рассмотрите использование систем оркестрации. Если Kubernetes кажется избыточным, отличной простой альтернативой остается Docker Swarm. Наше практическое руководство по Docker Swarm 2026 поможет вам быстро развернуть отказоустойчивый кластер. Помните, что экосистема контейнеризации постоянно развивается. Регулярно проверяйте changelog новых версий Docker Engine на предмет изменений в поведении команд и появления новых best practices. Актуальность — залог стабильной работы вашей инфраструктуры в 2026 году и позже.docker system df -v
Она покажет, сколько места занимают:
- Активные и неиспользуемые (dangling) образы
- Контейнеры (если они остановлены, но не удалены, их файловая система все еще на диске)docker system df -v!):
docker system prune: Удалит все остановленные контейнеры, все сети не используемые хотя бы одним контейнером, все «висячие» образы и весь build cache. Запрашивает подтверждение.docker volume prune: Удалит все тома, не примонтированные ни в один контейнер. Крайне важно убедиться, что в них нет нужных данных для бекапов.docker stats, а настроить полноценный мониторинг, например, через cAdvisor, собирающий метрики в Prometheus с визуализацией в Grafana. Подробности такого подхода описаны в нашем руководстве «Docker в Production: гайд по безопасному деплою, мониторингу и логированию».Рекомендации и лучшие практики для стабильной работы в 2026
Безопасность и обслуживание окружения
docker scan <image_name> (интеграция с Snyk) для проверки базовых образов и зависимостей на наличие известных CVE.--memory) и CPU (--cpus) при запуске контейнеров, особенно в production. Это предотвращает «захват» ресурсов одним сервисом. Делается через флаги командной строки или, что предпочтительнее, в docker-compose.yml.node:20-alpine -> node:20-alpine3.20) для получения исправлений безопасности.Автоматизация рутинных операций и скрипты
#!/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#!/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"