Docker Swarm: cluster z několika nodů na VPS

Docker Swarm: cluster z několika nodů

Hlavní série „Docker na VPS" skončila logickým náznakem: vše, co jsme stavěli - od prvního kontejneru až po self-hosted Git s vlastním CI - běželo na jednom serveru. Jeden server znamená jeden bod selhání: pokud VPS spadne, spadne celý stack najednou, bez ohledu na to, kolik restart: unless-stopped je zapsáno v compose souboru.

Docker Swarm je orchestrátor vestavěný do Docker Engine, který řeší přesně tento problém: rozkládá služby mezi několik nodů a sám hlídá, aby byl spuštěn požadovaný počet replik, i když jeden z nodů selže. Klíčový rozdíl oproti všemu, co jsme dosud dělali, je absence jakýchkoli externích závislostí. Není třeba instalovat Kubernetes, etcd nebo samostatnou control plane: cluster se zvedne jedním příkazem docker swarm init na stejném Docker Engine, který už na serveru běží od prvního článku série.

Swarm se vyplatí v konkrétní nice: cluster o 2-10 nodech, tým bez zkušenosti s Kubernetes, infrastruktura na VPS nebo bare-metal bez cloudového poskytovatele s hotovým managed clusterem. Mimo tuto niku - velké clustery, náročné stateful zátěže, potřeba autoscalingu - už jde o Kubernetes, ale to je téma na jinou diskusi.

Tato mini-série se skládá ze dvou článků. První je o samotném clusteru: nody, služby, overlay sítě, rolling update bez výpadku. Druhý o tom, co je potřeba pro reálné nasazení: secrets a configs namísto .env v otevřené podobě, docker stack deploy pro nasazení compose souborů jako celého stacku, a Portainer jako grafické rozhraní nad tím vším.

2. Swarm vs standalone Docker Compose

V článcích 1-5 hlavní série řídil Docker Compose kontejnery na jednom hostu. Nebyl tam žádný failover ani rozložení zátěže mezi servery - pokud host spadl, spadly všechny služby najednou, a znovu je bylo možné spustit jen na něm, jakmile byl opět dostupný.

Swarm nevyžaduje přepsat vše od nuly. Stejné principy compose souboru - služby, sítě, volumes - se přenášejí téměř beze změn; rozdíl je v příkazu pro nasazení: místo docker compose up -d se používá docker stack deploy, který rozkládá služby mezi nody clusteru, místo aby je všechny zvedl na jednom hostu.

Hlavní koncepční rozdíl je v tom, co přesně Docker hlídá. V běžném Compose je základní jednotkou kontejner: konkrétní běžící proces na konkrétním hostu. Ve Swarmu je základní jednotkou služba: deklarace požadovaného stavu ve stylu „udržuj 3 repliky image X spuštěné, bez ohledu na to, na kterých nodech". Kontejner je fakt, služba je záměr, který Swarm sám udržuje a při problému restartuje repliky tam, kde je to možné.

3. Klíčové koncepty

3.1 Node

Node je fyzický nebo virtuální stroj, který je součástí clusteru. Každý node má jednu ze dvou rolí: manager nebo worker.

3.2 Manager

Manager uchovává stav celého clusteru ve formě Raft logu, přijímá řídicí příkazy (docker service create, docker stack deploy) a plánuje, na kterých nodech spouštět úlohy. Minimum je jeden manager node; pro odolnost samotného řízení clusteru je potřeba lichý počet - 1, 3 nebo 5.

3.3 Worker

Worker vykonává úlohy (tasks) přidělené manager nody, ale sám nepřijímá řídicí příkazy clusteru. V jednoduché topologii může manager node zároveň vykonávat i pracovní zátěž, ale pro produkční clustery s více nody se manager obvykle od aplikačních služeb odlehčuje.

3.4 Service

Service je požadovaný stav: „udržuj N replik image X spuštěných a dostupných na portu Y". Swarm tento stav sám udržuje v čase - pokud repl­ika spadne, restartuje místo ní novou, aniž by čekal na zásah člověka.

3.5 Task

Task je jedna konkrétní instance služby na konkrétním nodu, fakticky ekvivalent jednoho kontejneru. Pokud má služba 3 repliky, cluster má současně 3 úlohy, možná rozmístěné na různých nodech.

3.6 Overlay network

Overlay síť je virtuální L2 síť nad L3 spojením mezi nody clusteru. Služby připojené ke stejné overlay síti vidí jedna druhou podle jména služby bez ohledu na to, na kterém fyzickém nodu je každá z nich skutečně spuštěna - stejně jako se služby Compose viděly podle jména v rámci jednoho hostu v článku 2 hlavní série.

