Sticky Session With Docker Swarm (CE) på CentOS 7

Introduksjon

Docker Swarm gjør dine individuelle servere til en klynge av datamaskiner, noe som letter skalering, høy tilgjengelighet og belastningsbalansering. Swarm load-balancer implementerer en round-robin lastbalanseringsstrategi, og dette kan forstyrre riktig funksjon av (legacy) stateful applikasjoner som krever en form for klebrige økter for å tillate et høytilgjengelighetsoppsett med flere forekomster. Docker Enterprise Edition støtter Layer-7 sticky session, men i denne veiledningen vil vi fokusere på den gratis (CE) versjonen av Docker. For å implementere klissete økter bruker vi Traefik.

Forutsetninger

• Minst to nylig distribuerte og oppdaterte CentOS 7-forekomster i samme undernett med privat nettverk aktivert
• Docker CE installert på disse forekomstene
• Forekomstene skal være en del av samme Swarm og skal kunne kommunisere med hverandre over det private nettverket
• Forkunnskaper om Docker og Docker Swarm
• En ikke-admin-bruker med sudo-rettigheter (valgfritt, men det anbefales på det sterkeste å ikke bruke root-brukeren)

I denne opplæringen skal vi bruke to Vultr-forekomster med private IP-adresser 192.168.0.100 og 192.168.0.101, begge er Docker Swarm-managernoder (som ikke er ideell for produksjon, men nok for denne opplæringen).

Hvem er jeg

Denne opplæringen bruker jwilder/whoamidocker-bildet som demoapplikasjon. Denne enkle beholderen vil svare på et REST-anrop med navnet på den svare beholderen, noe som gjør det veldig enkelt å teste om de klissete øktene fungerer. Dette bildet brukes kun til demoformål og må erstattes av ditt eget programs bilde. Den whoami-serviceer konfigurert som følger:

sudo docker network create whoaminet -d overlay
sudo docker service create --name whoami-service --mode global --network whoaminet --publish "80:8000" jwilder/whoami
sudo firewall-cmd --zone=public --add-port=80/tcp --permanent
sudo firewall-cmd --reload

Hvis vi skulle senere curlpå whoamiREST endepunkt på http://192.168.0.100/, vi kan se round-robin lastbalansering av Docker sverm på jobb.

curl http://192.168.0.100
I'm a6a8c9294fc3
curl http://192.168.0.100
I'm ae9d1763b4ad
curl http://192.168.0.100
I'm a6a8c9294fc3
curl http://192.168.0.100
I'm ae9d1763b4ad
curl http://192.168.0.100
I'm a6a8c9294fc3

Det nytter ikke å teste dette med moderne nettlesere som Chrome eller Firefox fordi de er designet for å holde tilkoblinger i live (åpne) og Docker Swarm load-balancer vil bare bytte til den andre beholderen ved hver ny tilkobling. Hvis du vil teste dette med en nettleser, må du vente i minst 30 sekunder før tilkoblingen lukkes før du oppdaterer igjen.

Sette opp Traefik

Traefik støtter Docker Swarm, den kan oppdage og registrere eller avregistrere containere mens du er på farten, og den kommuniserer med applikasjonen din over det interne overleggsnettverket. Traefik trenger litt informasjon om søknaden din før den kan begynne å håndtere forespørsler om den. Denne informasjonen gis til Traefik ved å legge til etiketter til Swarm-tjenesten din.

sudo docker service update --label-add "traefik.docker.network=whoaminet" --label-add "traefik.port=8000" --label-add "traefik.frontend.rule=PathPrefix:/" --label-add "traefik.backend.loadbalancer.stickiness=true" whoami-service

Listen nedenfor beskriver hva hver etikett betyr:

• traefik.docker.network: Docker-overleggsnettverket som Traefik vil kommunisere med tjenesten din over
• traefik.port: Porten som tjenesten din lytter til (dette er den internt eksponerte porten, ikke den publiserte porten)
• traefik.frontend.rule: PathPrefix:/binder kontekstroten /til denne tjenesten.
• traefik.backend.loadbalancer.stickiness: Aktiverer selvklebende økter for denne tjenesten

Nå som whoami-serviceer konfigurert med de nødvendige etikettene, kan vi legge til Traefik-tjenesten til svermen:

sudo docker service create --name traefik -p8080:80 -p9090:8080 --mount type=bind,source=/var/run/docker.sock,destination=/var/run/docker.sock --mode=global --constraint 'node.role == manager' --network whoaminet traefik --docker --docker.swarmmode --docker.watch --web --loglevel=DEBUG

Denne kommandoen gjør ganske mange ting samtidig. Listen nedenfor vil forklare mer detaljert:

• --name traefik: Vår nye Docker-tjeneste heter traefik
• -p8080:80: Vi publiserer Traefiks port 80til port 8080(port 80er allerede i bruk av vår whoami-service)
• -p9090:8080: Vi publiserer Traefiks eget webgrensesnitt til port 9090
• --mount ...: Vi monterer Docker Socket inn i containeren slik at Traefik kan få tilgang til vertens Docker runtime
• --global: Vi ønsker Traefik-beholdere på hver managernode av høye tilgjengelighetsgrunner
• --constraint 'node.role == manager': Vi vil bare at Traefik skal kjøre på ledernoder fordi arbeidernoder ikke kan gi Traefik den informasjonen den trenger. For eksempel, docker service lspå en arbeider node fungerer ikke, så Traefik ville ikke engang kunne oppdage hvilke tjenester som kjører
• --network whoaminet: Kobler Traefik til samme nettverk som vår whoami-service, ellers kan de ikke koble seg til. Vi har tidligere fortalt Traefik å koble til tjenesten vår over dette nettverket med traefik.docker.networketiketten
• traefik: Be docker om å bruke det nyeste Traefik docker-bildet for denne tjenesten
• --docker --docker.swarmmode --docker.watch --web --loglevel=DEBUG: Kommandolinjeargumenter sendt direkte til Traefik for å la den kjøre i Docker-svermmodus ( --loglevel=DEBUGer valgfritt her, men interessant under oppsett og for denne opplæringen)

