Teenuste avastamine jaotatud süsteemides, kasutades Consuli näidet. Aleksandr Sigatšev

Tutvustan teile Aleksandr Sigatševi ettekannet teemal Teenuste avastamine jaotatud süsteemides, kasutades Consuli näidet.

Teenuste avastamine on loodud selleks, et uue rakenduse liitmine meie olemasoleva keskkonnaga oleks võimalikult madalate kuludega. Kasutades Teenuste avastamist, saame maksimaalselt eraldada kas konteineri nagu Docker või virtuaalteenuse sellest keskkonnast, kus see on käivitatud.

Tere kõigile! Mina olen Aleksandr Sigatšev, töötan ettevõttes Inventos. Täna tutvustan teile sellist mõistet nagu Teenuste avastamine. Uurime Teenuste avastamist Consuli näitel.

Milliseid probleeme lahendab Teenuste avastamine? Teenuste avastamine on loodud selleks, et uue rakenduse liitmine meie olemasoleva keskkonnaga oleks võimalikult madalate kuludega. Kasutades Teenuste avastamist, saame maksimaalselt eraldada kas konteineri nagu Docker või virtuaalteenuse sellest keskkonnast, kus see on käivitatud.

Kuidas see välja näeb? Klassikalise näitena veebist – see on frontend, mis võtab kasutaja päringu vastu. Edasi suunatakse see backend'i. Antud näitel tasakaalustab load-balancer kahte backend'i.

Siin näeme, et käivitame rakenduse kolmanda koopia. Kui rakendus käivitatakse, registreerib see end Teenuste avastamises. Teenuste avastamine teavitab load-balancerit. Load-balancer muudab oma konfiguratsiooni automaatselt ja uus backend rakendub. Nii saab backend'ide lisamine või vastupidi, nende töölt kõrvaldamine toimuda.

Mida veel on mugav teha Teenuste avastamise abil? Teenuste avastamisest võivad leida konfiguratsioonid nginx, sertifikaadid ja aktiivsete backend-serveerijate loetelu.

Samuti võimaldab Teenuste avastamine avastada vigu ja talitlushäireid. Millised skeemid on võimalikud talitlushäirete avastamisel?

• See rakendus, mille me välja töötasime, teavitab Teenuste avastamist, et see on ikka veel töökorras.
• Teenuste avastamine küsib rakenduse juurest kättesaadavuse kohta.
• Või kasutatakse kolmanda osapoole skripti või rakendust, mis kontrollib meie rakenduse kättesaadavust ja teavitab Teenuste avastamist, et kõik on korras ja võib töötada, või vastupidi, et kõik on halvasti ja tuleb see rakenduse koopia tasakaalustamisest kõrvaldata.

Iga skeem võib rakenduda sõltuvalt sellest, millist tarkvara me kasutame. Näiteks, kui me just alustasime uue projekti arendamist, saame probleemideta tagada skeemi, kus meie rakendus teavitab Service Discovery't. Või võime ühendada, et Service Discovery viib läbi kontrolli.

Kui aga rakendus on meile pärandatud või välise arendaja loodud, sobib siin kolmas variant, kus me kirjutame töötleja, ja see kõike integreerub meie tööga automaatselt.

See on üks näide. Nginx'i kujul olev load-balancer taaskäivitub. See on lisatööriist, mis on saadaval koos Consul'iga. See on consul-template. Me määratleme reegli. Räägime, et kasutame шаблона (Golangi templatiserija). Toimingute korral, teavitamisel, et on toimunud muudatusi, ta genereeritakse uuesti ja Service Discovery'le saadetakse käsk „reload”. Lihtne näide, kui sündmuse korral konfigureeritakse nginx uuesti ja käivitatakse.

Mis on Consul?

• Ennekõike on see Service Discovery.

• Sellel on kättesaadavuse kontrollimise mehhanism – Health Checking.

• Samuti sisaldab see KV Store'i.

• Ja selle aluseks on võimalus kasutada Multi Datacenter'i.

Milleks seda kõike kasutada? KV Store'is saame säilitada konfigureerimise näiteid. Health Checking võimaldab meil kontrollida kohalikke teenuseid ja teavitada. Multi Datacenter'i kasutatakse selleks, et saaksime koostada teenuste kaardi. Näiteks Amazonil on mitu tsooni ja see suunab liikluse kõige optimaalsemalt, et vältida tarbetuid päringuid andmekeskuste vahel, mis arvestatakse eraldi kohaliku liikluse jätkude ja seega on väiksem viivitus.

Vaatame natuke termineid, mida Consul'is kasutatakse.

