Ju ofroj të njohni me shpjegimin e raportit të Aleksandër Sigachev mbi Zbulimin e Shërbimeve në sistemet e shpërndara duke marrë si shembull Consul.
Zbulimi i Shërbimeve është krijuar në mënyrë që të lidheni me një aplikacion të ri në mjedisin tonë ekzistues me minimumin e kostove. Duke përdorur Zbulimin e Shërbimeve, ne mund të ndajmë maksimalisht ose kontejnerin në formën e dokers, ose një shërbim virtual nga mjedisi në të cilin është nisur.

Përshëndetje të gjithëve! Jam Aleksandër Sigachev, punoj në kompaninë Inventos. Sot do t'ju njoh me konceptin e Zbulimit të Shërbimeve. Do të shqyrtojmë Zbulimin e Shërbimeve me shembullin e Consul.

Cilat probleme zgjidh Zbulimi i Shërbimeve? Zbulimi i Shërbimeve është krijuar që të lidheni me një aplikacion të ri në mjedisin tonë ekzistues me minimumin e kostove. Duke përdorur Zbulimin e Shërbimeve, ne mund të ndajmë maksimalisht ose kontejnerin në formën e dokers, ose një shërbim virtual nga mjedisi në të cilin është nisur.
Si duket kjo? NĂ« njĂ« shembull klasik nĂ« web â Ă«shtĂ« frontend-i, i cili merr njĂ« kĂ«rkesĂ« nga pĂ«rdoruesi. MĂ« pas, ai bĂ«n ruterimin e saj nĂ« backend. NĂ« kĂ«tĂ« shembull â load-balancer-i balancojnĂ« nĂ« dy backend.

Këtu shohim se ne nisëm një ekzemplar të tretë të aplikacionit. Përkatësisht, kur aplikacioni nis, ai regjistron veten në Zbulimin e Shërbimeve. Zbulimi i Shërbimeve njofton load-balancer-in. Load-balancer-i ndryshon automatikisht konfigurimin e tij dhe tashmë backend-i i ri fillon punën. Kështu mund të shtohen backend-e ose, përkundrazi, të përjashtohen nga puna.

ĂfarĂ« tjetĂ«r Ă«shtĂ« e pĂ«rshtatshme tĂ« bĂ«het me ndihmĂ«n e Zbulimit tĂ« ShĂ«rbimeve? NĂ« Zbulimin e ShĂ«rbimeve mund tĂ« ruhen konfigurime nginx, certifikata dhe lista e serverĂ«ve aktivĂ« backend.
Po ashtu, Zbulimi i Shërbimeve lejon të zbulojë dështimet, të identifikojë defektet. Cilat mund të jenë skemat për zbuluar defektet?
- Ky është një aplikacion që ne e zhvilluam, ai vetë njofton Zbulimin e Shërbimeve që është ende funksional.
- Zbulimi i Shërbimeve nga ana e tij pyet aplikacionin për faktin e aksesueshmërisë.
- Ose përdoret një skript ose aplikacion i palës së tretë, i cili kontrollon aksesueshmërinë e aplikacionit tonë dhe njofton Zbulimin e Shërbimeve, që gjithçka shkon mirë dhe mund të punojë, ose, përkundrazi, që gjithçka është keq dhe duhet përjashtuar këtë ekzemplar aplikacioni nga balancimi.
Ădo skemĂ« mund tĂ« aplikohet nĂ« varĂ«si tĂ« softuerit qĂ« ne pĂ«rdorim. PĂ«r shembull, sapo kemi filluar zhvillimin e njĂ« projekti tĂ« ri, mund ta sigurojmĂ« lehtĂ«sisht njĂ« skemĂ« ku aplikacioni ynĂ« njofton ShĂ«rbimin e Zbulimit. Ose mund tĂ« lidhim qĂ« ShĂ«rbimi i Zbulimit kryen verifikimin.
Nëse aplikacioni na është lënë në trashëgimi ose është zhvilluar nga dikush tjetër, atëherë këtu është e përshtatshme varianti i tretë, kur ne shkruajmë një trajtues dhe gjithçka e tillë automatizohet në punën tonë.

