Sticky Session With Docker Swarm (CE) na CentOS 7

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

Wprowadzenie

Docker Swarm zamienia poszczególne serwery w klaster komputerów, ułatwiając skalowanie, wysoką dostępność i równoważenie 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ć konfigurację wysokiej dostępności 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 CentOS 7 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 niebędący administratorem z uprawnieniami sudo (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.100 i 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 służy wyłącznie do celów demonstracyjnych i musi zostać zastąpiony obrazem własnej aplikacji. whoami-serviceJest skonfigurowany 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 firewall-cmd --zone=public --add-port=80/tcp --permanent
sudo firewall-cmd --reload

Jeśli chcielibyśmy następnie końcowych REST co możemy zobaczyć round-robin równoważenia obciążenia z Docker Swarm w pracy.curlwhoamihttp://192.168.0.100/

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 (otwarte), a moduł równoważenia obciążenia Docker Swarm przełączy się na inny kontener 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 oznacza każda etykieta:

• 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. Poniższa lista wyjaśni bardziej szczegółowo:

• --name traefik: Nasza nowa usługa Docker nazywa się traefik
• -p8080:80: Publikujemy port Traefik 80do portu 8080(port 80jest już używany przez nasz whoami-service)
• -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: Łączy Traefik z tą samą siecią co nasza whoami-service, w przeciwnym razie nie mogą się 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 ( --loglevel=DEBUGjest tutaj opcjonalny, ale interesujący podczas instalacji i tego samouczka)

Pozostaje tylko otworzyć niezbędne porty w zaporze CentOS:

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

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 _a49bczostał ustawiony nowy plik 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

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 wartość pliku cookie na, http://10.0.0.4:8000wó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, czego potrzeba, aby skonfigurować Przyklejone sesje warstwy 7 w Docker CE na CentOS 7.