A modern alkalmazásfejlesztés világában egyre nagyobb kihívást jelent a komplex, több komponensből álló rendszerek hatékony kezelése. Amikor tucatnyi mikroszolgáltatás fut párhuzamosan, és mindegyiknek különböző erőforrás-igényei vannak, az egyszerű konténerizáció már nem elegendő. Itt lép be a képbe a Docker Swarm, amely forradalmasította a konténer-alapú alkalmazások üzemeltetését.
A Docker Swarm egy natív klaszterezési és orkhesztrációs megoldás, amely lehetővé teszi több Docker host egyesítését egyetlen virtuális Docker hostként. Ez a technológia automatizálja a konténerek telepítését, skálázását és kezelését egy teljes gépcsoport között. A Swarm mód beépített load balancing, service discovery és rolling update funkciókat biztosít.
Az alábbi részletes elemzés betekintést nyújt a Docker Swarm működésébe, architektúrájába és gyakorlati alkalmazásaiba. Megismerheted a manager és worker node-ok közötti különbségeket, a szolgáltatások definiálásának módját, valamint a skálázási és hibakezelési mechanizmusokat. Gyakorlati példákon keresztül láthatod, hogyan építhetsz fel robusztus, magas rendelkezésre állású alkalmazásokat.
Mi a Docker Swarm és miért fontos?
A Docker Swarm alapvetően megváltoztatja a konténerek kezelésének módját nagyvállalati környezetben. Míg egy egyszerű Docker telepítés esetén minden konténert manuálisan kell indítani és kezelni, addig a Swarm automatizálja ezeket a folyamatokat.
A Swarm mód legnagyobb előnye a deklaratív szolgáltatás-definíció. Ez azt jelenti, hogy nem azt mondjuk meg, hogyan indítson el egy konténert, hanem azt, hogy milyen állapotot szeretnénk elérni. A Swarm orchestrator ezután folyamatosan figyeli és fenntartja ezt az állapotot.
A modern DevOps kultúrában a Docker Swarm különösen értékes, mivel egyszerűbb alternatívát kínál a Kubernetes-hez képest. Míg a Kubernetes rendkívül erőteljes, addig a Swarm könnyebben tanulható és kevesebb konfigurációt igényel.
Docker Swarm architektúra és komponensek
Manager és Worker node-ok szerepe
A Docker Swarm klaszter két fő típusú node-ból áll: manager node-ok és worker node-ok. A manager node-ok felelősek a klaszter állapotának fenntartásáért, a szolgáltatások ütemezéséért és az API végpontok biztosításáért.
A worker node-ok kizárólag a konténerek futtatására szolgálnak. Fontos megjegyezni, hogy a manager node-ok alapértelmezetten worker funkciókat is ellátnak, kivéve, ha explicit módon letiltjuk ezt a viselkedést.
A Raft konszenzus algoritmus biztosítja a manager node-ok közötti adatkonzisztenciát. Ez azt jelenti, hogy a klaszter állapota minden manager node-on szinkronizálva van, és a döntések demokratikus módon születnek.
Szolgáltatások és taskok fogalma
A Docker Swarm-ban a service a legmagasabb szintű absztrakció. Egy service definiálja, hogy milyen konténereket szeretnénk futtatni, hány példányban és milyen konfigurációval. A service-ek deklaratív módon írják le a kívánt állapotot.
A task egy service egy konkrét példánya egy adott node-on. Minden task tartalmaz egy konténert és a hozzá tartozó konfigurációt. A Swarm orchestrator folyamatosan figyeli a task-okat és szükség esetén újraindítja vagy áthelyezi őket.
A replica fogalma azt jelenti, hogy egy service-ből hány példányt szeretnénk futtatni. A Swarm automatikusan elosztja ezeket a replikákat a rendelkezésre álló node-ok között.
Swarm inicializálás és csomópontok kezelése
Klaszter létrehozása és konfigurálása
A Docker Swarm inicializálása rendkívül egyszerű folyamat. Az első manager node létrehozásához elegendő egyetlen parancs futtatása: docker swarm init. Ez a parancs automatikusan generál egy egyedi klaszter-azonosítót és token-eket a további node-ok csatlakoztatásához.
A advertise address megadása kritikus fontosságú többhálózatos környezetekben. Ez az IP-cím határozza meg, hogy a többi node hogyan éri el az adott manager node-ot. Helytelen beállítás esetén a klaszter kommunikációja megszakadhat.
Az inicializálás során a Docker automatikusan létrehozza a szükséges tanúsítványokat és kulcsokat a biztonságos kommunikációhoz. Minden node egyedi identitást kap, amely lehetővé teszi a kölcsönös hitelesítést.
Node-ok hozzáadása és eltávolítása
Új worker node hozzáadásához a docker swarm join parancsot kell használni a megfelelő token-nel és manager címmel. A join token-ek külön generálódnak worker és manager node-ok számára, ami fokozott biztonságot nyújt.
A node-ok eltávolítása kétlépcsős folyamat. Először a node-ot drain állapotba kell helyezni, ami azt jelenti, hogy az összes futó task áthelyeződik más node-okra. Ezután a node biztonságosan eltávolítható a klaszterből.
A node label-ek használata lehetővé teszi a node-ok kategorizálását és a szolgáltatások célzott telepítését. Például megadhatunk label-eket a hardver típusára vagy a földrajzi helyre vonatkozóan.
| Node típus | Szerepkör | Minimális darabszám | Ajánlott darabszám |
|---|---|---|---|
| Manager | Klaszter irányítás, API végpont | 1 | 3 (HA esetén) |
| Worker | Konténer futtatás | 0 | 2+ |
| Manager+Worker | Vegyes szerepkör | 1 | 1 (kisebb környezetek) |
Service-ek létrehozása és konfigurálása
Replicated és Global szolgáltatások
A Docker Swarm két alapvető service típust támogat: replicated és global szolgáltatásokat. A replicated service-ek esetén meghatározhatjuk, hogy pontosan hány replica fusson a klaszterben, és a Swarm automatikusan elosztja ezeket a node-ok között.
A global service-ek minden node-on pontosan egy példányban futnak. Ez különösen hasznos monitoring ágensek, log collector-ok vagy biztonsági szoftverek esetén, ahol minden gépen szükség van a szolgáltatásra.
A placement constraint-ek segítségével finomhangolhatjuk, hogy mely node-okon futhatnak az egyes szolgáltatások. Például megadhatjuk, hogy egy adatbázis csak SSD tárolóval rendelkező node-okon induljon el.
Hálózatok és volume-ok kezelése
A Docker Swarm automatikusan létrehoz egy overlay hálózatot minden service számára. Ez lehetővé teszi, hogy a különböző node-okon futó konténerek közvetlenül kommunikáljanak egymással, mintha ugyanazon a gépen futnának.
A ingress hálózat biztosítja a külső forgalom load balancing-ját. Amikor egy szolgáltatás portot publikál, az összes node-on elérhető lesz, függetlenül attól, hogy azon a node-on fut-e a szolgáltatás vagy sem.
A volume-ok kezelése Swarm környezetben összetettebb, mivel biztosítani kell, hogy az adatok minden node számára elérhetőek legyenek. Named volume-ok, bind mount-ok és external volume driver-ek használhatók erre a célra.
"A Docker Swarm legnagyobb erőssége abban rejlik, hogy a komplex orkhesztrációs feladatokat egyszerű, deklaratív konfigurációkká alakítja át."
Skálázás és load balancing
Automatikus és manuális skálázás
A Docker Swarm kiváló skálázási lehetőségeket kínál mind horizontális, mind vertikális irányban. A manuális skálázás során egyszerűen megváltoztatjuk a service replica számát a docker service scale paranccsal.
A horizontális skálázás során új replica-k indulnak el a klaszter különböző node-jain. A Swarm scheduler intelligensen választja ki a legmegfelelőbb node-okat a rendelkezésre álló erőforrások és a placement constraint-ek alapján.
Az automatikus skálázás külső eszközök segítségével valósítható meg, amelyek monitorozzák a CPU, memória vagy egyéb metrikákat, és szükség esetén módosítják a replica számot. Ez különösen hasznos változó terhelésű alkalmazások esetén.
Built-in load balancing mechanizmusok
A Docker Swarm beépített load balancer-t biztosít minden service számára. Az internal load balancing a service neveken keresztül működik, és automatikusan elosztja a forgalmat a rendelkezésre álló replica-k között.
Az external load balancing az ingress hálózaton keresztül valósul meg. Amikor egy kliens kapcsolódik egy publikált porthoz, a kérés automatikusan továbbítódik egy egészséges replica-hoz, függetlenül attól, hogy melyik node-ra érkezik.
A load balancing algoritmus alapértelmezetten round-robin módszerrel működik, de session affinity és egyéb speciális igények kielégítésére external load balancer-ek is használhatók.
Hálózatkezelés Swarm módban
Overlay hálózatok működése
Az overlay hálózatok a Docker Swarm hálózatkezelésének gerincét alkotják. Ezek a hálózatok VXLAN technológiát használnak a különböző host-ok közötti kommunikáció megvalósításához.
Minden overlay hálózat saját IP tartománnyal rendelkezik, és a konténerek automatikusan IP-címet kapnak ebből a tartományból. A DNS alapú service discovery lehetővé teszi, hogy a szolgáltatások név alapján találják meg egymást.
A mesh routing biztosítja, hogy minden node képes legyen forgalmat továbbítani bármely service-hez, még akkor is, ha az adott node-on nem fut az adott szolgáltatás példánya.
Service discovery és DNS
A Docker Swarm beépített DNS alapú service discovery-t biztosít. Minden service automatikusan kap egy DNS nevet, amely megegyezik a service nevével. Ez lehetővé teszi, hogy az alkalmazások egyszerűen hivatkozhassanak egymásra.
A virtual IP (VIP) mechanizmus biztosítja, hogy minden service mögött egy stabil IP-cím álljon, függetlenül attól, hogy hány replica fut és azok hol helyezkednek el. Ez jelentősen leegyszerűsíti az alkalmazások közötti kommunikációt.
Az endpoint mód konfigurálásával befolyásolhatjuk, hogyan történik a load balancing. A VIP mód centralizált load balancing-ot biztosít, míg a DNSRR (DNS Round Robin) mód közvetlenül a replica IP-címeket adja vissza.
Rolling update és verziókezelés
Fokozatos frissítések stratégiái
A rolling update az egyik legfontosabb funkciója a Docker Swarm-nak, amely lehetővé teszi az alkalmazások megszakítás nélküli frissítését. A folyamat során a replica-k fokozatosan cserélődnek ki az új verzióra.
A parallelism beállítás határozza meg, hogy egyszerre hány replica frissüljön. Alacsony érték esetén a frissítés lassabb, de biztonságosabb, míg magas érték gyorsabb frissítést eredményez, de nagyobb kockázattal jár.
A delay paraméter meghatározza az egyes frissítési lépések közötti várakozási időt. Ez lehetőséget ad az új replica-knak a teljes inicializálásra, mielőtt a következő frissítési kör elkezdődne.
Rollback mechanizmusok
A Docker Swarm automatikus rollback funkciókat kínál, amelyek problémás frissítések esetén aktiválódnak. A failure threshold beállítás határozza meg, hogy hány sikertelen replica után induljon el a rollback folyamat.
A monitor period alatt a Swarm figyeli az új replica-k állapotát, és ha a megadott threshold-ot túllépi a sikertelen példányok száma, automatikusan visszaáll az előző verzióra.
A manuális rollback is lehetséges a docker service rollback parancs használatával. Ez különösen hasznos olyan esetekben, amikor a frissítés technikailag sikeres volt, de funkcionális problémákat okozott.
| Frissítési paraméter | Alapértelmezett érték | Ajánlott beállítás | Hatás |
|---|---|---|---|
| Parallelism | 1 | 1-2 (kis szolgáltatások) | Egyszerre frissülő replica-k száma |
| Delay | 0s | 10s-30s | Várakozás frissítési lépések között |
| Failure action | pause | rollback | Művelet sikertelen frissítés esetén |
| Monitor period | 5s | 30s-60s | Új replica-k megfigyelési ideje |
Secrets és konfigurációkezelés
Biztonságos adatok kezelése
A Docker Secrets mechanizmus lehetővé teszi érzékeny adatok (jelszavak, API kulcsok, tanúsítványok) biztonságos kezelését Swarm környezetben. A secrets titkosítva tárolódnak a Swarm adatbázisban és csak a szükséges konténerek számára válnak elérhetővé.
A secrets nem environment változókon keresztül kerülnek átadásra, hanem in-memory fájlrendszeren keresztül mount-olódnak a konténerekbe. Ez megakadályozza, hogy érzékeny adatok véletlenül log fájlokba vagy process listákba kerüljenek.
A secret rotation lehetővé teszi a secrets frissítését anélkül, hogy a szolgáltatásokat újra kellene indítani. Ez kritikus fontosságú biztonsági szempontból, különösen hosszú távon futó szolgáltatások esetén.
Konfiguráció externalizálása
A Docker Configs mechanizmus hasonlóan működik a secrets-hez, de nem titkosított konfigurációs fájlok kezelésére szolgál. Ez lehetővé teszi az alkalmazás konfigurációjának externalizálását anélkül, hogy azt a konténer image-be kellene beépíteni.
A config fájlok ugyanúgy mount-olódnak a konténerekbe, mint a secrets, de nem titkosítva tárolódnak. Ez egyszerűsíti az alkalmazások konfigurálását és lehetővé teszi a dinamikus konfigurációváltoztatásokat.
A template-ek használata lehetővé teszi dinamikus konfigurációk létrehozását, amelyek runtime információkat (például node ID, service név) tartalmazhatnak. Ez különösen hasznos monitoring és logging konfigurációk esetén.
"A secrets és configs helyes használata a különbség a hobby projekt és a production-ready alkalmazás között Docker Swarm környezetben."
Monitoring és hibakezelés
Egészségmonitorozás és health check-ek
A health check-ek kritikus szerepet játszanak a Docker Swarm megbízhatóságában. Minden konténer számára definiálhatunk health check parancsokat, amelyek rendszeresen ellenőrzik a szolgáltatás állapotát.
A Swarm automatikusan újraindítja vagy áthelyezi azokat a task-okat, amelyek health check-je sikertelenül zárul. Ez biztosítja, hogy csak egészséges replica-k szolgáljanak ki forgalmat.
A custom health check-ek lehetővé teszik alkalmazás-specifikus állapot ellenőrzések implementálását. Például egy web alkalmazás esetén ellenőrizhetjük egy kritikus API endpoint elérhetőségét.
Log aggregáció és metrikák
A centralizált logging elengedhetetlen nagyobb Swarm klaszterek esetén. A Docker natív log driver-ek támogatják a népszerű log aggregációs rendszereket, mint az ELK stack vagy a Fluentd.
A node és service metrikák gyűjtése lehetővé teszi a klaszter teljesítményének folyamatos monitorozását. Prometheus és Grafana kombinációja különösen népszerű megoldás erre a célra.
A alerting rendszerek konfigurálása biztosítja, hogy a kritikus problémákról időben értesüljünk. Ez magában foglalja a node leállásokat, service hibákat és erőforrás-kimerülési helyzeteket.
Biztonsági aspektusok
TLS és tanúsítványkezelés
A Docker Swarm alapértelmezetten mutual TLS (mTLS) titkosítást használ minden node közötti kommunikációhoz. Ez biztosítja, hogy csak hitelesített node-ok csatlakozhassanak a klaszterhez.
A tanúsítványok automatikus rotációja megakadályozza a hosszú távú biztonsági kockázatokat. A Swarm alapértelmezetten 90 naponta újítja meg a tanúsítványokat, de ez az időszak konfigurálható.
A CA tanúsítvány védelme kritikus fontosságú a klaszter biztonságához. A root CA private key kompromittálása esetén az egész klaszter újraépítése válhat szükségessé.
RBAC és hozzáférés-vezérlés
Bár a Docker Swarm nem rendelkezik beépített RBAC (Role-Based Access Control) rendszerrel, külső megoldások integrálhatók a finomhangolt hozzáférés-vezérlés érdekében.
A Docker Enterprise kiegészítő licenccel részletesebb biztonsági funkciókat kínál, beleértve a felhasználói hitelesítést és authorizációt. Ez különösen fontos vállalati környezetekben.
A network segmentation használata lehetővé teszi a szolgáltatások izolálását és a lateral movement támadások megakadályozását. Overlay hálózatok és firewall szabályok kombinációja nyújtja a legerősebb védelmet.
"A Docker Swarm biztonsága csak annyira erős, mint a leggyengébb láncszeme – minden komponens megfelelő konfigurálása elengedhetetlen."
Teljesítményoptimalizálás
Erőforrás-kezelés és limitek
A resource constraint-ek megadása biztosítja, hogy egyetlen szolgáltatás se monopolizálja a node erőforrásait. CPU és memória limitek beállítása megakadályozza a "noisy neighbor" problémákat.
A reservation beállítások garantálják a minimális erőforrás-allokációt egy szolgáltatás számára. Ez különösen fontos kritikus alkalmazások esetén, ahol az erőforrások előre foglalása szükséges.
A placement preference-ek használata lehetővé teszi az optimális erőforrás-kihasználást. Például preferálhatjuk az alacsonyabb terhelésű node-okat új task-ok indításához.
Storage és I/O optimalizálás
A volume driver-ek kiválasztása jelentős hatással van a teljesítményre. Local volume-ok gyorsabbak, de nem biztosítanak magas rendelkezésre állást, míg a network volume-ok lassabbak, de rugalmasabbak.
A SSD tárolók használata kritikus fontosságú adatbázis szolgáltatások esetén. A placement constraint-ek segítségével biztosíthatjuk, hogy ezek a szolgáltatások csak megfelelő tárolóval rendelkező node-okon induljanak.
A I/O throttling beállítások megakadályozzák, hogy egy szolgáltatás túlzottan terhelje a tárolórendszert. Ez különösen fontos megosztott tárolók esetén.
Hibakeresés és troubleshooting
Gyakori problémák és megoldások
A split-brain szituációk elkerülése érdekében mindig páratlan számú manager node-ot használjunk. Három manager node biztosítja az egy node leállását, míg öt manager már két node egyidejű hibáját is képes kezelni.
A network connectivity problémák gyakran a tűzfal beállításokból erednek. A Docker Swarm számos portot használ (2377, 7946, 4789), amelyeket minden node között meg kell nyitni.
A disk space kimerülése kritikus problémát okozhat, különösen a manager node-okon. A Swarm adatbázis és a log fájlok rendszeres tisztítása elengedhetetlen.
Diagnosztikai eszközök és parancsok
A docker node ls parancs gyors áttekintést nyújt a klaszter állapotáról. Az Unreachable vagy Down státuszú node-ok azonnali figyelmet igényelnek.
A docker service ps parancs részletes információkat ad egy service task-jairól, beleértve a hibás indítási kísérleteket és azok okait. Ez az első lépés a service-szintű problémák diagnosztizálásában.
A docker system df és docker system prune parancsok segítenek a disk space kezelésében és a felesleges objektumok eltávolításában.
"A hatékony troubleshooting kulcsa a megfelelő monitoring és a proaktív problémakezelés Docker Swarm környezetekben."
Production környezetek kialakítása
Magas rendelkezésre állás tervezése
A multi-zone deployment biztosítja, hogy a klaszter túlélje egy teljes adatközpont kiesését. A manager node-okat különböző availability zone-okba kell helyezni a maximális redundancia érdekében.
A backup stratégia kialakítása kritikus fontosságú. A Swarm állapot rendszeres mentése lehetővé teszi a gyors helyreállítást katasztrofális hibák esetén.
A disaster recovery tervek kidolgozása és rendszeres tesztelése biztosítja, hogy vészhelyzet esetén gyorsan helyreállíthassuk a szolgáltatásokat.
Kapacitástervezés és skálázás
A resource monitoring folyamatos figyelemmel kísérése lehetővé teszi a proaktív kapacitásbővítést. A CPU, memória és hálózat metrikák trendjei alapján előre jelezhetjük a jövőbeli igényeket.
A node heterogenitás kezelése különösen fontos nagyobb klaszterekben. Különböző node típusok (compute-optimized, memory-optimized, storage-optimized) használata lehetővé teszi az optimális erőforrás-kihasználást.
A cost optimization szempontjából fontos a spot instance-ok és reserved instance-ok megfelelő kombinációja cloud környezetekben.
Docker Swarm vs alternatívák
Kubernetes összehasonlítás
A komplexitás tekintetében a Docker Swarm jelentősen egyszerűbb, mint a Kubernetes. Míg a Kubernetes számos komponenst és konfigurációt igényel, addig a Swarm "out-of-the-box" működik.
A ökoszisztéma szempontjából azonban a Kubernetes előnyben van. A CNCF ökoszisztéma sokkal több eszközt és integrációt kínál, mint amit a Docker Swarm natívan támogat.
A tanulási görbe meredeksége jelentősen eltér. A Docker Swarm néhány óra alatt elsajátítható, míg a Kubernetes kompetens használata hónapokat igényel.
Mikor válasszuk a Docker Swarm-ot?
A kis és közepes méretű projektek esetén a Docker Swarm gyakran a jobb választás egyszerűsége miatt. Különösen igaz ez olyan csapatokra, amelyek már jól ismerik a Docker-t.
A gyors prototípus fejlesztés során a Swarm lehetővé teszi a gyors iterációt és tesztelést. Az alacsony konfigurációs overhead-del több időt fordíthatunk az alkalmazás fejlesztésére.
A legacy alkalmazások konténerizálása során a Swarm gyakran simább átmenetet biztosít, mivel kevesebb alkalmazás-módosítást igényel.
"A Docker Swarm nem a leghatékonyabb orkhesztrátor, de gyakran a legpraktikusabb választás kisebb csapatok és projektek számára."
Jövőbeli trendek és fejlesztések
Edge computing és IoT integráció
Az edge computing térnyerésével a Docker Swarm könnyűsége előnnyé válik. A kisebb footprint és egyszerűbb kezelhetőség ideálissá teszi edge node-ok kezelésére.
Az IoT eszközök orkhesztrációja új kihívásokat jelent, amelyekre a Swarm jól felkészült. A beépített security és a könnyű telepíthetőség kritikus előnyök ebben a környezetben.
A hybrid cloud architektúrák esetén a Swarm egyszerűsége megkönnyíti a multi-cloud deploymenteket és a vendor lock-in elkerülését.
Fejlesztési irányok
A WebAssembly (WASM) integráció új lehetőségeket nyit a konténerek mellett. A Docker már kísérletezik WASM workload-ok támogatásával Swarm környezetben.
A GitOps workflow-k integrálása egyre fontosabbá válik. A deklaratív természet miatt a Swarm jól illeszkedik a GitOps paradigmákhoz.
Az AI/ML workload-ok támogatása fejlesztés alatt áll, beleértve a GPU resource-ok kezelését és a specialized node-ok támogatását.
"A Docker Swarm jövője a egyszerűség és a hatékonyság közötti egyensúly megtalálásában rejlik, különösen a edge computing és hibrid környezetek kontextusában."
Mi a különbség a Docker Swarm és a Kubernetes között?
A Docker Swarm sokkal egyszerűbb telepíteni és kezelni, beépített a Docker Engine-be, és kevesebb konfigurációt igényel. A Kubernetes összetettebb, de sokkal több funkcionalitást és rugalmasságot kínál, valamint nagyobb ökoszisztémával rendelkezik.
Hány manager node szükséges egy production klaszterhez?
Production környezetben minimum 3 manager node ajánlott a magas rendelkezésre állás biztosításához. Ez lehetővé teszi egy manager node kiesését anélkül, hogy a klaszter működése megszakadna. Nagyobb környezetekben 5 vagy 7 manager node is használható.
Hogyan működik a load balancing Docker Swarm-ban?
A Docker Swarm beépített load balancer-t használ, amely automatikusan elosztja a forgalmat a service replica-k között. Az ingress network biztosítja, hogy bármely node-on keresztül elérhető legyen a service, még akkor is, ha azon a node-on nem fut replica.
Milyen portokat kell megnyitni Docker Swarm használatához?
Docker Swarm három fő portot használ: 2377 (cluster management), 7946 (node kommunikáció TCP és UDP), és 4789 (overlay network forgalom UDP). Ezeket minden node között meg kell nyitni a megfelelő működéshez.
Lehet-e Docker Swarm-ot használni Windows konténerekkel?
Igen, a Docker Swarm támogatja a Windows konténereket is. Azonban vegyes (Linux és Windows) node-okból álló klaszterekben a szolgáltatásokat megfelelő placement constraint-ekkel kell konfigurálni, hogy a konténerek a megfelelő operációs rendszerű node-okon induljanak.
Hogyan lehet biztonsági mentést készíteni Docker Swarm klaszterről?
A Swarm állapot mentéséhez le kell állítani a Docker daemon-t egy manager node-on, majd lemásolni a /var/lib/docker/swarm könyvtárat. A visszaállításhoz ezt a könyvtárat kell visszamásolni és a docker swarm init --force-new-cluster paranccsal újra inicializálni a klasztert.