Ky është një nga shembujt. Load-balancer në formën e nginx-rij ngarkohet sërish. Kjo është një utilitare shtesë që ofrohet me Consul. Ky është consul-template. Ne përshkruajmë një rregull. Them se po përdorim një model (Shablonizuesi Golang). Kur ndodhin ngjarje, kur ka njoftime për ndryshime, ai regenerohet dhe Shërbimi i Zbulimit dërgon komandën "reload". Një shembull i thjeshtë, kur me ngjarjen ripërshtatet nginx dhe riniset.

ĂfarĂ« Ă«shtĂ« Consul?
Së pari - është Shërbimi i Zbulimit.
Ai ka mekanizmin e verifikimit të disponueshmërisë - Verifikimi i Shëndetit.
Po ashtu ka një KV Store.
Dhe themeli i tij mbështet përdorimin e Datacentereve të Shumta.
Për çfarë mund të përdoret të gjithë kjo? Në KV Store ne mund të ruajmë shembuj konfigurimesh. Verifikimi i Shëndetit mund të bëjë një kontroll të shërbimeve lokale dhe të njoftojë. Multi Datacenter përdoret për të ndërtuar një hartë shërbimesh. Për shembull, Amazon ka disa zona dhe rregullon trafikun në mënyrën më optimale, në mënyrë që të mos ketë kërkesa të panevojshme ndërmjet datacentereve, të cilat tarifohen veçmas nga trafiku lokal dhe, për rrjedhojë, kanë vonesë më të vogël.

Lëvizim pak në terminologjinë që përdoret në Consul.
- Consul - një shërbim i shkruar në Go. Një nga përparësitë e programit në Go është se është një skedar binar i vetëm, që thjesht e shkarkoni. E nisni nga çdo vend dhe nuk keni varësi.
- Më pas, me anë të çelësave ne mund ta nisim këtë shërbim ose në mënyrën e klientit, ose në mënyrën e serverit.
- Po ashtu, atributi "datacenter" lejon të vendosni një flamur të cilit datacenter i përket ky server.
- Konsensusi - bazohet në protokollin raft. Nëse dikujt i intereson, mund të lexojë më shumë rreth kësaj në faqen e internetit të Consul. Ky është një protokoll që lejon të përcaktohet lideri dhe të merren parasysh cilat të dhëna janë të vlefshme dhe të aksesueshme.
- Gossip â Ă«shtĂ« njĂ« protokoll qĂ« siguron ndĂ«rveprimin midis nyjeve. Ky sistem Ă«shtĂ« decentralizuar. Brenda njĂ« qendre tĂ« tĂ« dhĂ«nave, tĂ« gjitha nyjet komunikojnĂ« me fqinjĂ«t e tyre. NjĂ«herĂ«sh, informacioni mbi gjendjen aktuale kalon nga njĂ«ra palĂ« tek tjetra. Mund tĂ« thuhet se janĂ« thashetheme mes fqinjĂ«ve.
- LAN Gossip â shkĂ«mbim lokal tĂ« tĂ« dhĂ«nave midis fqinjĂ«ve brenda njĂ« qendre tĂ« tĂ« dhĂ«nave.
- WAN Gossip â pĂ«rdoret kur na nevojitet tĂ« sinkronizojmĂ« informacionin midis dy qendrave tĂ« tĂ« dhĂ«nave. Informacioni udhĂ«ton midis nyjeve qĂ« shĂ«njohen si serverĂ«.
- RPC â lejon tĂ« kryhen kĂ«rkesa pĂ«rmes klientit nĂ« server.
PĂ«rshkrimi i RPC. Supozoni se nĂ« njĂ« makinĂ« virtuale ose nĂ« njĂ« server fizik Ă«shtĂ« aktivizuar Consul si klient. Ne i drejtohemi atij lokalisht. MĂ« pas, klienti lokal kĂ«rkon informacion nga serveri dhe sinkronizohet. Informacioni, varĂ«sisht nga konfigurimet, mund tĂ« jepet nga keĆi lokal, ose mund tĂ« sinkronizohet me liderin, me serverin kryesor.
KĂ«to dy skema kanĂ« si pĂ«rfitime ashtu edhe disavantazhe. NĂ«se punojmĂ« me keĆi lokal, kjo Ă«shtĂ« e shpejtĂ«. NĂ«se punojmĂ« me tĂ« dhĂ«nat qĂ« ruhen nĂ« server, kjo Ă«shtĂ« mĂ« e ngadaltĂ«, por marrim informacion mĂ« tĂ« saktĂ«.

