Залепваща сесия с Docker Swarm (CE) на CentOS 7

Въведение

Docker Swarm превръща вашите отделни сървъри в клъстер от компютри, улеснявайки мащабирането, високата наличност и балансирането на натоварването. Балансирането на натоварването на Swarm прилага стратегия за кръгово балансиране на натоварването и това може да попречи на правилното функциониране на (наследени) приложения с състояние, които изискват някаква форма на лепкави сесии, за да позволят настройка с висока достъпност с множество екземпляри. Docker Enterprise Edition поддържа лепкава сесия на Layer-7, но в това ръководство ще се съсредоточим върху безплатната (CE) версия на Docker. За да реализираме лепкави сесии, ще използваме Traefik.

Предпоставки

• Най-малко два току-що внедрени и актуализирани екземпляра на CentOS 7 в една и съща подмрежа с активирана частна мрежа
• Docker CE, инсталиран на тези екземпляри
• Екземплярите трябва да са част от един и същи рояк и трябва да могат да комуникират помежду си през частната мрежа
• Предварителни познания за Docker и Docker Swarm
• Потребител без администратор с sudo права (по избор, но е силно препоръчително да не използвате root потребител)

В този урок ще използваме два екземпляра на Vultr с частни IP адреси 192.168.0.100 и 192.168.0.101, като и двата са възли на Docker Swarm (което не е идеално за производство, но е достатъчно за този урок).

Кой съм аз

Този урок използва jwilder/whoamiизображението на docker като демонстрационно приложение. Този прост контейнер ще отговори на REST повикване с името на отговарящия контейнер, което го прави много лесно да се тества дали лепкавите сесии работят. Това изображение се използва само за демонстрационни цели и трябва да бъде заменено с изображение на вашето собствено приложение. В whoami-serviceе конфигуриран както следва:

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

Ако бихме впоследствие curlна whoamiкрайната точка на покой http://192.168.0.100/, можем да видим на кръгла Робин балансиране на натоварването на 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

Няма смисъл да се тества това с модерни браузъри като Chrome или Firefox, защото те са предназначени да поддържат връзките живи (отворени) и балансиращото натоварване на Docker Swarm само ще превключва към другия контейнер при всяка нова връзка. Ако искате да тествате това с браузър, ще трябва да изчакате поне 30 секунди, докато връзката се затвори, преди да опресните отново.

Настройка на Traefik

Traefik първоначално поддържа Docker Swarm, може да открива и регистрира или дерегистрира контейнери в движение и комуникира с вашето приложение през вътрешната мрежа за наслагване. Traefik се нуждае от информация за вашето приложение, преди да започне да обработва заявките за него. Тази информация се предоставя на Traefik чрез добавяне на етикети към вашата услуга 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

Списъкът по-долу описва какво означава всеки етикет:

• traefik.docker.network: Мрежата за наслагване на Docker, през която Traefik ще комуникира с вашата услуга
• traefik.port: Портът, на който вашата услуга слуша (това е вътрешно експонираният порт, а не публикуваният порт)
• traefik.frontend.rule: PathPrefix:/свързва корена на контекста /към тази услуга.
• traefik.backend.loadbalancer.stickiness: Активира лепкави сесии за тази услуга

Сега, когато whoami-serviceе конфигуриран с необходимите етикети, можем да добавим услугата Traefik към рояка:

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

Тази команда прави много неща наведнъж. Списъкът по-долу ще обясни по-подробно:

• --name traefik: Нашата нова услуга Docker се казва traefik
• -p8080:80: Публикуваме порт 80до порт на Traefik 8080(портът 80вече се използва от нашите whoami-service)
• -p9090:8080: Публикуваме собствен уеб интерфейс на Traefik за порт 9090
• --mount ...: Монтираме Docker Socket в контейнера, така че Traefik да има достъп до Docker среда за изпълнение на хоста
• --global: Искаме Traefik контейнери на всеки мениджърски възел поради причини за висока наличност
• --constraint 'node.role == manager': Искаме Traefik да работи само на мениджърски възли, защото работните възли не могат да предоставят на Traefik информацията, от която се нуждае. Например, docker service lsна работния възел не работи, така че Traefik дори няма да може да открие какви услуги се изпълняват
• --network whoaminet: Свързва Traefik към същата мрежа като нашата whoami-service, в противен случай те не могат да се свържат. По-рано казахме на Traefik да се свърже с нашата услуга през тази мрежа с traefik.docker.networkетикета
• traefik: Кажете на docker да използва най-новото изображение на Docker Traefik за тази услуга
• --docker --docker.swarmmode --docker.watch --web --loglevel=DEBUG: Аргументите на командния ред се предават директно на Traefik, за да му позволят да работи в Docker роев режим ( --loglevel=DEBUGтук е по избор, но е интересно по време на настройката и за този урок)

Всичко, което остава да направите, е да отворите необходимите портове в защитната стена на 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

Как работи

Веднага след като Traefik стартира, можете да видите в журналите, че Traefik открива двата whoamiконтейнера. Той също така извежда името на бисквитката, която ще използва за обработка на лепкавата сесия:

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"

Ако се свием до, http://192.168.0.100:8080можем да видим, че _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

Ако при последващи обаждания изпратим тази бисквитка до Traefik, винаги ще бъдем препратени към същия контейнер:

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

Бисквитката не съдържа нищо друго освен вътрешния (наслагване) IP адрес на контейнера, до който Traefik трябва да изпрати за заявка. Ако промените стойността на бисквитката на, http://10.0.0.4:8000тогава заявката ефективно ще бъде препратена към другия контейнер. Ако бисквитката никога не бъде изпратена повторно до Traefik, тогава лепкавата сесия няма да работи и заявките ще бъдат балансирани между контейнерите на приложението и контейнерите Traefik.

Това е всичко, което е необходимо, за да настроите Layer 7 Sticky Sessions в Docker CE на CentOS 7.