Логи Docker Swarm: service, task и stack deploy

Автор: Казачкин Даниил Михайлович · Обновлено 29 сентября 2026 г.

Команда docker stack deploy относится к Swarm, а docker compose up — к другому способу управления приложением. Поэтому поиск «docker stack deploy logs» не приводит к команде docker stack logs: такой команды нет. Нужно определить сервис стека, его задачи и уже затем читать нужный журнал.

Три уровня наблюдения

Stack объединяет сервисы. Service описывает желаемые экземпляры, а task представляет конкретную задачу, для которой Swarm создаёт контейнер на выбранном узле. Если экземпляр перезапустился на другой машине, журнал одного локального контейнера не описывает всю историю сервиса. Имя сервиса обычно включает имя stack, но его нужно получить из системы, а не угадывать.

Для существующего учебного Swarm выполняйте на manager:

docker stack ls
docker stack services demo
docker stack ps --no-trunc demo
docker service ps --no-trunc demo_web
docker service logs --tail 100 --timestamps demo_web

demo и demo_web здесь обозначают реальные имена вашего стенда. Команды чтения не создают Swarm и не разворачивают новое приложение. Если машина не manager, ошибка доступа к управлению ожидаема; запускать swarm init на рабочем хосте ради просмотра логов не требуется. Команда service logs.

Ошибка до появления процесса

Задача может быть отклонена ещё до старта контейнера: образ недоступен, нет credentials registry, не хватает ресурсов или задан неподходящий mount. Тогда stdout приложения пуст по естественной причине. docker service ps --no-trunc показывает состояние и подробность ошибки задачи; docker stack ps помогает увидеть распределение всего стека. Справка service ps.

Если task уже работает, docker service logs --since 15m --follow demo_web собирает новые сообщения сервиса. Можно передать ID отдельной task для сужения области. Не удаляйте префиксы task/node, пока не выяснили, на каком экземпляре возникла проблема. В нескольких репликах одинаковое сообщение не обязательно означает повтор одной операции.

Проверить драйвер и узел

Официально docker service logs работает для сервисов с json-file или journald. Нельзя обещать такой же результат с любым удалённым logging driver. Если проект отправляет события во внешнее хранилище, используйте его способ поиска и идентификаторы задач. Ограничение драйверов.

Локальный docker logs CONTAINER обращается к контейнеру на daemon выбранного context. Он полезен на конкретном узле, но не заменяет сбор по кластеру. При диагностике запишите manager, task ID, node и интервал времени, чтобы коллега мог повторить наблюдение.

Отличить от Compose

Если проект поднят через docker compose up, используйте docker compose logs, даже если YAML содержит слово services. В нём «сервис» не означает объект Docker Swarm. По docker compose ls и docker stack ls можно понять, каким инструментом создано приложение. Это первый шаг перед выбором команды, а не повод мигрировать проект в Swarm.

Учебный сценарий разбора

Представьте таблицу: task A отклонена из-за отсутствующего образа, task B запустилась и завершилась с кодом 1, task C продолжает обслуживать запросы. Для A ищите причину в состоянии задачи и доступе registry; для B — в её выводе и exit code; для C — в запросах, метриках и health. Запишите по одной следующей команде для каждой. Если нужен реальный кластерный эксперимент, создайте отдельные виртуальные узлы и проверяйте на них, не меняя режим действующего Docker host. Результат урока — правильный выбор уровня диагностики, а не развёртывание кластера за одну команду.