Nëse e paraqesim atë grafiket, duket si kjo pamje e faqes. Shohim se kemi aktivizuar tre liderë. Njëri është shënjuar me yll si lider. Në këtë shembull, tre klientë shkëmbejnë informacion lokal me njëri-tjetrin përmes UDP/TCP. Ndërsa informacioni midis qendrave të të dhënave kalon midis serverëve. Këtu, klientët bashkëpunojnë lokal.

Cili API ofron Consul? Për të marrë informacion, Consul ka dy lloje API.
Ky është API DNS. Me default Consul aktivizohet në portin 8600. Ne mund të konfiguroni proksimin e kërkesës dhe të sigurojmë qasje përmes rezollvimit lokal, përmes DNS lokal. Mund të kërkojmë përmes domenit dhe do të marrim informacion mbi adresën IP.
HTTP API â ose mund tĂ« kĂ«rkojmĂ« lokal nĂ« portin 8500 pĂ«r informacion mbi njĂ« shĂ«rbim tĂ« caktuar dhe do tĂ« marrim njĂ« pĂ«rgjigje JSON, cila IP ka serveri, cili host, cili port Ă«shtĂ« regjistruar. Informacione shtesĂ« mund tĂ« dĂ«rgohen pĂ«rmes njĂ« token.

ĂfarĂ« nevojitet pĂ«r tĂ« aktivizuar Consul?
NĂ« versionin e parĂ«, ne nĂ« modalitetin e zhvilluesit shĂ«nojmĂ« flamurin qĂ« Ă«shtĂ« modaliteti i zhvilluesit. Agjenti nis si server. Dhe tĂ«rĂ« funksionin e realizon tashmĂ« vetĂ« nĂ« njĂ« makinĂ«. ĂshtĂ« e pĂ«rshtatshme, e shpejtĂ« dhe praktikisht nuk kĂ«rkohet asnjĂ« konfigurim shtesĂ« pĂ«r fillimin e parĂ«.
Modaliteti i dytĂ« â Ă«shtĂ« nisja nĂ« prodhim. KĂ«tu nisja ndĂ«rlikohet disi. NĂ«se nuk kemi asnjĂ« version tĂ« konsulit, atĂ«herĂ« ne duhet tĂ« sjellim nĂ« bootstrap makinĂ«n e parĂ«, dmth. kjo makinĂ« qĂ« do tĂ« marrĂ« mbi vete detyrat e liderit. Ne e ngrisim atĂ«, pastaj e ngrisim njĂ« ekzemplar tĂ« dytĂ« tĂ« serverit, duke i kaluar informacionin se ku ndodhet masteri. E ngrisim dhe eksperimentin e tretĂ«. Pasi kemi ngritur tri makina, nĂ« makinĂ«n e parĂ« tĂ« ngritur nga bootstrap, e rinisim atĂ« nĂ« modalitetin normal. TĂ« dhĂ«nat sinkronizohen dhe klasteri fillestar Ă«shtĂ« tashmĂ« ngritur.
Rekomandohet që të nisni nga tre në shtatë ekzemplarë në modalitetin server. Kjo është e justifikuar nga fakti që, nëse numri i serverëve rritet, atëherë rritet edhe koha për sinkronizimin e informacionit mes tyre. Numri i nodave duhet të jetë tek, për të siguruar kuorum.

