Stacks і декларативне розгортання

Після модуля ви зможете описувати multi-service застосунок декларативно, валідувати manifest, повторно застосовувати зміни та видаляти весь stack як одиницю керування.

• пояснювати зв’язок stack, services, networks і configs
• відрізняти docker compose від docker stack deploy
• читати імена ресурсів із префіксом stack
• виконувати ідемпотентний повторний deploy

Stack — іменований набір Swarm services, networks, configs і secrets, створений із Compose-подібного manifest. Stack не є окремим runtime-об’єктом: docker stack ls агрегує ресурси за namespace labels.

Ім’я swarm-m07 перетворює web на swarm-m07_web, а app — на swarm-m07_app. Цей namespace дозволяє керувати пов’язаними ресурсами, але потребує унікальних stack names.

docker compose керує containers одного Engine. docker stack deploy надсилає Swarm service specs manager. Секція deploy має сенс для Swarm: replicas, update_config, rollback_config, placement і resources.

Stack deploy не будує image з build і не реалізує всі можливості сучасної Compose Specification. Для кластера публікують image у registry та вказують доступний усім nodes immutable reference.

Повторний deploy обчислює відмінності manifest і поточних service specs. Незмінені ресурси зберігаються, змінені приводяться до нового desired state.

Прапорець --detach=false чекає convergence. Перед deploy команда stack config нормалізує й перевіряє manifest без зміни кластера.

• Зберігайте manifest на керівній машині під контролем версій, але не secrets
• Перед зміною виконуйте stack config
• Використовуйте фіксований stack name
• Перевіряйте stack services і stack ps після кожного deploy
• Не застосовуйте docker compose up як заміну orchestrator
• Cleanup починайте зі stack rm і дочекайтеся видалення overlay network

Створіть тимчасовий manifest на devops-vm. Команда printf формує два сервіси та overlay network; потім файл копіюється лише на manager-2.

mkdir -p /tmp/swarm-m07
printf '%s
' 'services:' '  web:' '    image: nginx:1.29-alpine' '    deploy:' '      replicas: 2' '      update_config:' '        parallelism: 1' '    networks: [app]' '  probe:' '    image: alpine:3.22' '    command: ["sleep", "3600"]' '    networks: [app]' 'networks:' '  app:' '    driver: overlay' > /tmp/swarm-m07/stack.yaml
scp /tmp/swarm-m07/stack.yaml swarm-manager-2:/tmp/swarm-m07-stack.yaml

Спочатку виведіть нормалізовану модель, потім розгорніть stack. Очікуються web 2/2, probe 1/1 і мережа swarm-m07_app зі scope swarm.

ssh swarm-manager-2 docker stack config --compose-file /tmp/swarm-m07-stack.yaml
ssh swarm-manager-2 docker stack deploy --detach=false --compose-file /tmp/swarm-m07-stack.yaml swarm-m07
ssh swarm-manager-2 docker stack ls
ssh swarm-manager-2 docker stack services swarm-m07
ssh swarm-manager-2 docker stack ps swarm-m07
ssh swarm-manager-2 docker network ls --filter name=swarm-m07

Змініть кількість web replicas із двох до трьох і застосуйте те саме stack name. Сервіси зберігають identity, а orchestrator створює лише відсутній slot.

sed -i 's/replicas: 2/replicas: 3/' /tmp/swarm-m07/stack.yaml
scp /tmp/swarm-m07/stack.yaml swarm-manager-2:/tmp/swarm-m07-stack.yaml
ssh swarm-manager-2 docker stack deploy --detach=false --compose-file /tmp/swarm-m07-stack.yaml swarm-m07
ssh swarm-manager-2 docker stack services swarm-m07
ssh swarm-manager-2 docker stack ps swarm-m07

Помилки розділяйте на parsing manifest, створення service spec, image pull і runtime task. stack ps --no-trunc пов’язує помилку з node та task history.

ssh swarm-manager-2 docker stack config --compose-file /tmp/swarm-m07-stack.yaml
ssh swarm-manager-2 docker stack ps swarm-m07 --no-trunc
ssh swarm-manager-2 docker service inspect swarm-m07_web --pretty
ssh swarm-manager-2 docker service logs swarm-m07_web

• unsupported option — перевірте підтримку поля stack deploy
• No such image — образ має бути доступний кожному призначеному node
• Pending — досліджуйте placement і resources
• мережа не видаляється одразу — дочекайтеся завершення tasks

• Чи є stack окремим runtime-об’єктом?
• Як формуються імена ресурсів?
• Чому build непридатний для stack deploy?
• Що перевіряє stack config?
• Чому повторний deploy зберігає service ID?
• Чим stack rm відрізняється від видалення одного service?

Модуль засвоєно, якщо ви валідуєте manifest, розгортаєте два сервіси, змінюєте replicas повторним deploy і підтверджуєте повний cleanup.

ssh swarm-manager-2 docker stack rm swarm-m07
ssh swarm-manager-2 docker stack ls
ssh swarm-manager-2 docker service ls
ssh swarm-manager-2 docker network ls --filter name=swarm-m07
ssh swarm-manager-2 rm -f /tmp/swarm-m07-stack.yaml
rm -f /tmp/swarm-m07/stack.yaml
rmdir /tmp/swarm-m07