introduzione
Docker Swarm trasforma i tuoi singoli server in un cluster di computer; facilitando il ridimensionamento, l'alta disponibilità e il bilanciamento del carico. Il bilanciamento del carico Swarm implementa una strategia di bilanciamento del carico round robin e ciò potrebbe interferire con il corretto funzionamento delle applicazioni state legacy che richiedono una qualche forma di sessioni permanenti per consentire un'installazione ad alta disponibilità con più istanze. Docker Enterprise Edition supporta la sessione appiccicosa di livello 7, ma in questa guida ci concentreremo sulla versione gratuita (CE) di Docker. Per implementare sessioni appiccicose useremo Traefik.
Prerequisiti
- Almeno due istanze Debian 9 appena distribuite e aggiornate nella stessa sottorete con rete privata abilitata
- Docker CE installato su queste istanze
- Le istanze dovrebbero far parte dello stesso Swarm e dovrebbero essere in grado di comunicare tra loro tramite la rete privata
- Conoscenza pregressa di Docker e Docker Swarm
- Un utente non root con
sudodiritti (facoltativo ma si consiglia vivamente di non utilizzare l'utente root)
In questo tutorial utilizzeremo due istanze Vultr con indirizzi IP privati 192.168.0.100e 192.168.0.101. Entrambi sono nodi del gestore Docker Swarm (che non è l'ideale per la produzione ma abbastanza per questo tutorial).
Chi sono
Questo tutorial utilizza l' jwilder/whoamiimmagine docker come un'applicazione demo. Questo semplice contenitore risponderà a una chiamata REST con il nome del contenitore rispondente, rendendo molto semplice verificare se le sessioni adesive funzionano. Questa immagine è ovviamente utilizzata solo a scopo dimostrativo e deve essere sostituita dall'immagine della propria applicazione.
Il servizio whoami è configurato come segue:
sudo docker network create whoaminet -d overlay
sudo docker service create --name whoami-service --mode global --network whoaminet --publish "80:8000" jwilder/whoami
sudo iptables -I INPUT 1 -p tcp --dport 80 -j ACCEPT
Se successivamente curlarriviamo all'endpoint REST whoami http://192.168.0.100/, possiamo vedere al lavoro il bilanciamento del carico round robin di Docker Swarm:
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
Non è utile testarlo con browser moderni come Chrome o Firefox perché sono progettati per mantenere attive le connessioni e il bilanciamento del carico Docker Swarm passerà all'altro contenitore solo su ogni nuova connessione. Se si desidera testarlo con un browser, è necessario attendere almeno 30 secondi per chiudere la connessione prima di aggiornare nuovamente.
Installazione di Traefik
Traefik supporta in modo nativo Docker Swarm, è in grado di rilevare e registrare o annullare la registrazione dei container al volo e comunica con l'applicazione tramite la rete di overlay interna. Traefik necessita di alcune informazioni sull'applicazione prima che possa iniziare a gestire le richieste per essa. Queste informazioni vengono fornite a Traefik aggiungendo etichette al servizio Swarm:
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
L'elenco seguente descrive il significato di ciascuna etichetta:
traefik.docker.network : La rete overlay Docker, su cui Traefik comunicherà con il tuo servizio
traefik.port : La porta su cui è in ascolto il servizio (questa è la porta esposta internamente, non la porta pubblicata)
traefik.frontend.rule: PathPrefix:/ lega la root di contesto ' /' a questo servizio
traefik.backend.loadbalancer.stickiness : Abilita sessioni permanenti per questo servizio
Ora che whoami-serviceè stato configurato con le etichette richieste, possiamo aggiungere il servizio Traefik allo sciame:
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
Questo comando fa molte cose contemporaneamente, come mostrato nel seguente elenco:
--name traefik : Il nostro nuovo servizio Docker si chiama Traefik
-p8080:80: Pubblichiamo la porta di Traefik 80su porta 8080perché la porta 80è già in uso dal nostro servizio whoami
-p9090:8080 : Pubblichiamo l'interfaccia Web di Traefik sulla porta 9090
--mount ... : Montiamo il Docker Socket nel container in modo che Traefik possa accedere al runtime Docker dell'host
--global : Vogliamo contenitori Traefik su ciascun nodo gestore per motivi di alta disponibilità
--constraint 'node.role == manager': Vogliamo che Traefik sia eseguito solo su nodi manager perché i nodi worker non possono fornire a Traefik le informazioni di cui ha bisogno. Ad esempio, docker service lssu un nodo di lavoro non funziona, quindi Traefik non sarebbe nemmeno in grado di scoprire quali servizi sono in esecuzione
--network whoaminet: Collega Traefik alla stessa rete della nostra whoami-service, altrimenti non può connettersi ad essa. In precedenza avevamo detto a Traefik di connettersi al nostro servizio su questa rete con l' traefik.docker.networketichetta
traefik : Dì alla finestra mobile di utilizzare l'ultima immagine della finestra mobile Traefik per questo servizio
--docker --docker.swarmmode --docker.watch --web --loglevel=DEBUG: Argomenti della riga di comando passati direttamente a Traefik per consentirgli di funzionare in modalità sciame Docker. DEBUGè facoltativo qui, ma interessante durante l'installazione e per questo tutorial
Tutto quello che resta da fare è aprire le porte necessarie nel firewall Debian:
sudo iptables -I INPUT 1 -p tcp --dport 8080 -j ACCEPT
sudo iptables -I INPUT 1 -p tcp --dport 9090 -j ACCEPT
Come funziona
Non appena Traefik si avvia, è possibile vedere nei registri che Traefik scopre i due whoamicontenitori. Fornisce anche il nome del cookie che utilizzerà per gestire la sessione adesiva:
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"
Se ci rannicchiamo http://192.168.0.100:8080possiamo vedere che _a49bcè stato impostato un nuovo cookie :
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
Se, nelle chiamate successive, inviamo questo cookie a Traefik, verremo sempre inoltrati allo stesso contenitore:
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
Il cookie non contiene altro che l'indirizzo IP interno del contenitore a cui Traefik deve inviare per richiedere. Se si passa al valore del cookie in http://10.0.0.4:8000, la richiesta verrà effettivamente inoltrata all'altro contenitore. Se il cookie non dovesse mai essere reinviato a Traefik, la sessione adesiva non funzionerà e le richieste verranno bilanciate tra i contenitori dell'applicazione e i contenitori Traefik.
Questo è tutto ciò che è necessario per impostare sessioni adesive di livello 7 in Docker CE su Debian 9.