Si sigurohen Kontrollimet e ShĂ«ndetit? NĂ« direktorinĂ« pĂ«r konfigurimin e Consul, ne shkruajmĂ« rregullin e kontrollit nĂ« formatin Json. Versioni i parĂ« â Ă«shtĂ« disponueshmĂ«ria nĂ« kĂ«tĂ« shembull tĂ« domenit google.com. Dhe themi qĂ« nĂ« njĂ« interval prej 30 sekondash duhet tĂ« kryejmĂ« kĂ«tĂ« kontroll. KĂ«shtu ne verifikojmĂ« se nodi ynĂ« ka akses nĂ« rrjetin e jashtĂ«m.
Versioni i dytĂ« â Ă«shtĂ« kontrolli i vetvetes. Ne thjesht e thĂ«rrasim localhost me curl nĂ« portin e specifikuar, me njĂ« interval prej 10 sekondash.
Këto kontrolle akumulohen dhe kalojnë në Zbulimin e Shërbimeve. Në bazë të disponueshmërisë, këto nodë përjashtohen ose shfaqen në listën e makinave që janë në dispozicion dhe që punojnë siç duhet.

Po ashtu, Consul ofron një ndërfaqe UI, e cila niset me një flamur të veçantë dhe do të jetë e accesueshme në mesin e makinës. Kjo lejon shikimin e informacionit, si dhe mund të bëhen disa ndryshime.
Në këtë shembull është hapur skeda "Shërbimi". Të vizatohet se janë të lansuara tri shërbime, një prej tyre është Consul. Numri i kontrollimeve të kryera. Dhe ka tre qendra të të dhënave ku ndodhen makinat.

