http://www.littlebigextra.com/how-to-maintain-session-persistence-sticky-session-in-docker-swarm-with-multiple-containers/<br>
Több okból is szükség lehet ráAzt elöljáróban elmondhatjuk, hogy Layer 7 reversa swarm-proxy-t tegyünk ot illetve, úgy általában a konténer cluster-ünk elé eket elsősorban stateless micorservice-ekre találták ki, ahol egymás mellett akár több tízezer stateless service példány fut, és tényleg teljesen mindegy hogy éppen melyik kapja a kérést. Ilyen méretekben nincs is értelme statefull szolgáltatásokról beszélni. A swarm mode is erre készül, a nagy számú, statless végpontok kezelésére tökéletes a swarm-ba beépített Layer 4 TCP (szállítási rétegbeli) load -balancer helyett: .., ami Round-rubin módon mindig a következő elérhető konténernek adja a feladatot.
A konténeres világban Session kezelést kétféle módon hozhatunk létre ha nagyon messziről nézzük:
* Elosztott session kezelés: minden egyes konténer, ami részt vesz a szolgáltatásban hozzáfér egy központi sesison-höz, ahonnan minden egyes hozzá beérkező request estén ki tudja olvasni, hogy hol tart a user és onnan folytatja. Ebben az esetben használható a swarm beépített Layer 4 load-balancing szolgáltatása. Azonban a szakirodalom szerint ez a megoldás nagyon rosszul skálázódik. Míg 10 láb esetén remekül működik, 10.000 láb esetén már nagyon nehézkessé válik, hogy minden node tényleg megkapja megfelelő sebességgel a legfrissebb session-t. Ez gyakorlatilag lehetetlen.
* Központosított session kezelés a load-balacer-ben: Ebben az esetben a beépített Layer 4 load-balancer értelem szerűen nem használható, ezért itt egy olyan, külső load-balancer megoldásra van szükség, ami tud sticky session-t kezelni, ezen felül képes automatikusan lekövetni a swarm cluster változásait és remekül bírja a terhelést. (akár 10.000 node-ot is).
Azonban igen is szükség van statefull szolgáltatásokra, és bár akkora cluster nem építhető belőlük mint a stateless szolgáltatásokból, kiválóan passzolnak a swarm világba.
Itt jön A konténeres cluster világban Session kezelést kétféle módon hozhatunk létre ha nagyon messziről nézzük: * '''Elosztott session kezelés''': minden egyes konténer, ami részt vesz a szolgáltatásban hozzáfér egy központi sesison tárhoz, ahonnan minden egyes hozzá beérkező request estén ki tudja olvasni, hogy hol tart a user és onnan folytatja. Ebben az esetben használható a swarm beépített Layer 4 load-balancing szolgáltatása. Azonban a szakirodalom szerint ez a megoldás nagyon rosszul skálázódik. Míg 10 láb esetén remekül működik, 1000 láb esetén már nagyon nehézkessé válik, hogy minden node tényleg megkapja megfelelő sebességgel a képbe legfrissebb session-t. Ez gyakorlatilag lehetetlen. * '''Központosított session kezelés a Traefik load-balacer-ben''': Ebben az esetben a beépített Layer 4 load-balancer értelem szerűen nem használható, ezért itt egy olyan, külső load-balancer megoldásra van szükség, ami azt állítja magáróltud sticky session-t kezelni, ezen felül képes automatikusan lekövetni a swarm cluster változásait és remekül bírja a terhelést. A session kezelésen felül, még több okunk is lehet, hogy erre találták ki. miért tegyünk egy load-balancing szolgáltatást a swarm cluster elé: * SSL/TLS termination* Content‑based routing (based, for example, on the URL or a header)* Access control and authorization* Rewrites and redirects
Itt jön a képbe a Traefik ami azt állítja magáról, hogy erre találták ki.
==Áttekintés==
