Docker Swarm: кластер з кількох нод на VPS

Docker Swarm: кластер з кількох нод

Основна серія «Docker на VPS» закінчилась логічним натяком: усе, що ми будували - від першого контейнера до self-hosted Git зі своїм CI - працювало на одному сервері. Один сервер означає одну точку відмови: якщо VPS падає, падає весь стек одночасно, незалежно від того, скільки restart: unless-stopped прописано в compose-файлі.

Docker Swarm - вбудований у Docker Engine оркестратор, який вирішує саме цю задачу: розподіляє сервіси між кількома нодами і сам стежить, щоб бажана кількість реплік була запущена, навіть якщо одна з нод відмовила. Ключова відмінність від усього, що ми робили досі, - жодних зовнішніх залежностей. Не потрібно встановлювати Kubernetes, etcd чи окремий control plane: кластер піднімається однією командою docker swarm init на тому ж Docker Engine, який уже стоїть на сервері з першої статті серії.

Swarm виправданий у конкретній ніші: кластер з 2-10 нод, команда без досвіду Kubernetes, інфраструктура на VPS чи bare-metal без хмарного провайдера з готовим managed-кластером. За межами цієї ніші - великі кластери, складні stateful-навантаження, потреба в autoscaling - розмова вже про Kubernetes, але це тема для іншої розмови.

Ця міні-серія складається з двох статей. Перша - про сам кластер: ноди, сервіси, overlay-мережі, rolling update без даунтайму. Друга - про те, що потрібно для реального використання: secrets і configs замість .env у відкритому вигляді, docker stack deploy для розгортання compose-файлів цілим стеком, і Portainer як графічний інтерфейс поверх усього цього.

2. Swarm vs standalone Docker Compose

У статтях 1-5 основної серії Docker Compose керував контейнерами на одному хості. Там не було ні failover, ні розподілу навантаження між серверами - якщо хост падав, падали всі сервіси одночасно, і підняти їх можна було тільки на ньому ж, після того як він знову став доступний.

Swarm не вимагає переписувати все з нуля. Ті самі принципи compose-файлу - сервіси, мережі, volumes - переносяться майже без змін; відмінність у команді розгортання: замість docker compose up -d використовується docker stack deploy, яка розподіляє сервіси між нодами кластера, а не піднімає їх усі на одному хості.

Головна концептуальна відмінність - у тому, що саме Docker тримає під контролем. У звичайному Compose базова одиниця - контейнер: конкретний запущений процес на конкретному хості. У Swarm базова одиниця - сервіс: декларація бажаного стану на кшталт «тримай 3 репліки образу X запущеними, незалежно від того, на яких нодах». Контейнер - це факт, сервіс - це намір, який Swarm підтримує сам, перезапускаючи репліки там, де це можливо, якщо щось пішло не так.

3. Ключові концепції

3.1 Node

Node - фізична чи віртуальна машина, що входить до складу кластера. Кожна нода має одну з двох ролей: manager або worker.

3.2 Manager

Manager зберігає стан усього кластера у вигляді Raft-логу, приймає команди управління (docker service create, docker stack deploy) і планує, на яких нодах запускати задачі. Мінімум - одна manager-нода; для відмовостійкості самого управління кластером потрібна непарна кількість - 1, 3 або 5.

3.3 Worker

Worker виконує задачі (tasks), призначені manager-нодами, але сам не приймає команди управління кластером. Проста топологія - manager-нода теж може виконувати робочі навантаження одночасно з управлінням, але для production-кластерів із кількома нодами manager зазвичай розвантажують від прикладних сервісів.

3.4 Service

Service - це бажаний стан: «тримай N реплік образу X запущеними і доступними на порту Y». Swarm самостійно підтримує цей стан у часі - якщо репліка впала, він перезапускає нову замість неї, не чекаючи втручання людини.

3.5 Task

Task - один конкретний екземпляр сервісу на конкретній ноді, фактично еквівалент одного контейнера. Якщо сервіс має 3 репліки, у кластера одночасно є 3 задачі, можливо розкидані по різних нодах.

3.6 Overlay network

Overlay-мережа - віртуальна L2-мережа поверх L3-з'єднання між нодами кластера. Сервіси, під'єднані до тієї самої overlay-мережі, бачать одне одного за іменем сервіса незалежно від того, на якій фізичній ноді кожен із них насправді запущений - так само, як сервіси Compose бачили одне одного за іменем у межах одного хоста в статті 2 основної серії.

