Прапаную азнаёміцца з расшыфроўкай дакладу Аляксандра Сігачова Service Discovery у размеркаваных сістэмах на прыкладзе Consul.
Service Discovery створаны для таго, каб з мінімальнымі выдаткамі можна падлучыць новае прыкладанне ва ўжо існуючае наша асяроддзе. Выкарыстоўваючы Service Discovery, мы можам максімальна падзяліць альбо кантэйнер у выглядзе докера, альбо віртуальны сэрвіс ад таго асяроддзя, у якім ён запушчаны.
Я ўсіх вітаю! Я Сігачоў Аляксандр, працую ў кампаніі Inventos. І сёння я вас пазнаёмлю з такім паняццем, як Service Discovery. Разгледзім мы Service Discovery на прыкладзе Consul.
Якія праблемы вырашае Service Discovery? Service Discovery створаны для таго, каб з мінімальнымі выдаткамі можна падлучыць новае прыкладанне ва ўжо існуючае наша асяроддзе. Выкарыстоўваючы Service Discovery, мы можам максімальна падзяліць альбо кантэйнер у выглядзе докера, альбо віртуальны сэрвіс ад таго асяроддзя, у якім ён запушчаны.
Як гэта выглядае? На класічным прыкладзе ў вэбе - гэта фронтэнд, які прымае запыт карыстальніка. Далей выконвае маршрутызацыю яго на backend. На дадзеным прыкладзе - гэта load-balancer балансуе на два backend.
Тут мы бачым, што мы запускаем трэці асобнік прыкладання. Адпаведна, калі праграма запускаецца, яно вырабляе рэгістрацыю ў Service Discovery. Service Discovery паведамляе load-balancer. Load-balancer мяняе свой канфіг аўтаматычна і ўжо новы backend падключаецца ў працу. Такім чынам могуць дадавацца backend, альбо, наадварот, выключацца з працы.
Што яшчэ зручна рабіць пры дапамозе Service Discovery? У Service Discovery могуць захоўвацца канфігі nginx, сертыфікаты і спіс актыўных backend-сервераў.
Таксама 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? Для таго каб атрымаць інфармацыю, ёсць два віды API у Consul.
Гэта DNS API. Па змаўчанні Consul запускаецца на 8600 порце. Мы можам наладзіць праксіраванне запыту і забяспечыць доступ праз лакальны рэзалінг, праз лакальны DNS. Мы можам запытаць па дамене і атрымаем у адказ інфармацыю аб IP-адрасе.
HTTP API - альбо мы можам лакальна на 8500 порце запытаць інфармацыю аб канкрэтным сэрвісе і атрымаем JSON адказ, які IP мае сервер, які host, які порт зарэгістраваны. І дадатковая інфармацыя можа быць перададзена праз token.
Што трэба, каб запусціць Consul?
У першым варыянце мы ў рэжыме распрацоўніка паказваем сцяг, што гэта рэжым распрацоўніка. Agent стартуе як сервер. І ўсю функцыю выконвае ўжо самастойна на адной машыне. Зручна, хутка і ніякіх дадатковых налад для першага старту не патрабуецца.
Другі рэжым - гэта запуск у production. Тут запуск крыху ўскладняецца. Калі ў нас няма ніводнай версіі консула, то мы павінны прывесці ў bootstrap першую машыну, т. е. гэтая машына, якая возьме на сябе абавязкі лідэра. Мы ўздымаем яе, затым мы ўздымаем другі асобнік сервера, перадаючы яму інфармацыю, дзе ў нас знаходзіцца майстар. Трэці падымаем. Пасля таго, як у нас паднята тры машыны, мы на першай машыне з запушчанага bootstrap, перазапускаем яе ў звычайным рэжыме. Дадзеныя сінхранізуюцца, і пачатковы кластар ужо падняты.
Рэкамендуецца запускаць ад трох да сямі асобнікаў у рэжыме сервера. Гэта абумоўліваецца тым, што калі колькасць сервераў расце, то павялічваецца час на сінхранізацыю інфармацыі паміж імі. Колькасць нод павінна быць няцотным, каб забяспечыць кворум.
Як забяспечваюцца Health Checks? У дырэкторыю для канфігурацыі Consul мы ў выглядзе Json пішам правіла праверкі. Першы варыянт - гэта даступнасць у дадзеным прыкладзе дамена google.com. І які гаворыцца, што праз інтэрвал у 30 секунд трэба выконваць гэтую праверку. Такім чынам мы правяраем, што наша нода мае доступ у знешнюю сетку.
Другі варыянт - гэта праверка сябе. Мы звычайным curl тузаем localhost па паказаным порце з інтэрвалам у 10 секунд.
Гэтыя праверкі сумуюцца і паступаюць у Service Discovery. На падставе даступнасці гэтыя ноды або выключаюцца, або з'яўляюцца ў спісе даступных і карэктна якія працуюць машынак.
Таксама Consul падае UI-інтэрфейс, які з асобным сцягам запускаецца і будзе даступны на машынцы. Гэта дазваляе праглядаць інфармацыю, а таксама можна ўносіць некаторыя змены.
У дадзеным прыкладзе адкрыта ўкладка "Сэрвіс". Паказана, што запушчана тры сэрвісы, адзін з іх Consul. Колькасць выкананых праверак. І маюцца тры дата-цэнтры, у якіх знаходзяцца машынкі.
Гэта прыклад укладкі "Nodes". Бачым, што ў іх састаўныя імёны з удзелам дата-цэнтраў. Тут таксама паказана, якія сэрвісы запушчаны, т. е. мы бачым, што тэгі не зададзены. У гэтых дадатковых тэгах можна задаць нейкую інфармацыю, якую распрацоўшчык можа выкарыстоўваць для ўказання дадатковых параметраў.
Таксама можна перадаваць інфармацыю ў Consul аб стане дыскаў, аб сярэдняй загрузцы.
пытанні
Пытанне: У нас есць докер-кантэйнер, як яго выкарыстоўваць з Consul ?
Адказ: Для докер-кантэйнера ёсць некалькі падыходаў. Адзін з самых распаўсюджаных - гэта выкарыстоўваць іншы докер-кантэйнер, які адказвае за рэгістрацыю. Пры запуску яму пракідваецца сокет докера. Усе падзеі па рэгістрацыі і дэпублікацыі кантэйнера заносяцца ў Consul.
Пытанне: Г. зн. Consul сам запускае докер-кантэйнер?
Адказ: Не. Мы запускаем докер-кантэйнер. І пры канфігурацыі паказваем - слухай вось такі сокет. Гэта прыкладна гэтак жа, як ідзе праца з сертыфікатам, калі мы пракідаем інфармацыю, дзе і што ў нас ляжыць.
Пытанне: Атрымліваецца, што ўсярэдзіне докер-кантэйнера, які мы спрабуем падлучыць да Service Discovery павінна быць нейкая логіка, якая ўмее аддаваць дадзеныя Consul?
Адказ: Не зусім. Калі ён стартуе, то мы праз пераменнае асяроддзе перадаем зменныя. Дапушчальны, сэрвіс name, сэрвіс порт. У рэгістры слухае гэтую інфармацыю і заносіць у Consul.
Пытанне: У мяне яшчэ па UI пытанне. Мы разгарнулі UI, дапусцім, на production-серверы. Што з бяспекай? Дзе захоўваюцца дадзеныя? Ці можна неяк акумуляваць дадзеныя?
Адказ: У UI як раз дадзеныя з базы і з Service Discovery. Паролі мы ставім у наладах самастойна.
Пытанне: Гэта можна публікаваць у інтэрнет?
Адказ: Па змаўчанні Consul стартуе на localhost. Каб публікаваць у гэты інтэрнэт, трэба будзе паставіць нейкі проксі. За правілы бяспекі мы адказваем самі.
Пытанне: Гістарычныя дадзеныя са скрынкі выдае? Цікава паглядзець статыстыку па Health Checks. Можна ж дыягнаставаць праблемы, калі сервер часта выходзіць са строю.
Адказ: Я ня ўпэўнены, што там ёсьць дэталі праверак.
Пытанне: Не столькі важны бягучы стан, колькі важная дынаміка.
Адказ: Для аналізу - так.
Пытанне: Service Discovery для докера Consul лепш не выкарыстоўваць?
Адказ: Я б не рэкамендаваў яго выкарыстоўваць. Мэта даклада - пазнаёміць, што ёсць такое паняцце. Гістарычна ён прайшоў шлях, па-мойму, да 1-ай версіі. Цяпер ужо ёсць больш паўнавартасныя рашэнні, напрыклад, Kubernetes, які ўсё гэта мае пад капотам. У складзе Kubernetes Service Discovery саступае Etcd. Але я з ім не так шчыльна знаёмы, як з Consul. Таму Service Discovery я вырашыў зрабіць на прыкладзе Consul.
Пытанне: Схема з серверам лідэрам не тармозіць старт прыкладання ў цэлым? І як Consul вызначае новага лідара, калі гэты ляжыць?
Адказ: У іх апісаны цэлы пратакол. Калі цікава, то можна пачытаць.
Пытанне: Consul у нас выступае паўнавартасным серверам і ўсе запыты лятаюць праз яго?
Адказ: Ён выступае не паўнавартасным серверам, а бярэ пэўную зону. Яна, як правіла, заканчваецца service.consul. І далей мы ўжо па логіцы ідзем. Мы не выкарыстоўваем у production даменныя імёны, а менавіта ўнутраную інфраструктуру, якая звычайна хаваецца за кэшаванне сервера, калі мы працуем па DNS.
Пытанне: Т. е. калі мы хочам звярнуцца да базы дадзеных, то мы ў любым выпадку будзем тузаць Consul, каб знайсці гэтую базу перш, правільна?
Адказ: Так. Калі працуем па DNS, тое гэта працуе як без Consul, калі выкарыстаем DNS імёны. Звычайна сучасныя прыкладанні не ў кожным запыце тузаюць даменнае імя, таму што мы connect ўсталявалі, усё працуе і ў бліжэйшы час мы практычна не выкарыстоўваем. Калі connect разарваўся, то так, мы зноў пытаемся, дзе ў нас ляжыць база і ідзем да яе.
- Чат карыстальнікаў Hashicorp: Consul, Nomad, Terraform
PS З нагоды health checks. У Consul як і ў Kubernetes выкарыстоўваецца аднолькавая сістэма праверкі стану жывучасці сэрвісу на аснове статут кода.
200 OK for healthy
503 Service Unavailable for unhealthyКрыніцы:
Крыніца: habr.com