• Consul on Go keeles kirjutatud teenus. Üks Go programmi eeliseid on see, et see on 1 binaarfail, mille saad lihtsalt alla laadida. Käivitage see ükskõik kus ja teil pole sõltuvusi.
• Edasi saame klahvide abil käivitada selle teenuse kas kliendi või serveri režiimis.
• Samuti võimaldab atribuut „datacenter” määrata, millisele andmekeskusele see server kuulub.
• Consensus põhineb raft-protokollil. Kui kedagi huvitab, saab selle kohta rohkem lugeda Consul'i veebisaidilt. See on protokoll, mis võimaldab määrata liidri ja otsustada, millised andmed on kehtivad ja kättesaadavad.
• Gossip – see protokoll, mis tagab node'ide vahelise suhtluse. See süsteem on detsentraliseeritud. Ühes andmekeskuses suhtlevad kõik node'id omavahel. Seega edastavad nad üksteisele teavet jooksva seisundi kohta. Võib öelda, et see on naabrite vahelised kuulujutud.
• LAN Gossip – lokaalne andmevahetus naabrite vahel ühes andmekeskuses.
• WAN Gossip – kasutatakse, kui on vajalik teabe sünkroniseerimine kahe andmekeskuse vahel. Teave liigub node'ide vahel, mis on märgitud serveriteks.
• RPC – võimaldab päringute tegemist kliendi kaudu serveris.

RPC kirjeldus. Oletame, et virtuaalses või füüsilises serveris töötab Consul kliendina. Me pöördume selle poole kohalikult. Edasi kohalik klient pärib teavet serverilt ja sünkroniseerib. Teave võib sõltuvalt seadistustest tulla lokaalsest vahemälust või sünkroniseerida serveri liidriga.

Nendel kahe schemel on nii eeliseid kui ka puudusi. Kui töötame kohalikus vahemälus, siis on see kiire. Kui töötame serveris hoitava teabega, siis on see aeglasem, kuid saame värskemat teavet.

Kui seda graafiliselt kujutada, siis on meil selline skeem. Näeme, et meil on käivitatud kolm liidrit. Üks on tähistatud tähega liidrina. Selles näites on kolm klienti, kes vahetavad omavahel teavet kohaliku UDP/TCP kaudu. Teave andmekeskuste vahel edastatakse serverite vahel. Siin suheldakse klientide vahel kohalikult.

Millist API't pakub Consul? Teabe hankimiseks on Consul'il kaks tüüpi API'd.

See on DNS API. Vaikimisi käivitub Consul 8600 pordin. Saame seadistada päringu proksimise ja tagada juurdepääsu kohaliku resolvimise kaudu, kohaliku DNS-i kaudu. Saame pärida domeeni ja saame vastuseks IP-aadressi teavet.

HTTP API – või saame kohalikult 8500 pordin küsida teavet konkreetse teenuse kohta ja saame JSON vastuse, millise IP'l on server, milline host, milline port on registreeritud. Ja lisainformatsioon võib olla edastatud token'i kaudu.

Mida on vaja, et Consul käivitada?

Esimeses variandis määrame arendaja režiimis lipu, et see on arendaja režiim. Agent käivitub serverina. Ja täidab kogu funktsiooni juba ühel masinal iseseisvalt. Mugav, kiire ja praktiliselt mingit täiendavat seadistamist esimese käivitamise jaoks ei ole vajalik.

Teine režiim on tootmisrežiim. Siin käivitamine veidi keerulisem. Kui meil pole ühtegi konsoliversiooni, peame tooma esimesena töötama masina, st selle masina, mis võtab üle juhi kohustused. Külastame seda, seejärel käivitame teise serveri koopia, edastades talle teabe, kus asub meie meister. Kolmandat tõstame üles. Pärast kolme masina tõstmist käivitame esimesel masinal, mis on käivitunud bootstrap'ist, oma tavalises režiimis. Andmed sünkroniseeritakse ja algne kluster on juba üles tõstetud.

Soovitav on käivitada kolm kuni seitse eksemplari serverirežiimis. See tuleneb asjaolust, et kui serverite arv suureneb, suureneb ka teabe sünkroniseerimise aeg nende vahel. Nodide arv peab olema paaritu, et tagada kvoorum.

Kuidas tagatakse tervisekontrollid? Configuratsiooni katalooge Consul jaoks kirjutame me reegli kontrollimise nagu JSON. Esimene variant on selle näite järgi juurdepääsetavuse kontrollimine domeenile google.com. Ja ütleme, et iga 30 sekundi tagant tuleb seda kontrolli teostada. Nii kontrollime, et meie nodal on juurdepääs välisele võrgule.

Teine variant on kontrollida iseennast. Me teeme tavalise curl'i kutse localhost'i kindlaksmääratud pordile iga 10 sekundi tagant.

Need kontrollid summeeritakse ja saadetakse Teenuse Tuvastamisse. Tuginedes juurdepääsetavusele, kas need nodid välistatakse või ilmuvad saadaval ja korralikult töötavate masinate nimekirja.

Samuti pakub Consul UI-liidest, mis käivitub eraldi lipuga ja on saadaval masinatel. See võimaldab vaadata teavet ning teha ka mõningaid muudatusi.

Selles näites on avatud 'Teenuse' vahekaart. Näidatud on, et kolm teenust on käivitatud, neist üks on Consul. Kontrollimise tulemuste hulk. Ja on kolme andmekeskust, kus masinad asuvad.

