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