Service Discovery в разпределени системи на примера на Consul. Александър Сигачев

Предлагам да се запознаете с разшифровката на доклада на Александър Сигачев за Service Discovery в разпределените системи на примера на Consul.

Service Discovery е създаден с цел минимизиране на разходите при свързване на ново приложение в вече съществуващата ни среда. Използвайки Service Discovery, можем максимално да разделим или контейнера в Docker формат, или виртуалния сервис от средата, в която е стартиран.

Здравейте на всички! Аз съм Александър Сигачев, работя в компанията Inventos. И днес ще ви запозная с понятието Service Discovery. Ще разгледаме Service Discovery на примера на Consul.

Какви проблеми решава Service Discovery? Service Discovery е създаден с цел минимизиране на разходите при свързване на ново приложение в вече съществуващата ни среда. Използвайки Service Discovery, можем максимално да разделим или контейнера в Docker формат, или виртуалния сервис от средата, в която е стартиран.

Как изглежда това? На класическия пример в уебсайта – това е фронтенд, който приема заявка от потребителя. След това извършва маршрутизацията към бекенда. В този пример – load-balancer разпределя трафика между два бекенда.

Тук виждаме, че стартираме третия екземпляр на приложението. Съответно, когато приложението стартира, то извършва регистрация в Service Discovery. Service Discovery уведомява load-balancer. Load-balancer автоматично променя конфигурацията си и новият бекенд започва да работи. По този начин могат да се добавят бекенди или, напротив, да се изключват от работа.

Какво още е удобно да правим с помощта на Service Discovery? В Service Discovery могат да се съхраняват конфигурации на nginx, сертификати и списък с активни бекенд-сървъри.

Също така, Service Discovery позволява откритие на отказ, установяване на аварии. Кои са възможните схеми за откриване на откази?

• Това е приложението, което разработихме, което уведомява Service Discovery, че е все още работоспособно.
• Service Discovery от своя страна опрашва приложението за наличност.
• Или се използва външен скрипт или приложение, което проверява наличността на нашето приложение и уведомява Service Discovery, че е всичко наред и може да работи, или, напротив, че нещата не са добре и е необходимо този екземпляр на приложението да бъде изключен от балансировката.

Всяка от схемите може да се прилага в зависимост от софтуера, който използваме. Например, ако току-що сме започнали нов проект, можем лесно да осигурим схема, при която нашето приложение уведомява Service Discovery. Или можем да настроим, че Service Discovery извършва проверка.

Ако приложението е наследство или е разработено от трета страна, тогава подхожда третият вариант, при който пишем обработчик, и всичко това се автоматизира в нашата работа.

Това е един от примерите. Load-balancer под формата на nginx се рестартира. Това е допълнителен инструмент, който се предоставя заедно с Consul. Това е consul-template. Описваме правило. Казваме, че използваме шаблон ( шаблонизатор Golang). При събития, при уведомления за настъпили промени, той се регенерира и Service Discovery получава команда „reload“. Най-простият пример е, когато при събитие се конфигурира отново nginx и се рестартира.

Какво е Consul?

• Първо и преди всичко – това е Service Discovery.

• Той има механизъм за проверка на наличността – Health Checking.

• Също така разполага с KV Store.

• И в основата му е заложена възможността за използване на Multi Datacenter.

За какво може да се използва всичко това? В KV Store можем да съхраняваме примери на конфигурации. С помощта на Health Checking можем да извършваме проверки на локалната услуга и да уведомяваме. Multi Datacenter се използва, за да можем да построим карта на услугите. Например, Amazon притежава няколко зони и насочва трафика по оптимален начин, за да не се генерират излишни заявки между дата-центровете, които се таксуват отделно от локалния трафик и съответно имат по-ниска латентност.

Нека малко се запознаем с термините, които се използват в Consul.

