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