3.7 Raft consensus

Manager-ноди узгоджують стан кластера між собою через алгоритм Raft consensus. Кворум - мінімальна кількість manager-нод, які мають лишатись онлайн, щоб кластер продовжував приймати рішення, - розраховується як (N/2)+1. Для 3 manager-нод кворум становить 2: кластер витримує відмову однієї manager-ноди і продовжує працювати.

4. Вимоги і підготовка

4.1 Мінімальна топологія

Для першого знайомства достатньо двох віртуальних машин із встановленим Docker Engine за інструкцією зі статті 1 основної серії: одна стає manager, друга - worker.

4.2 Порти між нодами

Для роботи кластера між усіма нодами мають бути відкриті три порти:

4.3 Єдина версія Docker Engine

На кожній ноді має стояти той самий Docker Engine, встановлений офіційним скриптом - без Docker Desktop (він не призначений для серверів, про що йшлося в першій статті серії) і без розбіжностей у версії Compose-плагіна між нодами. Розбіжність версій Engine між manager і worker - рідкісна, але реальна причина дивної поведінки кластера, яку складно діагностувати post factum.

5. Ініціалізація кластера

5.1 Перша нода стає manager

docker swarm init --advertise-addr <IP_manager_ноди>

Прапор --advertise-addr вказує, яку саме IP-адресу інші ноди мають використовувати для з'єднання з цим manager - важливо вказати явно, якщо сервер має кілька мережевих інтерфейсів, щоб кластер не намагався спілкуватись через приватну адресу, недоступну ззовні, або навпаки.

5.2 Токени приєднання

Після виконання команди Docker одразу виводить два токени - для приєднання worker-нод і для приєднання додаткових manager-нод. Токени - це довгі рядки, що діють як пароль приєднання до кластера; зберігати їх варто так само обережно, як SSH-ключі деплою зі статті 4 основної серії.

5.3 Отримати токен пізніше

Якщо термінал із виводом команди вже закрито, токени можна отримати повторно в будь-який момент:

docker swarm join-token worker
docker swarm join-token manager

6. Додавання нод

6.1 Приєднання worker-ноди

На кожній новій ноді, яку потрібно додати як worker:

docker swarm join --token <worker-token> <manager-ip>:2377

6.2 Приєднання додаткового manager

Та сама команда, але з manager-token замість worker-token. Для кластерів, де важлива відмовостійкість самого управління, а не лише робочих навантажень, рекомендовано тримати 3 або 5 manager-нод - відповідно до формули кворуму з розділу 3.7.

6.3 Перевірка складу кластера

docker node ls

Команда виконується тільки на manager-ноді і показує всі ноди кластера разом з їхньою роллю (Manager / Worker) і поточним статусом (Ready, Down тощо) - перший інструмент для діагностики, коли щось у кластері поводиться не так, як очікувалось.

7. Services: запуск і масштабування

7.1 Створення сервісу

docker service create --name app --replicas 3 --publish 80:3000 myimage

Ця команда - концептуальний аналог docker run зі статті 1 основної серії, але на рівні кластера: замість одного контейнера на одному хості Swarm сам розподіляє три репліки між доступними нодами, керуючись власним алгоритмом планування.

7.2 Перегляд стану сервісів

docker service ls
docker service ps app

docker service ls показує список усіх сервісів кластера з кількістю готових реплік. docker service ps app деталізує: на якій саме ноді живе кожна конкретна репліка сервісу app, і в якому вона стані.

7.3 Масштабування в реальному часі

docker service scale app=5

Кількість реплік змінюється без перестворення сервіса і без простою вже запущених реплік - Swarm просто додає або прибирає потрібну кількість задач, підлаштовуючи реальний стан під нове бажане значення.

7.4 Вбудований ingress load balancer

Прапор --publish у Swarm працює інакше, ніж у звичайному docker run. Будь-яка нода кластера, навіть та, на якій фізично не запущено жодної репліки сервіса, приймає вхідний трафік на вказаний порт і сама проксує його до однієї з живих реплік - незалежно від того, на якій ноді та репліка насправді працює. Це знімає потребу у зовнішньому балансувальнику для базового сценарію: звернутись можна на IP будь-якої ноди кластера.