• Consul е услуга, написана на Go. Едно от предимствата на програмите на Go е, че имате един бинарен файл, който просто сваляте. Стартирате от всяко място и нямате зависимости.
• След това с помощта на ключове можем да стартираме тази услуга или в режим на клиент, или в режим на сървър.
• Също така атрибутът „datacenter“ позволява да се обозначи към кой дата-център принадлежи този сървър.
• Consensus се базира на протокола raft. Ако някой се интересува, може да прочете повече за него на сайта на Consul. Това е протокол, който позволява да се определи лидер и да се уточнят кои данни да се считат за валидни и налични.
• Gossip – това е протокол, който осигурява взаимодействие между възлите. И тази система е децентрализирана. В рамките на един дата център, всички възли общуват със съседите си. И, съответно, информацията за актуалното състояние се предава помежду им. Можем да кажем, че това са клюки между съседите.
• LAN Gossip – локален обмен на данни между съседите в рамките на един дата център.
• WAN Gossip – използва се, когато е необходимо да синхронизираме информацията между два дата центъра. Информацията минава между възлите, които са маркирани като сървъри.
• RPC – позволява да изпълняваме заявки от клиента към сървъра.

Описание на RPC. Да предположим, че на виртуална машина или физически сървър е стартиран Consul в режим на клиент. Обращаме се локално към него. А след това локалният клиент запитва информация от сървъра и синхронизира. Информацията в зависимост от настройките може да бъде предоставена от локалния кеш или да бъде синхронизирана с лидера, с главния сървър.

Тези две схеми имат както предимства, така и недостатъци. Ако работим с локалния кеш, то това е бързо. Ако работим с данните, които се съхраняват на сървъра, то отнема повече време, но получаваме по-актуална информация.

Ако това бъде визуализирано графически, ще изглежда така. Виждаме, че имаме стартирани три лидера. Един е обозначен със звездичка като лидер. В този пример три клиента обменят локално информация помежду си чрез UDP/TCP. А информацията между дата центровете се предава между сървърите. Тук клиентите взаимодействат помежду си локално.

Какъв API предоставя Consul? За да получим информация, Consul предлага два вида API.

Това е DNS API. По подразбиране Consul стартира на порт 8600. Можем да конфигурираме прокси за заявките и да осигурим достъп чрез локално разрешаване, чрез локален DNS. Можем да запитаме по домейн и ще получим информация за IP адреса в отговор.

HTTP API – или можем локално на порт 8500 да поискате информация за конкретна услуга и ще получим JSON отговор, какъв IP адрес има сървърът, какъв хост, какъв порт е регистриран. И допълнителна информация може да бъде предадена чрез токен.

Какво е необходимо, за да стартирате Consul?

В първия вариант стартираме в режим на разработчик, указвайки флаг, че това е режим на разработчик. Agent стартира като сървър. И цялата функция вече я изпълнява самостоятелно на една машина. Удобно е, бързо е и практически не са необходими допълнителни настройки за първоначален старта.

Вторият режим е стартиране в продукция. Тук стартирането е малко по-сложно. Ако нямаме нито една версия на консула, трябва да подготвим първата машина за bootstrap, т.е. тази машина, която поема функциите на лидер. Започваме я, след което стартираме втори екземпляр на сървъра, предавайки му информация къде се намира мастерът. Започваме трети. След като имаме три машини, на първата машина от стартирания bootstrap, я рестартираме в нормален режим. Данните се синхронизират и началният клъстер е вече активен.

Препоръчва се да се стартират от три до седем екземпляра в режим на сървър. Това е обусловено от това, че ако броят на сървърите расте, времето за синхронизиране на информацията между тях се увеличава. Броят на нодовете трябва да бъде нечетен, за да се осигури кворум.

Как се осигуряват Health Checks? В директорията за конфигурация на Consul създаваме правило за проверка под формата на JSON. Първият вариант е достъпността на домейна google.com. И казваме, че на всеки 30 секунди трябва да се извършва тази проверка. Така проверяваме, че нашата нода има достъп до външната мрежа.

Вторият вариант е проверка на самия себе си. Използваме обикновен curl, за да проверим localhost на посочения порт с интервал от 10 секунди.

Тези проверки се сумират и постъпват в Service Discovery. На база на наличността, тези ноди или се изключват, или се появяват в списъка на наличните и коректно работещи машини.

Също така, Consul предоставя UI интерфейс, който се стартира с отделен флаг и ще бъде достъпен на машината. Това позволява да се преглежда информация, както и да се внасят някои промени.

В този пример е отворен раздел 'Сервиз'. Показано е, че са стартирали три услуги, една от които е Consul. Броят на изпълнените проверки. И има три дата центъра, в които се намират машините.

