List Issues Suggestions1 Discussions Insights

🧙 Садовник: уточнил шаги, добавил проверки и обоснования. Примите, если полезно.

open+2−8⇅4proposed by devops · Aug 14, 2026 · based on v1

Conversation Checks Proposed changes14 Result

Result · becomes v2

•

Проверить актуальную версию Docker

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

Why: Актуальная версия Docker обеспечивает поддержку всех новых функций и исправлений.

code

1docker --version

•

Понять, что управляется Swarm, а что нет

Сначала смотрим сервисы кластера:

bash

1docker stack ls # список стеков

2docker service ls # сервисы и их реплики

3docker node ls # узлы кластера

Потом — все контейнеры на машине:

bash

1docker ps

У контейнеров Swarm имена вида стек_сервис.1.длинныйидентификатор. У обычных — простые, из compose-файла. Это самый быстрый способ их различить.

Why: Пока не разделишь эти два мира в голове, любая отладка превращается в гадание: останавливаешь контейнер, а он поднимается снова — потому что это сервис Swarm, и кластер честно восстанавливает заданное число реплик.

code

1docker service ls

–Ты можешь назвать, какие контейнеры на машине от Swarm, а какие нет
–Понимаешь, почему остановленный контейнер Swarm поднимается сам

Docker Swarm — обзор Управление сервисами

•

Остановить дублирующие контейнеры

Когда сервис уже живёт в Swarm, старый контейнер надо гасить тем же инструментом, которым поднимали:

bash

1# если поднимали через compose

2docker compose -f путь/к/docker-compose.yml down

4# если вручную

5docker stop имя && docker rm имя

Не пытайся гасить через docker stop контейнер Swarm-сервиса — кластер тут же создаст новый. Нужно docker service scale имя=0 или docker stack rm.

Why: Два комплекта одних и тех же сервисов — это не только двойной расход памяти. Это ещё и два приложения, пишущих в одну базу, и два планировщика, выполняющих одни и те же фоновые задачи.

code

1docker ps --format "{{.Names}}"

–Каждый сервис запущен ровно один раз
–Старые compose-контейнеры остановлены тем же инструментом, которым поднимались

•

Проверить состояние сервисов после остановки

После остановки дублирующих контейнеров убедитесь, что все сервисы работают корректно.

Why: Проверка состояния сервисов предотвращает возможные ошибки в работе приложений.

code

1docker service ls

–Все сервисы в состоянии RUNNING
–Нет остановленных или неработающих сервисов

•

Развернуть стек

bash

1docker stack deploy -c docker-compose.yml имя-стека

Тот же файл, что и для compose, но часть полей работает иначе:

раздел deploy читается только в Swarm, compose его игнорирует;
build в Swarm не работает — образ должен быть уже собран и доступен всем узлам;
depends_on игнорируется — порядок запуска не гарантируется.

Why: Последние два пункта ловят почти всех. Локально собранный образ есть только на одном узле — на остальных сервис просто не запустится, и ошибка будет про отсутствующий образ, а не про сборку.

code

1docker stack deploy -c docker-compose.yml myapp

–Стек виден в docker stack ls
–Все сервисы в состоянии N/N

Развёртывание стека

•

Понять, почему сервис не поднимается

Если docker service ls показывает 0/1, смотри историю задач:

bash

1docker service ps имя-сервиса --no-trunc

Колонка CURRENT STATE и ERROR обычно говорят всё. Типичные состояния:

Rejected — узел отказался: нет образа, не сошлись ограничения размещения, нет ресурсов
Failed — контейнер запустился и упал с ненулевым кодом
Complete — контейнер вышел с кодом 0. При restart_policy: on-failure кластер его НЕ поднимет, и сервис так и останется 0/1

Логи сервиса целиком: docker service logs имя --tail 50

Why: Состояние `Complete` сбивает с толку сильнее всего: выглядит как успех, а сервис лежит. Зная эти три слова, ты сэкономишь часы.

code

1docker service ps имя-сервиса --no-trunc

–Ты знаешь, чем отличаются Rejected, Failed и Complete
–Умеешь смотреть логи сервиса, а не контейнера