Створення кластера та життєвий цикл вузлів

Після модуля ви зможете пояснити bootstrap Swarm, ролі join token і node certificate, безпечно вивести follower manager, видалити його membership та повернути з новим node ID без втрати quorum.

• init створює перший manager і кореневий стан Swarm
• join token підтверджує роль під час приєднання, але не замінює node certificate
• advertise address задає адресу control plane вузла
• data-path address задає transport overlay
• повторний join створює нову identity та новий node ID

docker swarm init створює новий cluster identity, локальний manager і Raft state. Параметр advertise-addr має бути досяжним усім nodes; default address pool планують до створення overlay networks. Додаткові вузли отримують роль worker або manager під час join.

Join token є чутливим bootstrap credential. Після join вузол використовує взаємну TLS-автентифікацію й автоматично оновлюваний node certificate. Token можна ротувати без перепідключення наявних nodes.

Hostname допомагає оператору, але identity задають node ID і сертифікат. Після leave/remove/rejoin той самий hostname отримує новий ID. Старі Down-записи не слід плутати з поточним вузлом або видаляти до з’ясування причини.

• Ready описує зв’язок і стан node
• Active, Pause та Drain керують прийманням нових tasks
• Manager Status показує Leader, Reachable або Unreachable
• demote видаляє manager з Raft membership
• node rm видаляє membership-запис, але не очищає віддалений Engine

Спочатку підтверджують три здорові manager та обирають follower. Потім demote зменшує Raft membership із трьох до двох, але обидва manager, що залишилися, мають бути доступні. Після demote вузол виходить уже як worker, а manager видаляє його запис.

leave --force на manager і force-new-cluster є аварійними інструментами. Вони не замінюють demote та перевірку quorum. Одночасно змінюють лише один manager.

• Зафіксуйте leader та обирайте follower
• Не друкуйте join token і не зберігайте його у файл чи shell history
• Перед demote перевірте доступність двох manager, що залишаються
• Після кожного кроку виконуйте node ls
• Не застосовуйте node rm --force до доступного вузла
• Після rejoin порівняйте старий і новий node ID та дочекайтеся Ready/Reachable

Перевірте membership і локальний стан manager‑1 та manager‑2. Переконайтеся, що manager‑2 не є leader і всі три nodes Ready.

ssh swarm-manager-1 docker node ls
ssh swarm-manager-1 docker node inspect swarm-manager-2 --pretty
ssh swarm-manager-1 docker info
ssh swarm-manager-2 docker info

Виведіть лише manager‑2. Demote виконується через manager‑1, leave — локально на manager‑2, remove — знову через manager‑1.

ssh swarm-manager-1 docker node demote swarm-manager-2
ssh swarm-manager-2 docker swarm leave
ssh swarm-manager-1 docker node rm swarm-manager-2
ssh swarm-manager-1 docker node ls

Після кроку залишаються два manager з quorum. Не продовжуйте, якщо один із них Unreachable.

Token передається через pipe у stdin віддаленої shell, не з’являється у виводі й аргументах join на devops-vm. Вузол використовує стабільні control і data-path адреси cluster0.

ssh swarm-manager-1 docker swarm join-token -q manager | ssh swarm-manager-2 'read -r token; docker swarm join --token "$token" --advertise-addr 10.77.0.12 --data-path-addr 10.77.0.12 10.77.0.11:2377'
ssh swarm-manager-1 docker node ls
ssh swarm-manager-1 docker node inspect swarm-manager-2 --pretty

Очікується новий node ID, Status Ready та Manager Status Reachable. Leader може залишатися на будь-якому з двох інших nodes.

Помилка про manager leave без --force захищає Raft membership. Помилка видалення manager вимагає спочатку demote. За завислого join розділіть доступність TCP 2377, локальний стан Engine, сертифікати й наявну membership.

ssh swarm-manager-1 docker node ls
ssh swarm-manager-1 docker node inspect swarm-manager-2
ssh swarm-manager-2 docker info
ssh swarm-manager-2 journalctl -u docker --since today
ssh swarm-manager-2 ss -lntup
ssh swarm-manager-2 ping -c 2 10.77.0.11

• This node is already part of a swarm — спочатку inspect локальний стан
• context deadline exceeded — перевіряйте маршрут і TCP 2377
• node залишається Down — порівняйте ID та видаліть лише підтверджено старий запис
• Unreachable manager після join — перевірте advertise address і міжвузлові 2377/7946

• Чим join token відрізняється від node certificate?
• Чому hostname не є identity?
• Навіщо demote виконують до leave?
• Коли припустимий node rm --force?
• Чому не можна друкувати manager token?
• Які адреси задають advertise-addr і data-path-addr?

Модуль засвоєно, якщо ви повертаєте follower manager з новим ID, зберігаєте quorum на кожному кроці та можете пояснити кожен Docker guardrail.

Cleanup не видаляє кластер: відновіть три Ready manager, переконайтеся у відсутності тестових services і не залишайте token-файли.

ssh swarm-manager-1 docker node ls
ssh swarm-manager-1 docker service ls
ssh swarm-manager-2 docker info