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

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

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

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

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

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

Тук виждаме, че стартираме третата инстанция на приложението. Съответно, когато приложението стартира, то се регистрира в 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. Това е консулски шаблон. Ние описваме правилото. Ние казваме, че използваме шаблон (модел за шаблони на Golang). Когато се появят събития, когато са уведомени, че са настъпили промени, то се генерира повторно и командата „презареждане“ се изпраща към Service Discovery. Най-простият пример е, когато nginx се преконфигурира при събитие и се рестартира.

Какво е консул?

• На първо място, това е Service Discovery.

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

• Той също има KV Store.

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

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

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

• Consul е услуга, написана на Go. Едно от предимствата на програмата Go е 1 двоичен файл, който току-що сте изтеглили. Стартира се отвсякъде и нямате зависимости.
• Освен това, използвайки ключовете, можем да стартираме тази услуга или в клиентски режим, или в сървърен режим.
• Освен това атрибутът "datacenter" ви позволява да зададете флаг към кой център за данни принадлежи този сървър.
• Консенсус - базиран на протокола за сала. Ако някой се интересува, може да прочете повече за това на сайта на Консул. Това е протокол, който ви позволява да определите лидера и да определите кои данни се считат за валидни и налични.
• 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?

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

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

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

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

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

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

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

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

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

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

Въпроси

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

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

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

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

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

Отговор: Не точно. Когато започне, ние предаваме променливи през средата на променливите. Да кажем име на услуга, порт на услугата. Прослушва тази информация в регистъра и я въвежда в Консул.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

200 OK for healthy
503 Service Unavailable for unhealthy

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

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