See on "Nodes" vahekaart. Näeme, et neil on koos nimesid andmekeskustega. Siin on näidatud ka, millised teenused on aktiivsed, st me näeme, et silte ei ole määratud. Nendes täiendavates siltes saab määrata teavet, mida arendaja saab kasutada täiendavate parameetrite määramiseks.

Samuti saab Consulile edastada teavet ketaste oleku ja keskmise koormuse kohta.

Küsimused

Küsimus: Meil on Docker konteiner, kuidas seda kasutada Consuliga?

Vastus: Docker konteineri jaoks on mitu lähenemist. Üks levinumaid on kasutada kolmandat osapoolt Docker konteinerit, mis vastutab registri eest. Käivitamisel edastatakse talle Docker socket. Kõik konteineri registreerimise ja tühistamise sündmused salvestatakse Consulisse.

Küsimus: St Consul käivitab ise Docker konteineri?

Vastus: Ei. Me käivitame Docker konteineri. Ja konfiguratsioonis määrame – kuula sellist socketit. See on umbes sama, nagu töötamine sertifikaadiga, kui edastame teavet, kus ja mis meil on.

Küsimus: Tundub, et Docker konteineris, mille proovime Service Discovery'gaühendada, peab olema mingi loogika, mis oskab edastada andmeid Consulile?

Vastus: Mitte päris. Kui see käivitub, edastame me keskkonnamuutujate kaudu muutujad. Oletame, teenuse nimi, teenuse port. Register kuulab seda teavet ja salvestab selle Consulisse.

Küsimus: Mul on veel UI kohta küsimus. Oleme käivitanud UI, eeldades, et see on tootmiserveris. Mis on turvalisusega? Kus andmed asuvad? Kas saab andmeid kuidagi koguda?

Vastus: UI puhul tulevad andmed tegelikult andmebaasist ja Service Discovery'st. Paroolid paneme seadistustes ise paika.

Küsimus: Kas seda on lubatud internetis avaldada?

Vastus: Vaikimisi käivitub Consul localhost'is. Et seda internetti avaldada, tuleb paigaldada mõni proxy. Turvalisuse eest vastutame ise.

Küsimus: Kas ajaloolisi andmeid pakutakse? Huvi on vaadata tervise kontrollide statistikat. Kas tõepoolest saab diagnoosida probleeme, kui server sageli koos allub.

Vastus: Ma ei ole kindel, et seal on kontrollide detaile.

Küsimus: Mõningase tähtsuse oma oleva seisundi osas, kui palju olla dünaamikast.

Vastus: Analüüsimiseks – jah.

Küsimus: Kas Docker jaoks Service Discovery't Consuliga kasutada on parem mitte?

Vastus: Ma ei soovitaks seda kasutada. Ettekanne tutvustab, mis see mõisted on. Aajaloos on see teinud teed, minu arvates, esimese versiooni juurde. Praegu on olemas palju täiuslikumaid lahendusi, näiteks Kubernetes, millega on see kõik koos. Kuberneteses jääb Service Discovery Etcd'ile alla. Kuid ma ei tunne seda nii hästi kui Consulit. Seetõttu otsustasin Service Discovery näidata Consuli näitel.

Küsimus: Kas liidri serveri skeem ei aeglusta rakenduse käivitamist tervikuna? Ja kuidas Consul määrab uue liidri, kui see on maas?

Vastus: Neil on välja töötatud kogu protokoll. Kui see huvitab, siis saad seda lugeda.

Küsimus: Kas Consul toimib täieliku serverina ja kõik päringud liiguvad läbi selle?

Vastus: Ta ei tööta täieliku serverina, vaid hõlmab kindlat ala. See lõppeb tavaliselt service.consul'iga. Ja edasi juhindume loogikast. Me ei kasuta tootmises domeeninimesid, vaid sisemist infrastruktuuri, mis peidetakse tavaliselt serveri vahemälu taha, kui töötame DNS-iga.

Küsimus: St. kui soovime andmebaasi juurde pääseda, peame me igal juhul Consulit küsima, et kõigepealt leida see andmebaas, eks?

Vastus: Jah. Kui töötame DNS-i kaudu, siis see töötab nagu ilma Consulita, kui kasutame DNS-nimesid. Tavalised tänapäevased rakendused ei kontrolli igas päringus domeeninime, sest me oleme connect-iga ühendust loonud, kõik töötab ja lähitulevikus me ei kasutagi seda. Kui ühendus katkeb, siis – jah, küsime jälle, kus meie andmebaas on ja läheme selle juurde.

HashiCorp toodete vestlus — HashiCorpi kasutajate vestlus: Consul, Nomad, Terraform

P.S. Mis puutub tervisekontrollidesse. Consulis, nagu ka Kuberneteses, kasutatakse sama süsteemi teenuse elujõudmise kontrollimiseks põhinedes staatuse koodile.

200 OK tervislik
503 Teenus ei ole kättesaadav tervislikul

Allikad:
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/

Allikas: habr.com