Ju lutem shikoni përkthimin e raportit të Aleksandër Sigachev mbi Service Discovery në sistemet e shpërndara duke përdorur shembujt e Consul.
Service Discovery krijohet për të lidhur aplikacione të reja me kosto minimale në një ambient ekzistues. Duke përdorur Service Discovery, ne mund të ndajmë maksimalisht një kontenier si docker ose një shërbim virtual nga ambienti në të cilin është aktiv.
Përshëndetje të gjithëve! Unë jam Aleksandër Sigachev, punoj në kompaninë Inventos. Sot do t'ju njoh me konceptin e Service Discovery. Do ta shqyrtojmë Service Discovery duke u fokusuar në shembujt e Consul.
Cilat janë problemet që zgjidh Service Discovery? Service Discovery është krijuar për të lidhur aplikacione të reja në një ambient ekzistues me kosto minimale. Duke përdorur Service Discovery, ne mund të ndajmë maksimalisht një kontenier si docker ose një shërbim virtual nga ambienti në të cilin është aktiv.
Si duket kjo? Në një shembull klasik në internet – është frontend-i që merr kërkesën e përdoruesit. Më pas, ai e drejton atë në backend. Në këtë rast, load-balancer-i balancojë mes dy backend-eve.
Këtu shohim se ne po lançojmë një ekzemplar të tretë të aplikacionit. Kur aplikacioni aktivizohet, ai regjistrohet në Service Discovery. Service Discovery e informon load-balancer-in. Load-balancer-i automatikisht ndryshon konfigurimin e tij dhe backend-i i ri fillon të punojë. Kështu, mund të shtojmë backend-e, ose përndryshe, t'i përjashtojmë ato nga puna.
Çfarë është gjithashtu e lehtë të bësh me ndihmën e Service Discovery? Service Discovery mund të mbajë konfigurimet e nginx, certifikatat dhe listën e backend-serverëve aktivë.
Gjithashtu, Service Discovery lejon identifikimin e çështjeve dhe defekteve. Cilat janë mundësitë për identifikimin e defekteve?
- Ky është një aplikacion që ne e kemi zhvilluar, i cili njofton vetë Service Discovery se ende është funksional.
- Nga ana e tij, Service Discovery pyet aplikacionin mbi disponueshmërinë.
- Ose përdoret një skript ose aplikacion i jashtëm që verifikon disponueshmërinë e aplikacionit tonë dhe informon Service Discovery se gjithçka është në rregull dhe mund të funksionojë, ose, përkundrazi, se diçka nuk shkon dhe ky ekzemplar aplikacioni duhet përjashtuar nga balancimi.
Çdo skemë mund të aplikohet në varësi të softuerit që po përdorim. Për shembull, nëse sapo kemi filluar zhvillimin e një projekti të ri, ne mund të sigurojmë pa vështirësi një skemë ku aplikacioni ynë njofton Service Discovery. Ose mund të regjistrojmë që Service Discovery bëri kontrollin.
Nëse aplikacioni na ka mbetur si trashëgimi ose është zhvilluar nga dikush tjetër, atëherë zgjidhja e tretë është të shkruajmë një trajtues dhe gjithçka do të integrohet automatikisht në punën tonë.
Kjo është një nga shembujt. Load-balancer-i, si nginx, rindezhet. Kjo është një utilitar shtesë që ofrohet së bashku me Consul. Kjo është consul-template. Ne përshkruajmë një rregull. Them se përdorim një shablon (Shablonizatori Golang). Kur ndodhin ngjarje, kur ka njoftime për ndryshime, ai rinovohet dhe Service Discovery merr komandën 'reload'. Një shembull i thjeshtë, kur në rast ngjarjeje rregullohet konfigurimi i nginx dhe ai rindezhet.
Çfarë është Consul?
Së pari – është Service Discovery.
Ai ka një mekanizëm kontrolli të disponueshmërisë – Health Checking.
Po ashtu, ai ka një KV Store.
Dhe në themel të tij është mundësia për të përdorur Multi Datacenter.
Për çfarë mund të përdoret e gjithë kjo? Në KV Store mund të ruajmë shembuj konfiguracionesh. Kontrolli i Shëndetit mund të realizohet për të verifikuar një shërbim lokal dhe për t'u njoftuar. Multi Datacenter përdoret për të ndërtuar një hartë shërbimesh. Për shembull, Amazon ka disa zona dhe drejton trafikun në mënyrën më optimale që të mos ketë kërkesa të panevojshme mes qendrave të të dhënave, të cilat ngarkohen veçmas nga trafiku lokal dhe, për rrjedhojë, kanë vonesa më të vogla.
Le të shqyrtojmë pak terma të përdorur në Consul.
- Consul – është një shërbim i shkruar në Go. Një nga avantazhet e programit në Go është se është një skedar i vetëm binar që thjesht mund ta shkarkosh. E aktivizon nga çdo vend dhe nuk ke asnjë varësi.
- Më pas, me ndihmën e çelësave ne mund ta aktivizojmë këtë shërbim ose në modin klient, ose në modin server.
- Po ashtu, atributi 'datacenter' lejon të vendosësh një flamur për cilit datacenter i përket ky server.
- Konsensusi – bazohet në protokollin raft. Nëse dikujt i intereson, mund të lexojë më në detaj për këtë në faqen e Consul. Ky është protokoll që lejon të përcaktohet lideri dhe të identifikohen të dhënat që duhen konsideruar si të vlefshme dhe të aksesueshme.
- Gossip – është një protokoll që siguron ndërlidhjen midis nodave. Ky sistem është decentralizuar. Brenda një qendre të dhënash, të gjitha nodet komunikojnë me fqinjët e tyre. Kështu, informacioni mbi gjendjen aktuale transmetohet reciprokisht. Mund të thuhet se këto janë 'gossip' mes fqinjëve.
- LAN Gossip – shkëmbim lokal të të dhënave mes fqinjëve brenda një qendre të dhënash.
- WAN Gossip – përdoret kur na nevojitet të sinkronizojmë informacionin midis dy qendrave të dhënash. Informacioni kalon mes nodave që janë caktuar si serverë.
- RPC – lejon kryerjen e kërkesave nga klientët në server.
Përshkrimi i RPC. Le të themi se në një makinë virtuale ose në një server fizik është nisur Consul si klient. Ne i drejtohemi lokalish. Më pas, klienti lokal kërkon informacion nga serveri dhe sinkronizohet. Informacioni, në varësi të konfigurimeve, mund të japet nga cache lokale ose mund të sinkronizohet me liderin, me master-in e serverit.
Këto dy skema kanë si avantazhe ashtu edhe disavantazhe. Nëse punojmë me cache lokale, atëherë është më shpejt. Nëse punojmë me të dhënat që ruhen në server, procesi zgjat më shumë, por marrim informacion më të saktë.
Nëse e paraqesim grafikisht, kjo është një pamje e faqes. Ne shohim se janë aktivizuar tri mastera. Njëra është e shënuar me yll si lider. Në këtë rast, kemi tri kliente që shkëmbejnë lokal informacionin përmes UDP/TCP. Informacioni midis qendrave të dhënash kalon mes serverëve. Këtu klientët ndërveprojnë lokalish.
Cili API ofron Consul? Për të marrë informacion, ka dy lloje API në Consul.
Ky është API DNS. Me default, Consul ekzekutohet në portin 8600. Ne mund të configurem proxyn e kërkesave dhe të sigurojmë akses përmes rezolvimit lokal, përmes DNS lokal. Ne mund të kërkojmë sipas domenit dhe do të marrim si përgjigje informacionin mbi adresën IP.
HTTP API – ose mund të kërkojmë lokalish në portin 8500 informacionet mbi një shërbim të caktuar dhe do të marrim përgjigjen në format JSON, e cila përmban çfarë IP ka serveri, cili host, cili port është regjistruar. Informacione shtesë mund të dërgohen përmes token.
Çfarë na nevojitet për të nisur Consul?
Në variantin e parë, ne aktivizojmë në 'mode developer' duke caktuar flamurin që është ky modalitet. Agent nis si server. Ai kryen të gjitha funksionet tashmë vetë në një makinë. E përshtatshme, shpejt dhe praktikisht nuk nevojiten konfigurime shtesë për startin e parë.
Varianti i dytë – është nisja në production. Këtu procesi komplikohet pak. Nëse nuk kemi asnjë version të Consul, duhet të inicojmë makinën e parë për bootstrap, domethënë kjo makinë do të marrë rolin e liderit. E nisim atë, pastaj aktivizojmë një ekzemplar të dytë të serverit, duke i kaluar informacionin se ku ndodhet masteri. Pastaj lëmë të tretin. Pas ngritjes së tre makinave, në makinën e parë nga bootstrap-i i aktivizuar, e restartojmë në modalitetin normal. Të dhënat sinkronizohen dhe klasteri fillestar është ngritur.
Rekomandohet të nisen tre deri në shtatë ekzemplarë në modalitetin server. Kjo lidhet me faktin se nëse numri i serverëve rritet, atëherë rritet koha e sinkronizimit të informacionit midis tyre. Numri i nodave duhet të jetë tek, për të siguruar një kuorum.
Si sigurohen Health Checks? Në drejtorinë për konfigurimin e Consul ne shkruajmë një rregull kontrolli në formatin JSON. Varianti i parë – është aksesueshmëria në këtë rast e domenit google.com. Dhe ne themi se çdo 30 sekonda duhet të bëhet kjo verifikim. Kështu kontrollojmë se nodi ynë ka akses në rrjetin e jashtëm.
Varianti i dytë – është verifikimi i vetes. Ne përdorim curl për të kërkuar localhost në portin e caktuar me një interval prej 10 sekondash.
Këto kontrolle përmbledhen dhe kalojnë në Service Discovery. Bazuar në aksesueshmëri, këto nodet ose përjashtohen, ose shfaqen në listën e makinave të disponueshme dhe që funksionojnë në mënyrë korrekte.
Po ashtu, Consul ofron një ndërfaqe UI, e cila aktivizohet me një flamur të veçantë dhe do të jetë e aksesueshme në makinën. Kjo lejon të shikohet informacioni, si dhe mund të bëhen disa ndryshime.
Në këtë rast është hapur skeda 'Shërbimi'. Tregohet se janë aktivizuar tri shërbime, një prej tyre është Consul. Numri i verifikimeve të kryera. Dhe ka tri qendra të dhënash ku ndodhen makinat.
Ky është një shembull i skedës 'Nodes'. Shohim se kanë emra përbërës me përfshirjen e qendrave të dhënash. Po ashtu tregohet se cilat shërbime janë aktivizuar, domethënë shohim se etiketat nuk janë caktuar. Në këto etiketa shtesë mund të jepet ndonjë informacion që zhvilluesi mund ta përdorë për të caktuar parametra të tjerë.
Gjithashtu mund të kaloni informacion në Consul mbi gjendjen e disqeve dhe ngarkesën mesatare.
Pyetje
Pyetje: Kemi një konteiner docker, si ta përdorim atë me Consul?
Përgjigje: Për konteinerin docker ka disa qasje. Një nga qasjet më të zakonshme është të përdorni një konteiner docker të jashtëm që merret me regjistrimin. Kur e nisni, i kaloni soketin e dockerit. Të gjitha ngjarjet e regjistrimit dhe de-publikimit të konteinerit regjistrohen në Consul.
Pyetje: Kjo do të thotë, Consul vetë e nis konteinerin docker?
Përgjigje: Jo. Ne e nisnim konteinerin docker. Në konfigurim, tregojmë – dëgjo një soket të caktuar. Kjo është përafërsisht si puna me tri simbolike, kur kalojmë informacionin se ku dhe çfarë kemi.
Pyetje: Pra, brenda konteinerit docker, të cilin po përpiqemi ta lidhim me Shërbimin e Zbulimit, duhet të ketë një logjikë që di të ofrojë të dhëna për Consul?
Përgjigje: Jo domosdoshmërisht. Kur ai fillon, ne kalojmë variablat përmes mjedisit. Supozoni, emrin e shërbimit, portin e shërbimit. Në regjistrin dëgjon këtë informacion dhe e regjistron në Consul.
Pyetje: Kam gjithashtu një pyetje për UI. Ne e kemi zhvilluar UI-në, le të themi, në serverin e prodhimit. Çfarë ndodh me sigurinë? Ku ruhen të dhënat? A mund ta akumulojmë diçka?
Përgjigje: Në UI, të dhënat vijnë pikërisht nga baza dhe nga Shërbimi i Zbulimit. Ne vendosim fjalëkalimet në konfigurimet tona.
Pyetje: A mund të publikohet kjo në internet?
Përgjigje: Në default, Consul fillon në localhost. Për ta publikuar në internet, duhet të vendosim ndonjë proxy. Ne jemi përgjegjës për rregullat e sigurisë.
Pyetje: A ofron të dhëna historike prej kutisë? Më vjen mirë të shoh statistikat për Kontrollet e Shëndetit. A mund të diagnostikohet ndonjë problem nëse serveri shpesh dështojnë.
Përgjigje: Nuk jam i sigurt se ka detaje të kontrolleve.
Pyetje: Nuk është aq e rëndësishme gjendja aktuale, sa rëndësia e dinamikës.
Përgjigje: Për analizë – po.
Pyetje: A është më mirë të mos përdorim Shërbimin e Zbulimit për docker Consul?
Përgjigje: Nuk do ta rekomandoja atë. Qëllimi i prezantimit është të njoftoj se ka një koncept të tillë. Historikisht ai ka kaluar, mendoj, deri në versionin 1. Tani ka zgjidhje më të plota, si Kubernetes, i cili ka gjithçka brenda. Në kuadër të Kubernetes, Shërbimi i Zbulimit është inferior ndaj Etcd. Por unë nuk jam aq i njohur me të si me Consul. Prandaj, vendosa të bëj Shërbimin e Zbulimit si shembull Consul.
Pyetje: Schemi me serverin lider nuk ngadalëson nisjen e aplikacionit në përgjithësi? Si e përcakton Consul një lider të ri, nëse ky ndodhet i shtrirë?
Përgjigje: Ata kanë përshkruar një protokoll të plotë. Nëse je i interesuar, mund të lexosh.
Pyetje: Consul është një server i plotë për ne dhe të gjitha kërkesat kalojnë përmes tij?
Përgjigje: Ai nuk është një server i plotë, por merr një zonë të caktuar. Kjo zakonisht përfundon me service.consul. Dhe pastaj ne ndjekim logjikën. Nuk përdorim emrat e domeneve në prodhim, por infrastrukturën e brendshme, e cila zakonisht fshihet pas një serveri keqazhur, nëse punojmë me DNS.
Pyetje: Pra, nëse duam të lidhemi me bazën e të dhënave, ne në çdo rast do të konsultohemi me Consul për të gjetur këtë bazë, e drejtë?
Përgjigje: Po. Nëse punojmë me DNS, kjo funksionon si pa Consul, kur përdorim emrat e DNS. Zakonisht aplikacionet moderne nuk bëjnë kërkesë për emrin e domainit në çdo kërkesë, sepse e kemi vendosur lidhjen dhe gjithçka funksionon dhe gjatë një kohe ne praktikisht nuk e përdorim. Nëse lidhja prishët, atëherë – po, ne e pyesim përsëri se ku e kemi bazën dhe shkojmë te ajo.
— Chat i përdoruesve Hashicorp: Consul, Nomad, Terraform
P.S. Në lidhje me kontrollet e shëndetit. Në Consul si në Kubernetes përdoret sistemi i njëjtë për verifikimin e gjendjes së shërbimeve mbi bazën e kodit të statusit.
200 OK për të shëndetshëm
503 Shërbimi i Pa Disponueshëm për të sëmurëBurimet:
Burimi: habr.com