Ky është një shembull i skedës «Nodes». Mund të shohim se ato kanë emra të përbërë që përfshijnë qendrat e të dhënave. Këtu gjithashtu tregohet se cilat shërbime janë të aktivizuara, dmth. shohim që etiketat nuk janë caktuar. Në këto etiketa shtesë mund të caktojmë ndonjë informacion, që zhvilluesi mund ta përdorë për të specifikuar parametra të tjera.
Gjithashtu mund të dërgohet informacion në Consul mbi gjendjen e disqeve, mbi ngarkesën mesatare.
Pyetje
Pyesni: Kemi një kontenier docker, si ta përdorim atë me Consul?
Përgjigje: Për kontenierin docker ka disa qasje. Një nga qasjet më të zakonshme është të përdorim një kontenier docker të jashtëm që merret me regjistrimin. Kur aktivizohet, i kalojmë socket-in e docker-it. Të gjitha ngjarjet për regjistrimin dhe de-publikimin e kontenierit regjistrohen në Consul.
Pyesni: Domethënë, Consul vetë aktivizon kontenierin docker?
PĂ«rgjigje: Jo. Ne aktivizojmĂ« kontenierin docker. Dhe gjatĂ« konfigurimit specifikojmĂ« â dĂ«gjo njĂ« socket tĂ« tillĂ«. Kjo Ă«shtĂ« mĂ« e ngjashme me mĂ«nyrĂ«n se si funksionon certifikata, kur ne i kalojmĂ« informacionin, ku dhe çfarĂ« kemi.
Pyesni: Pra, brenda kontenierit docker, që po mundohemi ta lidhim me Discovery të Shërbimeve, duhet të ketë një logjikë që mund të kthejë të dhëna në Consul?
Përgjigje: Jo për skaj. Kur aktivizohet, ne i kalojmë variablat përmes ambientit. Supozoni, emri i shërbimit, porta e shërbimit. Në regjistrin dëgjon këtë informacion dhe e regjistron në Consul.
Pyesni: Kam njĂ« pyetje tjetĂ«r pĂ«r UI. Ne e rindĂ«rtuam UI, supozoni, nĂ« serverin e prodhimit. ĂfarĂ« Ă«shtĂ« me sigurinĂ«? Ku ruhen tĂ« dhĂ«nat? A mund tĂ« akumulojmĂ« ndonjĂ«herĂ« tĂ« dhĂ«na?
Përgjigje: Në UI, të dhënat vijnë nga baza dhe nga Discovery i Shërbimeve. Ne caktojmë vetë fjalëkalimet në konfigurime.
Pyesni: A mund të publikojmë këtë në internet?
Përgjigje: Nga e drejta, Consul aktivizohet në localhost. Për ta publikuar në internet, do të na nevojitet të vendosim ndonjë proxy. Ne jemi përgjegjës për rregullat e sigurisë.
Pyesni: A ofron të dhëna historike nga kutia? Më intereson të shoh statistikën për Kontrollet e Shëndetit. A mund të diagnostikojmë probleme nëse serveri shpesh dështon.
Përgjigje: Nuk jam i sigurt se atje ka detaje të kontrolleve.
Pyesni: Nuk është aq e rëndësishme gjendja aktuale, sesa dinamika.
PĂ«rgjigje: PĂ«r analizĂ« â po.
Pyesni: A është më mirë të mos përdorim Discovery të Shërbimeve për docker Consul?
Përgjigje: Nuk do ta rekomandoja atë. Qëllimi i raportit është të paraqesë se çfarë është ky koncept. Historikisht, ai ka kaluar një rrugë deri në versionin e parë. Tani ka zgjidhje më të plota, si Kubernetes, i cili e ka gjithçka nën kapak. Brenda Kubernetes, Zbulimi i Shërbimeve i nënshtrohet Etcd. Por nuk jam aq i njohur me të sa me Consul. Prandaj, vendosa të bëj Zbulimin e Shërbimeve me shembuj nga Consul.
Pyetje: A ndalon skema me serverin lider nisjen e aplikacionit në përgjithësi? Dhe si e përcakton Consul liderin e ri nëse ky bie?
Përgjigje: Ata e kanë përshkruar një protokoll të tërë. Nëse jeni të interesuar, mund ta lexoni.
Pyetje: Consul na shërben si një server i plotë dhe të gjitha kërkesat kalojnë përmes tij?
Përgjigje: Ai nuk shërben si një server i plotë, por merr një zonë të caktuar. Ajo zakonisht përfundon me service.consul. Dhe më pas ne ndjekim logjikën. Ne nuk përdorim emrat e dominio në prodhim, por pikërisht infrastrukturën tonë të brendshme, e cila zakonisht fshihet pas serverit të ruajtjes, nëse punojmë me DNS.
Pyetje: Do të thotë, nëse duam të qasje në bazën e të dhënave, në çdo rast do të kontaktojmë Consul-in për të gjetur këtë bazë, apo jo?
PĂ«rgjigje: Po. NĂ«se punojmĂ« me DNS, funksionon si pa Consul kur pĂ«rdorim emrat DNS. Zakonisht, aplikacionet moderne nuk e marrin emrin e domenit nĂ« çdo kĂ«rkesĂ«, sepse kemi vendosur lidhjen, gjithçka funksionon dhe nĂ« njĂ« kohĂ« tĂ« afĂ«rt ne praktikisht nuk e pĂ«rdorim. NĂ«se lidhja prishĂ«t, atĂ«herĂ« â po, pĂ«rsĂ«ri pyesim se ku ndodhet baza jonĂ« dhe shkojmĂ« te ajo.
â Biseda e pĂ«rdoruesve Hashicorp: Consul, Nomad, Terraform
P.S. Në lidhje me kontrollin e shëndetit. Në Consul, ashtu si në Kubernetes, përdoret sistemi i njëjtë për të verifikuar gjendjen e shërbimit mbi bazën e kodit të statusit.
200 OK për të shëndetshëm
503 Shërbimi i Pa Dispozuar për të pa shëndetshëmBurimet:
Burimi: habr.com
