Services, tasks и reconciliation

После модуля вы сможете различать service, task и container, читать историю slot и объяснять, как reconciliation возвращает observed state к desired state после отказа или scale.

• создавать replicated service с явным числом replicas
• сопоставлять service slot, task ID и container
• наблюдать замену failed task
• масштабировать desired state вверх и вниз
• отличать локальный restart контейнера от создания нового task

Service — декларация желаемого приложения: image, replicas, сети, ресурсы и политики. Для replicated service orchestrator создаёт устойчивые logical slots. Каждый запуск slot представлен неизменяемым task. На назначенном node task материализуется как container.

Task не перезапускается и не переносится. После отказа orchestrator завершает его историю и создаёт новый task для того же slot. Поэтому строки с отступом в service ps — полезная история замен, а не лишние containers.

Manager сравнивает desired state сервиса с observed state tasks. Если Running replicas меньше заданного числа, scheduler выбирает подходящий node и создаёт task. При scale up появляются новые slots; при scale down лишние slots получают desired state Shutdown.

Reconciliation асинхронен. Команда изменения может завершиться раньше, чем container загрузит image и станет Running. Проверяйте convergence через service ps и service ls, учитывая Preparing, Starting, Running, Failed и Shutdown.

Scheduler учитывает availability узла, platform, constraints, reservations и распределение уже запущенных tasks. Без constraints несколько replicas могут оказаться на одном node. Один экземпляр на каждом узле здесь является наблюдаемым результатом, но не гарантией replicated mode.

В проверенной лаборатории принудительное завершение container вернуло exit 137. Старый task стал Failed, новый task того же slot перешёл в Running, а сервис сохранил 3/3 replicas.

• Работайте через manager, а локальные containers исследуйте на назначенном node
• Перед отказом зафиксируйте task ID, slot, node и container ID
• Останавливайте только container тестового сервиса по label
• После kill ищите новый task ID в том же slot
• Не удаляйте историческую строку: она объясняет причину reconciliation
• После scale дождитесь полного convergence перед следующим изменением

Создайте три replicas без публикации порта. Зафиксируйте service ID, desired replicas, распределение slots и неизменяемый image digest.

ssh swarm-manager-2 docker service create --detach=true --name swarm-m05-web --replicas 3 nginx:1.29-alpine
ssh swarm-manager-2 docker service ls
ssh swarm-manager-2 docker service ps swarm-m05-web
ssh swarm-manager-2 docker service inspect swarm-m05-web --pretty

В проверенной раскладке slot на manager-1 был единственным container сервиса. Фильтр по системному service label исключает посторонние containers. Изучите labels, связывающие container с service, task и node.

ssh swarm-manager-1 docker ps --filter label=com.docker.swarm.service.name=swarm-m05-web
ssh swarm-manager-1 docker inspect --format '{{json .Config.Labels}}' $(ssh swarm-manager-1 docker ps --quiet --filter label=com.docker.swarm.service.name=swarm-m05-web)

Завершите container тестового сервиса на manager-1. Затем наблюдайте старый Failed task с exit 137 и новый Running task того же slot. Общее число готовых replicas должно вернуться к 3/3.

ssh swarm-manager-1 docker kill $(ssh swarm-manager-1 docker ps --quiet --filter label=com.docker.swarm.service.name=swarm-m05-web)
ssh swarm-manager-2 docker service ps swarm-m05-web --no-trunc
ssh swarm-manager-2 docker service ls

Увеличьте desired state до пяти, дождитесь 5/5, затем уменьшите до двух. При scale down ожидаются Shutdown tasks: это выполненное решение orchestrator, а не авария.

ssh swarm-manager-2 docker service scale swarm-m05-web=5
ssh swarm-manager-2 docker service ps swarm-m05-web
ssh swarm-manager-2 docker service scale swarm-m05-web=2
ssh swarm-manager-2 docker service ps swarm-m05-web

Для зависших или повторно падающих tasks сопоставляйте полную ошибку service ps, service spec, локальные containers и журнал Engine.

ssh swarm-manager-2 docker service inspect swarm-m05-web
ssh swarm-manager-2 docker service ps swarm-m05-web --no-trunc
ssh swarm-manager-1 docker ps --all --filter label=com.docker.swarm.service.name=swarm-m05-web
ssh swarm-manager-1 journalctl -u docker --since today

• Чем service отличается от task и container?
• Почему failed task не перезапускается?
• Что сохраняет identity slot при замене?
• Почему распределение по одному task на node не гарантировано?
• Как различить штатный Shutdown после scale down и отказ?
• Какие состояния показывают незавершённый convergence?

Модуль освоен, если вы по service ps восстанавливаете цепочку замены, объясняете новый task ID в прежнем slot и безопасно меняете replicas вверх и вниз.

Удалите только service модуля и подтвердите отсутствие его containers и активных Swarm services.

ssh swarm-manager-2 docker service rm swarm-m05-web
ssh swarm-manager-2 docker service ls
ssh swarm-manager-2 docker node ls