Това е пример за раздела «Nodes». Виждаме, че те имат съставни имена, свързани с дата-центрове. Тук също е показано кои услуги са активирани, т.е. виждаме, че етикетите не са зададени. В тези допълнителни етикети можем да зададем информация, която разработчикът може да използва за указване на допълнителни параметри.

Също така можем да предаваме информация в Consul за състоянието на дисковете, за средната натовареност.

Въпроси

Въпрос: Имаме ли Docker контейнер, как да го използваме с Consul?

Отговор: За Docker контейнера има няколко подхода. Един от най-разпространените е да се използва външен Docker контейнер, отговарящ за регистрацията. При стартирането му се предава сокет от Docker. Всички събития по регистрация и отмяна на контейнера се записват в Consul.

Въпрос: Тоест, Consul сам стартира Docker контейнера?

Отговор: Не. Ние стартираме Docker контейнера. И при конфигурацията указваме – следи този сокет. Това е приблизително като работа със сертификат, когато предаваме информация за това къде и какво имаме.

Въпрос: Получава се, че вътре в Docker контейнера, който се опитваме да свържем с Service Discovery, трябва да има някаква логика, която да може да предоставя данни на Consul?

Отговор: Не съвсем. Когато той стартира, чрез променливи на средата предаваме променливи. Например, име на услугата, порт на услугата. Регистърът следи тази информация и я записва в Consul.

Въпрос: Имам и въпрос за потребителския интерфейс. Разгръщали сме UI, да кажем, на продукционен сървър. Какво е положението със сигурността? Къде се съхраняват данните? Може ли по някакъв начин да се акумулират данни?

Отговор: В UI всъщност данните идват от базата и от Service Discovery. Паролите настройваме сами в настройките.

Въпрос: Може ли това да се публикува в интернет?

Отговор: По подразбиране Consul стартира на localhost. За да го публикуваме в интернет, ще трябва да настроим някакъв прокси. За правилата за сигурност отговаряме сами.

Въпрос: Историческите данни излизат ли от кутията? Интересно е да се види статистика за Health Checks. Може да се диагностицират проблеми, ако сървърът често излиза от строя.

Отговор: Не съм сигурен, че там има подробности за проверките.

Въпрос: Не толкова важно е текущото състояние, колкото важна е динамиката.

Отговор: За анализ – да.

Въпрос: Service Discovery за Docker не е по-добре да се използва с Consul?

Отговор: Не бих го препоръчал за употреба. Целта на доклада е да ни запознае с понятието. Исторически той е преминал пътя до версия 1. Вече съществуват и по-функционални решения, например, Kubernetes, който покрива всичко това. В частта за Service Discovery, Kubernetes отстъпва на Etcd. Но не съм толкова запознат с него, колкото с Consul. Затова реших да направя пример с Consul за Service Discovery.

Въпрос: Схемата с лидерския сървър не забавя ли стартирането на приложението като цяло? И как Consul определя новия лидер, ако този е паднал?

Отговор: Те имат описан цял протокол. Ако ви интересува, можете да го прочетете.

Въпрос: Consul служи ли ни като пълен сървър и всички заявки минават през него?

Отговор: Той не е пълен сървър, а обхваща определена зона. Тя обикновено завършва с service.consul. И оттам нататък следваме логиката. Ние не използваме домейни в продукционна среда, а именно вътрешната инфраструктура, която обикновено е скрита зад кеширането на сървъра, ако работим с DNS.

Въпрос: Т.е. ако искаме да се свържем с база данни, ние винаги ще питаме Consul, за да я намерим на първо място, нали?

Отговор: Да. Ако работим с DNS, това работи и без Consul, когато използваме DNS имена. Обикновено съвременните приложения не питат домейн името при всяка заявка, защото вече сме установили свързаност и в близко време практически не го използваме. Ако свързаността е прекъсната, да, питаме отново къде е нашата база и отиваме към нея.

Чат за продуктите на Hashicorp — Чат на потребители на Hashicorp: Consul, Nomad, Terraform

P.S. За health checks. В Consul, както и в Kubernetes, се използва една и съща система за проверка на състоянието на услугата въз основа на статус код.

200 OK за здрави
503 Услуга недостъпна за нездрави

Източници:
https://www.consul.io/docs/agent/checks.html
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
https://thoslin.github.io/microservice-health-check-in-kubernetes/

Източник: habr.com