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?
- 609 megtekintés
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?
- A hozzászóláshoz be kell jelentkezni
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).
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
A Docker Swarm nem menedzseli a hoszt hálózatát. Mert nem ez a dolga.
A metallb meg igen, ez a dolga.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Így van. Összedobtam rá egy programot, max 100-150 sor, csak furcsa volt hogy nem találok rá kész cuccot.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
é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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Sajnos nincs.
A K8s / CNCF halozati megoldasai erosen fejlodokepesek. Kerdes, hogy mennyire a CaaS / infrastruktura feladata megoldani a problemat.
- A hozzászóláshoz be kell jelentkezni
Traefik? https://containo.us/traefik/
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
Nem értek hozzá, hogyan tudja ezt kezelni? Nézegettem, de pont az IP kezelést nem láttam benne.
- A hozzászóláshoz be kell jelentkezni
Jól látod. Ez a cluster-re már beesett forgalom elosztására van, a kérdésedre pont nem válasz :)
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Akkor jól gondoltam/értettem... :-/ A második résszel - nem csak emiatt - egyetértek.
- A hozzászóláshoz be kell jelentkezni
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.
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
2019 november: https://www.mirantis.com/blog/mirantis-acquires-docker-enterprise-platf…
What About Docker Swarm?
The primary orchestrator going forward is Kubernetes. Mirantis is committed to providing an excellent experience to all Docker Enterprise platform customers and currently expects to support Swarm for at least two years, depending on customer input into the roadmap. Mirantis is also evaluating options for making the transition to Kubernetes easier for Swarm users.
Azaz leginkább nem lehet tudni, mi lesz vele, merre megy a jövőben...
- A hozzászóláshoz be kell jelentkezni
A fent linkelt írás pont erről szól.
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
Persze, de ettől még jelen pillanatban tele a faszom.
Holnapra elmúlik.
- A hozzászóláshoz be kell jelentkezni
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.
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
A következő javasolt videó: "Bassza meg az Isten"
- A hozzászóláshoz be kell jelentkezni
Igen, azt én is csak most láttam, de vegyük úgy, hogy lazán kapcsolódik. :)
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Tudsz hozzá értelmes doksit?
- A hozzászóláshoz be kell jelentkezni
Mondjuk amíg a Ranchert nem vásárolta fel a Suse, addig szerint a k3s is ugyanolyan instabil lábon állt.
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
Régi téma, de választ nem kaptál. Az ip gépek közti mozgatására a VRRP vagy CARP a megoldás.
Hogy alakult a swarm klasztered?
Én is épp 3-5 bare metal szerveren (2xXeon, 128 gb ram) akarok kialakítani valamit ami több mint a docker. A k8s-ről én úgy gondolom, hogy túl nagy overhead-et jelent, de tény, hogy jóval elterjedtebb, tehát valószínű az a jövő.
A swarm előnye az egyszerűség. Egy rendes Kubernetes-t szerintem még hónapokba telik production szinten beüzemelni, a swarm az szerintem megvan 1 hónap alatt.
Kubernetes-hez tud valaki esetleg rendes doksit, hogy kell saját szerveren production szinten kiépíteni? Pl. nincs tippem sem rá, hogy tudok 5 mailszervert futtatni benne, ilyen esetben, hogy néz ki a load balancer vagy a külső hálózat, stb. Ilyen kérdésekre neten nem találtam választ.
- A hozzászóláshoz be kell jelentkezni
Egyetértek amúgy, én is docker swarm-al csinálnám ha nincs rá végtelen idő.
Ha k8s akkor rancher.com, sokat segít.
zászló, zászló, szív
- A hozzászóláshoz be kell jelentkezni