Fórumok
Tudja valaki, hogy hogyan lehet megoldani Docker Swarmnál, hogy legyen egy olyan publikus IPje, ami a node kiesése estén "átvándorol" a másik futó node-ra?
Csináltam hozzá egy pythonos progit ami megcsinálja, de nem hiszem el, hogy nincs rá valami gyári megoldás.
A DNS-es hákolásokat nem szeretem, mert vagy rettentő alacsony a TTL vagy nagy a kiesés.
Ötlet?
Hozzászólások
Na most ezt még egyszer.
Ha egy IP host gépek között akarsz csereberélni arra vannak standard módszerek & eszközök, de semmi közük a docker-hez..
Mit akarsz csinálni?
https://goo.gl/muWzKz (digitalocean)
A docker annyiban kerül előtérbe, hogy van saját cluster managementje, és azt gondolnám, van valami megoldása az IP átvételre is.
A feladat egyszerű, adott egy domain DNSben beállított IP, működjön akkor is ha az egyik swarmos gép kiesik (és pont az ő IPje volt beállítva).
Szóval azt várod, hogy a Docker Swarm átállítsa a DNS bejegyzést? Vagy mit is vársz el pontosan, mit tudjon a swarm?
Azt mondod, hogy a DNS nem jó a TTL miatt.
Az ingresst (azaz hogyan éri el a külvilág a klasztert) mindig érdekes probléma megoldani.
Nem, olyasmit várnék el, hogy megadok x db IP-t, és docker ossza el a node-okon. Hasonlóan mint a lent említett metallb.
A Docker Swarm nem menedzseli a hoszt hálózatát. Mert nem ez a dolga.
A metallb meg igen, ez a dolga.
Nos a Docker Swarm szerintem menedzseli a hoszt hálózatát. Csatolókat, bridgeket stb hoz létre rajta. Tehát menedzseli.
Clustert csinál. Load balance-t csinál.
Innen már csak egy apró lépés lett volna, hogy kezelje az IP-ket. De ezek szerint azt nem csinálja.
Ezek _hoszton belüli_ virtuális hálózatok. Azt a nem virtuális hálózatot, amivel a hoszt kívülre csatlakozik, nem menedzseli. Nem állít neki IP címet például, pedig te ezt szeretnéd.
Így van. Összedobtam rá egy programot, max 100-150 sor, csak furcsa volt hogy nem találok rá kész cuccot.
Minek?
https://wiki.clusterlabs.org/wiki/Pacemaker
https://goo.gl/muWzKz (digitalocean)
Mert nem találtam, olyan progit ami a kieső gép IP-jét átveszi. A clustert a swarm megvalósítja, azzal nekem nincs dolgom.
én kubernetes alatt metallb -t használok, lényegében úgy megy hogy hostnetwork-ot használ az adott konténer amiből minden node-on van 1-1 folyamatosan életben és ő eldönti hogy melyik hirdesse az ip-t. ha meghal, akkor elkezdi a másik hirdetni és megy minden tovább. csekkold le, hátha megy swarmon is
Köszönöm a választ, kísérletezek vele. Hasonló dolgokat egyébként találtam, de pont arra lennék kíváncsi, hogy dockerben nincs-e ez valahogy megoldva. Mert fura, hogy mindent megcsináltak szépre/egyszerűre de ennek a problémának a nyomát sem látom.
Sajnos nincs.
A K8s / CNCF halozati megoldasai erosen fejlodokepesek. Kerdes, hogy mennyire a CaaS / infrastruktura feladata megoldani a problemat.
Traefik? https://containo.us/traefik/
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…
Nem értek hozzá, hogyan tudja ezt kezelni? Nézegettem, de pont az IP kezelést nem láttam benne.
Jól látod. Ez a cluster-re már beesett forgalom elosztására van, a kérdésedre pont nem válasz :)
https://goo.gl/muWzKz (digitalocean)
Mar mas is elmondta a velemenyet. De az en velemenyem is az, hogy nem az orchestration reteg feladata IPket pakolgatni ide oda a hosztok kozott. Remelhetoleg ezt a komplexitast sose fogjak belerakni.
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer
Tehát attól, hogy fut n darab pládányban az alkalmazásom, amik be is regisztrálják magukat és a master node oda tudja nekik adni a kérést, a magas rendelkezésre állást azt ezen kívül kell megoldani...
Igen is meg nem is. A belso VIP-ket a virtual network megoldja, hogy minden nodeon ott legyen. Itt most konkretan a publikus IP-rol van szo amit jobb esetben amugy sem jut el a hosztig hanem van elotte egy LB ami megoldja ezt az egeszet mind cloud mint on-demand eseten.
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer
A "belső" VIP az a cím, amin megszólítható a swarm-ban elérhető alkalmazás? Ha nem, akkor annak az életben tartását is meg kell valahogy oldani...
Nagyabbol igen, de nem maga a swarm csinalja ezt (onmagaban a k8s se tudja ezt megvalositani neki is kell CNI ehhez). Belemehetunk a reszletekbe de akkor nagyon elterunk a topictol.
A docker swarm sajnos egy jo jatekszer teszt rendszerre de productionbe sose vinnem.
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer
Akkor jól gondoltam/értettem... :-/ A második résszel - nem csak emiatt - egyetértek.
OFF.
Én több helyen részt vettem Docker Swarm production-környezetben való beüzemelésében gond nélkül. Nem tud annyit, mint a k8s, de jobban dokumentált és szerintem stabilabb is annál.
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…
2016-ota hasznalok kubernetest az elejen tenyleg volt gond a dokumentacioval mostanba nem tapasztaltam ilyet vagy csak eleg nagy a rutinom es nem tunik fel ez igy nem tudom felmerni sajnos.
A masik, hogy a docker swarm deprecated doptak a supportott. Semmilyen tamogatas nem lesz hozza hamarossan es kifogkerulni a docker-cebol is. Ez az egyik problemaja a tobbit mindjart kifejtem a kovetkezo posztban.
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer
"Belemehetunk a reszletekbe de akkor nagyon elterunk a topictol."
Nem, kb ez a topik lényege. A hogyan. Most kínomban írtam rá progit, hogy ne kelljen erre egy külön nagy rendszer beüzemelnem, de végére rájöttem hogy ha csak 1db publik ip van, akkor végképp leegyszerűsíthető projekt, mert docker event rendszerén változást figyelve a leaderen be kell állítani az IPt, a többin meg lekapcsolni és kész. Az valószínűleg még 100 sor se lenne. Nyilván lehet, hogy van valami nyilvánvaló amit most nem veszek észre, ezért kíváncsi lennék hogy miért nem jó ez a megközelítés, vagy hol fog hibára futni.
"A docker swarm sajnos egy jo jatekszer teszt rendszerre de productionbe sose vinnem. "
Most kéne production alá rendszert keresnem, tehát érdekelne a gyakorlati tapasztalat.
Miért? Mitől jobb/más/ mint a k8s? Elsőre pont az tetszik benne, hogy egyszerű mint a faék. Nyilván ebből következik, hogy kevésbé testre szabható, de ezt most túlélem.
Eloszor a docker swarm vs k8s dolog elso korben ott bukik el, hogy a swarmot nem fejlesztik tobbe a Mirantis deprecatednek nyilvanitotta es valoszinuleg a kovetkezo fo docker-ce verziobol ki is fog kerulni.
Igazabol a docker swarm egy felokositott docker-compose semmi tobb igazabol osszetud fogni tobb docker konternert nagy vonalakban.
De mi elott ebbe belemegyunk melyebben terjunk vissza az eredeti problemara ahhoz viszont van par kerdes amit meg kell valaszolnod.
Cloud vagy on-demand infrastruktura lesz?
Van fizikai vagy virtualis loadbalancer a halozatba?
Hany darab node van? Fizikai es virtualis?
Hogyan nezki a halozati topologia?
Hany darab kontenert kell futtatni egy idejuleg egy nodeon?
Hany kulonbozo kontenert lesz a rendszerbe?
Adatbazist is innen akarjatok futtatni vagy csak az alkalmazast? Persistance adattarolas lesz a docker kontenerek alatt?
Szukseges-e titkositani az environment valtozokat?
Mekkora forgalom varhato?
Mekkora rendelkezesre allas kell?
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer
Tudsz mutatni infót arról, hogy a Docker Swarm deprecated lett? Mert én csak azt találom, hogy nem:
https://medium.com/@markuman/is-docker-swarm-mode-eol-7a3f316116a3
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…
2019 november: https://www.mirantis.com/blog/mirantis-acquires-docker-enterprise-platf…
Azaz leginkább nem lehet tudni, mi lesz vele, merre megy a jövőben...
A fent linkelt írás pont erről szól.
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…
Faszom tele azzal, hogy időt és pénzt áldozol egy technológia megtanulására, aztán valaki felvásárolja és beszántja a picsába.
Komolyan: az egész IT tiszta lottó, vagy eltalálod a túlélő technológiát (függetlenül annak minőségétől), vagy elbasztál az életedből x évet.
Szerintem ha a Swarmot ismered és működik, akkor használd azt. Lehet, hogy új feature már nem fog bele érkezni, de kidobni nem fogják egy jó ideig a docker-ce-ből, az biztos. Ahol én használtam/használom, ott jól teljesít, stabil és kevésbé overhead, mint a k8s.
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…
Persze de ettől még halott cucc lesz, magyarán új 1-2 év múlva élesedő projektet már nem érdemes indítani benne.
Nem tudjuk, hogy mi lesz. Plusz attól még, hogy a cég nem propagál bele fejlesztést, a közösség még fejlesztheti, vagy legalább szinten tarthatja.
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…
Persze, de ettől még jelen pillanatban tele a faszom.
Holnapra elmúlik.
Nézd, az informatikus élet folyamatos migráció. Nem tudjuk előre, hogy pár év múlva melyik technológia lesz a nyerő. Választunk egyet és ha nem jót választottunk, akkor keresünk másikat és migrálunk. Közben pedig levonjuk a megfelelő tanulságokat.
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…
Az új dolgok tanulása az első 10 évben szórakoztató volt, a másodikban unalmas, és félek, hogy a következő 10-ben undorító lesz.
'https://youtu.be/vR7QhSo_E9k
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…
A következő javasolt videó: "Bassza meg az Isten"
Igen, azt én is csak most láttam, de vegyük úgy, hogy lazán kapcsolódik. :)
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…
Nem igazan latok a Mirantis fejebe. Azt tudom, hogy hivatalossan sunsetteltek a projektet. A docker swarm mogott nem alakult ki akkora kozosseg szerintem akik tamogast is adnanak hozza.
Szerintem egy production rendszer kapcsan ezeket erdemes merlegelni mert nem igazan egeszseges amikor eltunik egy technologia. Amugy egy k3s-t pont ugyan egyszeru belonni mint egy docker swarmot.
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer
Tudsz hozzá értelmes doksit?
Mondjuk amíg a Ranchert nem vásárolta fel a Suse, addig szerint a k3s is ugyanolyan instabil lábon állt.
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…
"Igazabol a docker swarm egy felokositott docker-compose semmi tobb igazabol osszetud fogni tobb docker konternert nagy vonalakban. "
Meg hát ugye össze tud fogni x db vasat és elosztani köztük a terhelést és containereket 2-3 egyszerű paranccsal.
"Cloud vagy on-demand infrastruktura lesz?"
Passz, jó lett volna szükség esetén váltani egyikről a másikra.
"Van fizikai vagy virtualis loadbalancer a halozatba?"
Virtuális.
"Hany darab node van? Fizikai es virtualis?"
Próbaképp 3.
"Hogyan nezki a halozati topologia?"
3 gépnél egyszerűen :-)
"Hany darab kontenert kell futtatni egy idejuleg egy nodeon?"
Előre nem tudom, attól függ ügyesek-e a programozók.
"Hany kulonbozo kontenert lesz a rendszerbe?"
Előre végképp nem tudom, attól függ, hogy a programot hogyan lehet ügyesen servicekre bontani. De max 10-20 félére számítok.
"Adatbazist is innen akarjatok futtatni vagy csak az alkalmazast? Persistance adattarolas lesz a docker kontenerek alatt?"
Igen.
"Szukseges-e titkositani az environment valtozokat?"
Passz, gondolom függ az első kérdéstől is.
"Mekkora forgalom varhato?"
Max napi kb 10.000 különálló látogató.
"Mekkora rendelkezesre allas kell?"
A lehető legnagyobb. :-)
A dolog lényege az egyszerűség lett volna és az, hogy legkisebb fájdalom mellett lehessen tologatni a rendszer a szolgáltatók vagy saját infra között. Ezeket első blikkre szépen és rettentő egyszerűen megoldotta swarm, volt hozzá összerakott 3 konténerből megoldott reverse proxy, 2-3 konténerből megoldott logolás és monitoring. Ami így összességében egy elfogadható szintű rendelkezésreállást biztosított pilótavizsga nélkül.