Alt som gjenstår å gjøre er å åpne de nødvendige portene i CentOS-brannmuren:

sudo firewall-cmd --zone=public --add-port=8080/tcp --permanent
sudo firewall-cmd --zone=public --add-port=9090/tcp --permanent
sudo firewall-cmd --reload

Hvordan det fungerer

Så snart Traefik starter opp, kan du se i loggene at Traefik oppdager de to whoamicontainerne. Den sender også ut navnet på informasjonskapselen som den vil bruke til å håndtere den klissete økten:

time="2018-11-25T13:17:30Z" level=debug msg="Configuration received from provider docker: {\"backends\":{\"backend-whoami-service\":{\"servers\":{\"server-whoami-service-1-a179b2e38a607b1127e5537c2e614b05\":{\"url\":\"http://10.0.0.5:8000\",\"weight\":1},\"server-whoami-service-2-df8a622478a5a709fcb23c50e689b5b6\":{\"url\":\"http://10.0.0.4:8000\",\"weight\":1}},\"loadBalancer\":{\"method\":\"wrr\",\"stickiness\":{}}}},\"frontends\":{\"frontend-PathPrefix-0\":{\"entryPoints\":[\"http\"],\"backend\":\"backend-whoami-service\",\"routes\":{\"route-frontend-PathPrefix-0\":{\"rule\":\"PathPrefix:/\"}},\"passHostHeader\":true,\"priority\":0,\"basicAuth\":null}}}"
time="2018-11-25T13:17:30Z" level=debug msg="Wiring frontend frontend-PathPrefix-0 to entryPoint http"
time="2018-11-25T13:17:30Z" level=debug msg="Creating backend backend-whoami-service"
time="2018-11-25T13:17:30Z" level=debug msg="Adding TLSClientHeaders middleware for frontend frontend-PathPrefix-0"
time="2018-11-25T13:17:30Z" level=debug msg="Creating load-balancer wrr"
time="2018-11-25T13:17:30Z" level=debug msg="Sticky session with cookie _a49bc"
time="2018-11-25T13:17:30Z" level=debug msg="Creating server server-whoami-service-1-a179b2e38a607b1127e5537c2e614b05 at http://10.0.0.5:8000 with weight 1"
time="2018-11-25T13:17:30Z" level=debug msg="Creating server server-whoami-service-2-df8a622478a5a709fcb23c50e689b5b6 at http://10.0.0.4:8000 with weight 1"
time="2018-11-25T13:17:30Z" level=debug msg="Creating route route-frontend-PathPrefix-0 PathPrefix:/"
time="2018-11-25T13:17:30Z" level=info msg="Server configuration reloaded on :80"
time="2018-11-25T13:17:30Z" level=info msg="Server configuration reloaded on :8080"

Hvis vi krøller til kan http://192.168.0.100:8080vi se at en ny informasjonskapsel _a49bcer satt:

curl -v http://192.168.0.100:8080
* About to connect() to 192.168.0.100 port 8080 (#0)
*   Trying 192.168.0.100...
* Connected to 192.168.0.100 (192.168.0.100) port 8080 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: 192.168.0.100:8080
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Length: 17
< Content-Type: text/plain; charset=utf-8
< Date: Sun, 25 Nov 2018 13:18:40 GMT
< Set-Cookie: _a49bc=http://10.0.0.5:8000; Path=/
<
I'm a6a8c9294fc3
* Connection #0 to host 192.168.0.100 left intact

Hvis vi ved senere samtaler sender denne informasjonskapselen til Traefik, vil vi alltid bli videresendt til samme beholder:

curl http://192.168.0.100:8080 --cookie "_a49bc=http://10.0.0.5:8000"
I'm a6a8c9294fc3
curl http://192.168.0.100:8080 --cookie "_a49bc=http://10.0.0.5:8000"
I'm a6a8c9294fc3
curl http://192.168.0.100:8080 --cookie "_a49bc=http://10.0.0.5:8000"
I'm a6a8c9294fc3
curl http://192.168.0.100:8080 --cookie "_a49bc=http://10.0.0.5:8000"
I'm a6a8c9294fc3

Informasjonskapselen inneholder ingenting annet enn den interne, (overlegg), IP-adressen til beholderen som Traefik skal sende til for å be om. Hvis du endrer informasjonskapselverdien til, http://10.0.0.4:8000vil forespørselen i praksis bli videresendt til den andre beholderen. Hvis informasjonskapselen aldri skulle sendes til Traefik på nytt, vil ikke den klebrige økten fungere og forespørsler vil balanseres mellom applikasjonens beholdere og Traefik-beholderne.

Det er alt som trengs for å sette opp Layer 7 Sticky Sessions i Docker CE på CentOS 7.