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

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

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

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

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

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

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

Какво още е удобно да се прави с помощта на 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, е, че получавате 1 бинарен файл, който просто изтегляте. Стартирате от всяко място и нямате зависимости.
• По-нататък с помощта на ключовете можем да стартираме тази услуга или в режим на клиент, или в режим на сървър.
• Също така атрибутът '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 адреса на сървъра, хоста и регистрирания порт. Допълнителна информация може да бъде предадена чрез token.

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

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

Вторият режим е стартиране в production. Тук стартирането е малко усложнено. Ако нямаме нито една версия на консула, трябва да подготвим първата машина в 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, да кажем, на производствения сървър. Какво се случва с безопасността? Къде се съхраняват данните? Може ли да се акумулират данни?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

200 OK за здрави
503 Service Unavailable за нездрави

Източници:
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