8. Overlay network

8.1 Створення overlay-мережі

docker network create --driver overlay mynet

На відміну від bridge-мережі зі статті 2 основної серії, яка існує тільки в межах одного хоста, overlay-мережа доступна одночасно на всіх нодах кластера.

8.2 DNS між сервісами

Сервіси, під'єднані до однієї overlay-мережі, резолвлять одне одного за іменем сервіса через вбудований Swarm DNS - той самий принцип, що й у Compose (стаття 2), тільки тепер він працює через межі фізичних серверів, а не лише в межах одного хоста.

8.3 Шифрування і ізоляція

Трафік між нодами всередині overlay-мережі інкапсулюється у VXLAN і може бути додатково зашифрований. Ізоляція між різними overlay-мережами працює за тим самим принципом, що й ізоляція bridge-мереж у Compose: сервіс з однієї мережі не бачить сервіс з іншої, навіть якщо вони працюють на тих самих фізичних нодах.

9. Rolling update

9.1 Оновлення образу сервіса

docker service update --image myimage:v2 app

На відміну від docker compose up -d --no-deps app зі статті 4 основної серії, де оновлення застосунку означало короткий, але одномоментний перезапуск усіх реплік одразу, Swarm замінює репліки поступово, одну групу за іншою, не зупиняючи весь сервіс одночасно.

9.2 Керування темпом оновлення

9.3 Автоматичний відкат при помилці

Прапор --update-failure-action rollback вмикає автоматичне повернення до попередньої версії образу, якщо нові репліки не змогли піднятись успішно. Це прямий розвиток ідеї ручного rollback через SHA-тег зі статті 4 основної серії - тільки тепер рішення про відкат приймає сам кластер, а не людина за командою в терміналі.

9.4 Результат: zero-downtime без зовнішнього балансувальника

Поєднання поступової заміни реплік і вбудованого ingress load balancer з розділу 7.4 дає справжній zero-downtime update - той рівень, якого в статті 3 основної серії можна було досягти тільки складною схемою blue/green з ручним перемиканням Nginx.

10. Self-healing і обмеження Swarm

10.1 Відмова ноди

Якщо нода стає недоступною, Swarm перепланує всі задачі, що на ній виконувались, на інші доступні ноди кластера - за умови, що кворум manager-нод (розділ 3.7) усе ще зберігається.

10.2 Відмова окремої задачі

Якщо падає сам процес усередині контейнера-задачі, Swarm перезапускає його відповідно до політики --restart-condition - концептуально той самий механізм, що й restart: unless-stopped у Compose, тільки застосований на рівні кластера, а не окремого хоста.

10.3 Чесні обмеження порівняно з Kubernetes

Swarm свідомо простіший за Kubernetes, і це варто розуміти прямо, а не виявляти post factum. Відсутні: horizontal pod autoscaling (автоматичне масштабування за навантаженням), повноцінний health-check API порівняно з Kubernetes probes, механізм CRD і operators для розширення поведінки кластера, а підтримка stateful-сервісів (баз даних усередині кластера) помітно слабша, ніж у екосистемі Kubernetes з її StatefulSets і persistent volume claims.

10.4 Коли Swarm дійсно достатній

Там, де потрібен невеликий production-кластер без хмарного провайдера, і де простота операційного обслуговування важливіша за гнучкість - Swarm залишається розумним вибором. Команда, яка ще не має досвіду з Kubernetes, отримує відмовостійкість і rolling update буквально за одну команду docker swarm init, без кривої навчання, яку вимагає повноцінний Kubernetes-кластер.

11. Висновок

У результаті цієї статті є робочий кластер із щонайменше двох нод, сервіс, запущений одночасно на кількох із них, і rolling update, який оновлює версію образу без помітного простою для користувачів. Це вже помітний крок вперед порівняно з одним VPS із кінця основної серії: падіння однієї ноди більше не означає падіння всього стека.

Лишається відкритим практичне питання: як розгортати не окремий сервіс командою docker service create, а цілий стек із кількох сервісів одразу, як зберігати паролі бази даних не у відкритому .env, а через механізм, призначений саме для секретів, і як дивитись на все це не з командного рядка, а через графічний інтерфейс. Саме цим темам присвячена друга, завершальна стаття міні-серії.

Часті запитання