3.7 Raft consensus

Manager nody mezi sebou sjednocují stav clusteru pomocí algoritmu Raft consensus. Kvórum - minimální počet manager nodů, které musí zůstat online, aby cluster dál přijímal rozhodnutí - se počítá jako (N/2)+1. Pro 3 manager nody je kvórum 2: cluster snese výpadek jednoho manager nodu a dál funguje.

4. Požadavky a příprava

4.1 Minimální topologie

Pro první seznámení stačí dva virtuální stroje s nainstalovaným Docker Engine podle článku 1 hlavní série: jeden se stane managerem, druhý workerem.

4.2 Porty mezi nody

Pro chod clusteru musí být mezi všemi nody otevřeny tři porty:

4.3 Jednotná verze Docker Engine

Na každém nodu musí běžet stejný Docker Engine, nainstalovaný oficiálním skriptem - bez Docker Desktop (není určen pro servery, jak bylo řečeno v prvním článku série) a bez rozdílů ve verzi Compose pluginu mezi nody. Rozdíl ve verzích Engine mezi managerem a workerem je vzácnou, ale reálnou příčinou podivného chování clusteru, které je obtížné zpětně diagnostikovat.

5. Inicializace clusteru

5.1 První node se stane managerem

docker swarm init --advertise-addr <IP_manager_nodu>

Přepínač --advertise-addr určuje, kterou IP adresu mají ostatní nody použít pro připojení k tomuto manageru - je důležité ji zadat explicitně, pokud má server více síťových rozhraní, aby se cluster nesnažil komunikovat přes privátní adresu nedostupnou zvenčí, nebo naopak.

5.2 Tokeny pro připojení

Po provedení příkazu Docker okamžitě vypíše dva tokeny - pro připojení worker nodů a pro připojení dalších manager nodů. Tokeny jsou dlouhé řetězce, které fungují jako heslo pro vstup do clusteru; uchovávat je je třeba stejně pečlivě jako SSH klíče pro deploy z článku 4 hlavní série.

5.3 Získání tokenu později

Pokud je terminál s výstupem příkazu už zavřený, tokeny lze kdykoli znovu získat:

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

6. Přidávání nodů

6.1 Připojení worker nodu

Na každém novém nodu, který je třeba přidat jako worker:

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

6.2 Připojení dalšího manageru

Stejný příkaz, ale s manager-token namísto worker-token. Pro clustery, kde je důležitá odolnost samotného řízení, nejen pracovní zátěže, se doporučuje udržovat 3 nebo 5 manager nodů - podle vzorce kvóra z kapitoly 3.7.

6.3 Kontrola složení clusteru

docker node ls

Příkaz se provádí pouze na manager nodu a ukazuje všechny nody clusteru s jejich rolí (Manager / Worker) a aktuálním stavem (Ready, Down atd.) - první nástroj pro diagnostiku, když se cluster chová jinak, než se očekávalo.

7. Services: spouštění a škálování

7.1 Vytvoření služby

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

Tento příkaz je koncepční obdobou docker run z článku 1 hlavní série, ale na úrovni clusteru: místo jednoho kontejneru na jednom hostu Swarm sám rozloží tři repliky mezi dostupné nody podle vlastního plánovacího algoritmu.

7.2 Zobrazení stavu služeb

docker service ls
docker service ps app

docker service ls zobrazuje seznam všech služeb clusteru s počtem připravených replik. docker service ps app rozepisuje detaily: na kterém konkrétním nodu žije každá konkrétní replika služby app a v jakém je stavu.

7.3 Škálování v reálném čase

docker service scale app=5

Počet replik se mění bez znovuvytvoření služby a bez výpadku už běžících replik - Swarm jednoduše přidá nebo odebere potřebný počet úloh a reálný stav upraví podle nové požadované hodnoty.

7.4 Vestavěný ingress load balancer

Přepínač --publish ve Swarmu funguje jinak než v běžném docker run. Jakýkoli node clusteru, dokonce i ten, na kterém fyzicky neběží žádná replika služby, přijímá příchozí provoz na zadaném portu a sám jej proxuje k jedné z živých replik - bez ohledu na to, na kterém nodu daná replika skutečně běží. To odstraňuje potřebu externího load balanceru pro základní scénář: lze se připojit na IP adresu kterékoli nody clusteru.

8. Overlay network

