Sticky Session With Docker Swarm (CE) na Debian 9

• Wprowadzenie
• Wymagania wstępne
• Kim jestem
• Konfigurowanie Traefik
• Jak to działa

Wprowadzenie

Docker Swarm zmienia Twoje indywidualne serwery w klaster komputerów; ułatwianie skalowania, wysokiej dostępności i równoważenia obciążenia. Moduł równoważenia obciążenia Swarm implementuje strategię równoważenia obciążenia w trybie round-robin, co może zakłócać prawidłowe działanie (starszych) aplikacji stanowych, które wymagają pewnej formy sesji trwałych, aby umożliwić wysoką konfigurację z wieloma instancjami. Docker Enterprise Edition obsługuje lepką sesję warstwy 7, ale w tym przewodniku skupimy się na bezpłatnej (CE) wersji Dockera. Do implementacji sesji lepkich użyjemy Traefik.

Wymagania wstępne

• Co najmniej dwie świeżo wdrożone i zaktualizowane instancje Debiana 9 w tej samej podsieci z włączoną siecią prywatną
• Docker CE zainstalowany na tych instancjach
• Instancje powinny być częścią tego samego roju i powinny mieć możliwość komunikowania się ze sobą za pośrednictwem sieci prywatnej
• Wcześniejsza znajomość Docker i Docker Swarm
• Użytkownik inny niż root z sudouprawnieniami (opcjonalnie, ale zdecydowanie nie zaleca się używania użytkownika root)

W tym samouczku będziemy używać dwóch instancji Vultr z prywatnymi adresami IP 192.168.0.100i 192.168.0.101. Oba są węzłami menedżera Docker Swarm (co nie jest idealne do produkcji, ale wystarcza do tego samouczka).

Kim jestem

W tym samouczku użyto jwilder/whoamiobrazu dokera jako aplikacji demonstracyjnej. Ten prosty kontener będzie odpowiadał na wywołanie REST o nazwie odpowiadającego kontenera, dzięki czemu bardzo łatwo będzie sprawdzić, czy sesje lepkie działają. Ten obraz jest oczywiście używany wyłącznie do celów demonstracyjnych i musi zostać zastąpiony obrazem własnej aplikacji.

Usługa whoami jest skonfigurowana w następujący sposób:

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

Jeśli następnie curlustalimy punkt końcowy REST dla whoami http://192.168.0.100/, możemy zobaczyć równoważenie obciążenia Docker Swarm w działaniu:

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

Nie ma sensu testować tego w nowoczesnych przeglądarkach, takich jak Chrome lub Firefox, ponieważ są one zaprojektowane tak, aby utrzymywać połączenia przy życiu, a moduł równoważenia obciążenia Docker Swarm przełączy się na inny pojemnik tylko przy każdym nowym połączeniu. Jeśli chcesz to przetestować w przeglądarce, musisz odczekać co najmniej 30 sekund na zakończenie połączenia przed ponownym odświeżeniem.

Konfigurowanie Traefik

Traefik natywnie obsługuje Docker Swarm, może wykrywać i rejestrować lub wyrejestrowywać kontenery w locie oraz komunikuje się z aplikacją za pośrednictwem wewnętrznej sieci nakładek. Traefik potrzebuje informacji o Twojej aplikacji, zanim będzie mógł rozpocząć obsługę żądań. Informacje te są przekazywane do Traefik poprzez dodanie etykiet do usługi 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

Poniższa lista opisuje, co oznaczają poszczególne etykiety:

• traefik.docker.network : Sieć nakładek Docker, przez którą Traefik będzie komunikował się z twoją usługą
• traefik.port : Port, na którym nasłuchuje Twoja usługa (jest to port wewnętrznie udostępniony, a nie port opublikowany)
• traefik.frontend.rule: PathPrefix:/ wiąże kontekstowy katalog główny ' /' z tą usługą
• traefik.backend.loadbalancer.stickiness : Włącza trwałe sesje dla tej usługi

Teraz, gdy whoami-serviceskonfigurowano wymagane etykiety, możemy dodać usługę Traefik do roju:

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

To polecenie wykonuje jednocześnie wiele czynności, jak pokazano na poniższej liście:

• --name traefik : Nasza nowa usługa Docker nazywa się Traefik
• -p8080:80: Publikujemy port Traefik 80do portu, 8080ponieważ port 80jest już używany przez naszą usługę whoami
• -p9090:8080 : Publikujemy własny interfejs Traefik do portu 9090
• --mount ... : Montujemy Docker Socket w kontenerze, aby Traefik mógł uzyskać dostęp do środowiska wykonawczego Docker hosta
• --global : Chcemy pojemników Traefik w każdym węźle menedżera ze względu na wysoką dostępność
• --constraint 'node.role == manager': Chcemy, aby Traefik działał tylko na węzłach menedżera, ponieważ węzły robocze nie mogą dostarczyć Traefik potrzebnych informacji. Na przykład docker service lsw węźle pracownika nie działa, więc Traefik nie byłby nawet w stanie dowiedzieć się, jakie usługi są uruchomione
• --network whoaminet: Podłącz Traefik do tej samej sieci, co nasza whoami-service, w przeciwnym razie nie będzie mógł się z nim połączyć. Wcześniej powiedzieliśmy Traefik, aby łączył się z naszym serwisem za pośrednictwem tej sieci z traefik.docker.networketykietą
• traefik : Powiedz dokerowi, aby użył najnowszego obrazu dokowanego Traefik dla tej usługi
• --docker --docker.swarmmode --docker.watch --web --loglevel=DEBUG: Argumenty wiersza poleceń przekazywane bezpośrednio do Traefik, aby umożliwić mu działanie w trybie roju Docker. DEBUGjest tutaj opcjonalny, ale interesujący podczas instalacji i dla tego samouczka

Pozostaje tylko otworzyć niezbędne porty zapory ogniowej Debiana:

sudo iptables -I INPUT 1 -p tcp --dport 8080 -j ACCEPT
sudo iptables -I INPUT 1 -p tcp --dport 9090 -j ACCEPT

Jak to działa

Gdy tylko Traefik się uruchomi, w dziennikach widać, że Traefik odkrywa dwa whoamikontenery. Wyświetla także nazwę pliku cookie, który będzie używany do obsługi sesji trwałej:

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"

Jeśli się zwiniemy http://192.168.0.100:8080, możemy zobaczyć, że ustawiony został nowy plik cookie _a49bc:

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

Jeśli podczas kolejnych połączeń wyślemy ten plik cookie do Traefik, zawsze będziemy przekierowywani do tego samego kontenera:

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

Plik cookie zawiera tylko wewnętrzny adres IP kontenera, do którego Traefik powinien wysłać żądanie. Jeśli zmienisz na wartość pliku cookie na http://10.0.0.4:8000, wówczas żądanie zostanie skutecznie przekazane do innego kontenera. Jeśli plik cookie nigdy nie byłby ponownie wysyłany do Traefik, wówczas sesja lepka nie będzie działać, a żądania będą zrównoważone między kontenerami aplikacji a kontenerami Traefik.

To wszystko, co jest potrzebne, aby skonfigurować Przyklejone sesje warstwy 7 w Docker CE na Debianie 9.