Docker Swarm publikus IP

Virtualizáció

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

( st3v3 v | 2020. 07. 13., h – 16:18 )

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 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.

( kiuka | 2020. 07. 13., h – 16:47 )

é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

( o_O v | 2020. 07. 14., k – 15:28 )

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

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

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

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.

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

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...

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.

A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.

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.

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

"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.

( akoscomp | 2020. 12. 30., sze – 10:52 )

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.