8.1 Vytvoření overlay sítě

docker network create --driver overlay mynet

Na rozdíl od bridge sítě z článku 2 hlavní série, která existuje pouze v rámci jednoho hostu, je overlay síť dostupná současně na všech nodech clusteru.

8.2 DNS mezi službami

Služby připojené ke stejné overlay síti si navzájem resolvují jméno služby přes vestavěné Swarm DNS - stejný princip jako v Compose (článek 2), jen nyní funguje i přes hranice fyzických serverů, nejen v rámci jednoho hostu.

8.3 Šifrování a izolace

Provoz mezi nody uvnitř overlay sítě je zapouzdřen do VXLAN a lze jej dodatečně zašifrovat. Izolace mezi různými overlay sítěmi funguje na stejném principu jako izolace bridge sítí v Compose: služba z jedné sítě nevidí službu z jiné, i když běží na stejných fyzických nodech.

9. Rolling update

9.1 Aktualizace image služby

docker service update --image myimage:v2 app

Na rozdíl od docker compose up -d --no-deps app z článku 4 hlavní série, kde aktualizace aplikace znamenala krátký, ale jednorázový restart všech replik najednou, Swarm nahrazuje repliky postupně, po skupinách, bez zastavení celé služby najednou.

9.2 Řízení tempa aktualizace

9.3 Automatický rollback při chybě

Přepínač --update-failure-action rollback zapíná automatický návrat k předchozí verzi image, pokud se nové repliky nepodařilo úspěšně zvednout. Jde o přímé rozvinutí myšlenky manuálního rollbacku přes SHA tag z článku 4 hlavní série - jen nyní rozhodnutí o rollbacku dělá sám cluster, nikoli člověk příkazem v terminálu.

9.4 Výsledek: zero-downtime bez externího load balanceru

Kombinace postupné náhrady replik a vestavěného ingress load balanceru z kapitoly 7.4 dává skutečný zero-downtime update - úroveň, kterou v článku 3 hlavní série bylo možné dosáhnout jen složitým schématem blue/green s manuálním přepínáním Nginx.

10. Self-healing a omezení Swarmu

10.1 Výpadek nodu

Pokud se node stane nedostupným, Swarm přeplánuje všechny úlohy, které na něm běžely, na ostatní dostupné nody clusteru - za podmínky, že kvórum manager nodů (kapitola 3.7) je stále zachováno.

10.2 Výpadek jednotlivé úlohy

Pokud spadne samotný proces uvnitř kontejneru úlohy, Swarm ho restartuje podle politiky --restart-condition - koncepčně stejný mechanismus jako restart: unless-stopped v Compose, jen aplikovaný na úrovni clusteru, nikoli jednotlivého hostu.

10.3 Upřímná omezení ve srovnání s Kubernetes

Swarm je záměrně jednodušší než Kubernetes, a je dobré to chápat předem, ne až zpětně. Chybí: horizontal pod autoscaling (automatické škálování podle zátěže), plnohodnotné health-check API ve srovnání s Kubernetes probes, mechanismus CRD a operators pro rozšíření chování clusteru, a podpora stateful služeb (databází uvnitř clusteru) je výrazně slabší než v ekosystému Kubernetes s jeho StatefulSets a persistent volume claims.

10.4 Kdy je Swarm skutečně dostatečný

Tam, kde je potřeba malý produkční cluster bez cloudového poskytovatele, a kde je jednoduchost provozu důležitější než flexibilita, zůstává Swarm rozumnou volbou. Tým, který ještě nemá zkušenost s Kubernetes, získá odolnost a rolling update doslova jedním příkazem docker swarm init, bez křivky učení, kterou vyžaduje plnohodnotný Kubernetes cluster.

11. Závěr

Výsledkem tohoto článku je funkční cluster z alespoň dvou nodů, služba spuštěná současně na několika z nich a rolling update, který aktualizuje verzi image bez znatelného výpadku pro uživatele. To je už znatelný posun oproti jednomu VPS z konce hlavní série: výpadek jednoho nodu už neznamená pád celého stacku.

Zůstává otevřená praktická otázka: jak nasadit nikoli jednotlivou službu příkazem docker service create, ale celý stack z několika služeb najednou; jak uchovávat hesla k databázi ne v otevřeném .env, ale mechanismem určeným přímo pro secrets; a jak se na to vše dívat nikoli z příkazové řádky, ale přes grafické rozhraní. Přesně těmto tématům je věnován druhý, závěrečný článek mini-série.

Často kladené otázky