Tutvustan teile Aleksandr Sigatšovi ettekande tõlgendust teenuste avastamisest hajutatud süsteemides, kasutades näitena Consulit.
Teenuste avastamine on loodud selleks, et saaksime minimaalse vaevaga ühendada uusi rakendusi juba olemasolevasse keskkonda. Kasutades teenuste avastamist, suudame maksimaalselt eraldada kas konteineri, nagu Dockeri, või virtuaalse teenuse keskkonnast, kus see on käivitatud.
Tere kõigile! Olen Aleksandr Sigatšov, töötan ettevõttes Inventos. Täna tutvustan teile sellist mõistet nagu teenuste avastamine. Vaatame teenuste avastamist Consuli näitel.
Milliseid probleeme lahendab teenuste avastamine? Teenuste avastamine on loodud selleks, et saaksime minimaalse vaevaga ühendada uusi rakendusi juba olemasolevasse keskkonda. Kasutades teenuste avastamist, suudame maksimaalselt eraldada kas konteineri, nagu Dockeri, või virtuaalse teenuse keskkonnast, kus see on käivitatud.
Kuidas see välja näeb? Klassikalises veebinäites on see frontend, mis võtab kasutaja päringu vastu. Edasi suunatakse see backend'ile. Antud näites tasakaalustab load-balancer kahte backend'i.
Siit näeme, et käivitame rakenduse kolmanda eksemplari. Seega, kui rakendus käivitatakse, registreerib see end teenuste leidmise süsteemis. Teenuste leidmise süsteem teavitab koormuse jaoturit. Koormuse jaotur muudab automaatselt oma konfiguratsiooni ja uus taust teenus hakkab tööle. Nii saab taustteenuseid lisada või, vastupidi, eemaldada töö seest.
Mida veel on mugav teha teenuste leidmise süsteemi abil? Teenuste leidmise süsteemis võivad olla salvestatud nginx konfiguratsioonid, sertifikaadid ja aktiivsete taustserverite nimekiri.
Samuti võimaldab teenuste leidmise süsteem tuvastada rikkeid ja avastada tõrkeid. Millised skeemid on võimalikud tõrgete tuvastamiseks?
- See rakendus, mille me välja töötasime, teavitab teenuste leidmise süsteemi, et see on endiselt töövõimeline.
- Teenuste leidmise süsteem omakorda küsib rakenduselt selle kättesaadavuse kohta.
- Või kasutatakse kolmandat osapoole skripti või rakendust, mis kontrollib meie rakenduse kättesaadavust ja teavitab teenuste leidmise süsteemi, et kõik on korras ja saab töötada, või vastupidi, et kõik on halvasti ja on vajalik see rakenduse eksemplar koormuse jaotusest eemaldada.
Iga skeem võib olla rakendatav sõltuvalt sellest, millist tarkvara me kasutame. Näiteks, kui oleme alles alustanud uue projekti arendamist, siis saame hõlpsasti rakendada skeemi, kus meie rakendus teavitab Service Discovery't. Samuti võime seadistada, et Service Discovery teostab kontrolli.
Kuid juhul, kui rakendus on meile pärandatud või loodud mõne kolmanda osapoole poolt, sobib siinkohal kolmas variant, kus kirjutame töötleja, ja kõik see liitub meie tööprotsessiga automaatselt.
See on üks näide. Nginx koormuse tasakaalustaja taaskäivitub. See on täiendav utiliit, mis on saadaval koos Consuliga. See on consul-template. Me määratleme reegli. Ütleme, et kasutame mallisüsteemi (Golang template). Sündmuste korral, teavitustega, et on toimunud muutusi, see genereeritakse uuesti ja Service Discovery saadab käsu "reload". Lihtne näide, kuidas nginx konfigureeritakse ümber ja taaskäivitub sündmuse korral.
Mis on Consul?
Esiteks – see on Service Discovery.
Tal on kättesaadavuse kontrollimise mehhanism – Health Checking.
Samuti on tal KV Store.
Ja selle põhialuseks on Multi Datacenter'i kasutamise võimalus.
Milleks see kõik mõeldud on? KV Store'is saame hoida konfigureerimise näiteid. Health Checking võimaldab meil kontrollida kohalikke teenuseid ja teavitada neist. Multi Datacenter võimaldab luua teenuste kaarti. Näiteks Amazonil on mitu tsooni ja see suunab liiklust kõige optimaalsemalt, vältides liigseid päringuid andmekeskuste vahel, mis on eraldi tasustatud kohaliku liikluse kõrval ning seega madalama latentsusega.
Läheme veidi sügavamale terminolooge, mida Consul kasutab.
- Consul on Go keeles kirjutatud teenus. Üks Go programmi eeliseid on see, et see on 1 binaarfail, mille lihtsalt alla laadid. Käivita see igast kohast ja sul ei ole mingeid sõltuvusi.
- Edasi saame võtmete abil käivitada selle teenuse kas kliendi või serveri režiimis.
- Samuti võimaldab atribuut „datacenter” seada lipu, millisele andmekeskusele see server kuulub.
- Konsensus – põhineb raft-protokolil. Huvi korral saab selle kohta lähemalt lugeda Consul'i veebisaidilt. See on protokoll, mis võimaldab määrata juhti ja otsustada, millised andmed on kehtivad ja kättesaadavad.
- Gossip – see on protokoll, mis tagab suhtlemise sõlmede vahel. Lisaks on see süsteem detsentraliseeritud. Ühes andmekeskuses suhtlevad kõik sõlmed naabritega. Seega edastatakse üksteisele teavet hetkeolukorra kohta. Võib öelda, et need on naabrite vahelised kuulujutud.
- LAN Gossip – kohalike andmete vahetamine naabrite vahel ühes andmekeskuses.
- WAN Gossip – kasutatakse, kui on vaja sünkroonida teavet kahe andmekeskuse vahel. Teave liigub serveriks märgitud sõlmede vahel.
- RPC – võimaldab teha päringute saatesüsteemi kaudu kliendilt serverisse.
RPC kirjeldus. Oletame, et virtuaalses masinas või füüsilisel serveril on käimas Consul kliendina. Me pöördume selle poole kohalikult. Edasi pärib kohalik klient teavet serverilt ja sünkroniseerib. Teave võib sõltuvalt seadistustest pärineda kohalikust vahemälust või olla sünkroniseeritud liidri ehk serveri meistriga.
Neil kahel skeemil on nii eeliseid kui ka puuduseid. Kui me töötame kohaliku vahemäluga, on see kiire. Kui me töötame serveris salvestatud andmetega, siis see kestab kauem, kuid saame aktuaalsema teabe.
Kui seda visuaalselt kujutada, siis näeks see välja nii. Nähes, et meil on käimas kolm meistrit. Üht tähekesega märgitud kui liider. Antud näites on kolm klienti, kes vahetavad üksteisega kohalikult teavet läbi UDP/TCP. Ja teave andmekeskuste vahel edastatakse serverite vahel. Siin suhtlevad kliendid omavahel kohalikult.
Millist API-d Consul pakub? Teabe saamiseks on Consulil kaks tüüpi API-d.
See on DNS API. Vaikimisi töötab Consul porti 8600 peal. Saame seadistada päringute proximise ja tagada juurdepääsu kohaliku lahenduse kaudu, kohaliku DNS-i kaudu. Saame pärida domeeni ja saada vastuseks IP-aadressi teabe.
HTTP API – me saame kas kohalikult 8500 porti kaudu pärida konkreetse teenuse teavet ja saada JSON-vastuse, milline IP serveril on, milline host, milline port on registreeritud. Ja lisateavet saab edastada ka tokeni kaudu.
Mida on vaja, et käivitada Consul?
Esimeses variandis näitame arenduse režiimis lippu, et see on arenduse režiim. Agent käivitub serverina. Ja kogu funktsiooni täidab juba iseseisvalt ühel masinal. Mugav, kiire ja praktiliselt ei vaja esmakäivitamiseks mingeid täiendavaid seadistusi.
Teine režiim on tootmisrežiim. Siin käivitamine on veidi keerulisem. Kui meil pole ühtegi konsultandi versiooni, peame viima esimeses seadmes boottarkvara, s.t. seadme, mis võtab enda kanda juhi ülesanded. Käivitame selle, seejärel käivitame teise serveri eksemplari, edastades talle teabe, kus meie master asub. Käivitame kolmanda. Kui meil on kolm seadet töötamas, taaskäivitame esimeses seadmes boottarkvara tavarežiimis. Andmed sünkroniseeritakse ja algne klaster on juba üles tõstetud.
Soovitatav on käivitada kolm kuni seitse eksemplari serverirežiimis. See tuleneb sellest, et kui serverite arv kasvab, pikeneb ka teabe sünkroniseerimise aeg nende vahel. Nodide arv peab olema paaritu, et tagada kvoorum.
Kuidas tagatakse tervisekontrollid? Konsuli konfiguratsioonikausta kirjutame Json vormis kontrollreeglid. Esimene variant on ligipääsetavus antud näites domeenile google.com. Ja ütleme, et iga 30 sekundi järel tuleb seda kontrolli teha. Nii kontrollime, et meie node-l on ligipääs välisesse võrku.
Teine variant on enda kontrollimine. Kutsume localhost'i antud pordi kaudu välja tavalise curl'i iga 10 sekundi järel.
Need kontrollid summeeritakse ja edastatakse Service Discovery'le. Saadavuse alusel välistatakse need sõlmed või nad ilmuvad kergesti kergesti töötavate masinate nimekirja.
Consul pakub ka UI-liidese, mis käivitatakse eraldi lipu abil ja on masinas saadaval. See võimaldab vaadata teavet ning teha teatud muudatusi.
Antud näites on avatud vahekaart „Teenused”. Näha, et on käimas kolm teenust, neist üks on Consul. Näidatakse läbiviidud kontrollide arvu ja kolme andmekeskust, kus masinad asuvad.
See on näide vahekaardist „Nodes”. Näeme, et neil on koostisosade nimed, mis sisaldavad andmekeskusi. Siin on näha ka, millised teenused on käimas, st näeme, et silte ei ole määratud. Nendes lisasiltes võidakse määrata teavet, mida arendaja saab kasutada täiendavate parameetrite määramiseks.
Samuti saab Consul'ile edastada teavet ketta oleku, keskmise koormuse kohta.
Küsimused
Küsimus: Meil on Docker konteiner, kuidas seda Consuliga kasutada?
Vastus: Docker konteinerite jaoks on mitu lähenemist. Üks levinumaid on kasutada kolmanda osapoole Docker konteinerit, mis vastutab registreerimise eest. Käivitamisel edastatakse talle Docker socket. Kõik registreerimise ja eemaldamise sündmused kantakse üle Consulile.
Küsimus: Kas Consul käivitab Docker konteineri ise?
Vastus: Ei, me käivitame Docker konteineri. Ja konfigureerimisel näitame, et kuulame sellist socketit. See on umbes sama, nagu töötades sertifikaadiga, kui edastame teavet selle kohta, kus ja mis meil asub.
Küsimus: Kas see tähendab, et Docker konteineris, mille üritame ühendada Service Discoveryga, peab olema mingi loogika, mis suutis andmeid Consulile edastada?
Vastus: Mitte päris. Kui see käivitub, siis edastame keskkonnamuutujate kaudu muutujad. Oletame, teenuse nimi, teenuse port. Register kuulab seda teavet ja kannab selle Consulisse.
Küsimus: Mul on veel üks küsimus UI kohta. Oleme käivitanud UI, oletame, tootmisserveris. Kuidas on turvalisusega? Kus andmeid hoitakse? Kas on võimalik andmeid kuidagi koguda?
Küsimus: Kas see on võimalik avaldada internetis?
Vastus: UI-s on tõepoolest andmed andmebaasist ja Service Discovery-st. Paroolid seadistame ise.
Vastus: Vaikimisi käivitub Consul localhost-is. Selleks, et avaldada internetis, tuleb installeerida mingi proxy. Turvaseaduste eest vastutame ise.
Küsimus: Kas ajaloolisi andmeid pakutakse vaikimisi? Oleks huvitav näha statistikat Health Checks-i kohta. Probleeme saab ju diagnostiseerida, kui server sageli kokku kukub.
Vastus: Ma ei ole kindel, kas seal on päris üksikasjade kontrollimist.
Küsimus: Praegune olek ei ole nii oluline, kui oluline on dünaamika.
Vastus: Analüüsimiseks – jah.
Küsimus: Kas Consul'i kasutamine dokkeri jaoks pole soovitatav?
Vastus: Ma ei soovitaks seda kasutada. Ettepaneku eesmärk on tutvustada, et selline mõisted olemas on. Ajalooliselt on ta läbinud tee, minu arvates, kuni 1. versioonini. Praegu on olemas juba täielikumad lahendused, näiteks Kubernetes, mis omab seda kõike. Kubernetes'is jääb Service Discovery Etcd-ile alla. Kuid ma ei tunne seda nii hästi kui Consul-iga. Seetõttu otsustasin Service Discovery näidata Consul'i näitel.
Küsimus: Kas juhi serveriga skeem ei takista rakenduse käivitamist tervikuna? Kuidas Consul määrab uue juhi, kui olemasolev on maas?
Vastus: Neil on palju protokollidest. Kui huvitav, siis saad lugeda.
Küsimus: Kas Consul tegutseb meil täieliku serverina ja kõik päringud liiguvad selle kaudu?
Vastus: Ta ei tegutse täieliku serverina, vaid katab kindla ala. See lõppeb tavaliselt service.consul. Ja edasi liigume loogika järgi. Me ei kasuta tootmises domeeninimesid, vaid sisemist infrastruktuuri, mis tavaliselt peidetakse serveri vahemälu taha, kui me töötame DNS-iga.
Küsimus: St kui soovime andmebaasile ligi pääseda, siis peame igal juhul Consul'ilt küsima, et kõigepealt see andmebaas leida, eks?
Vastus: Jah. Kui töötame DNS-iga, siis see toimib nagu Consul'i kasutamata, kui kasutame DNS-nimesid. Kõige moodsamad rakendused ei küsi igas päringus domeeninime, kuna meil on ühendus loodud, kõik toimib ja me ei kasuta seda lähiajal. Kui ühendus katkeb, siis – jah, küsime jälle, kus meie andmebaas asub ja liigume sinna.
— HashiCorpi kasutajate jututuba: Consul, Nomad, Terraform
P.S. Seotud tervisekontrollidega. Consulis, nagu ka Kuberneteses, kasutatakse sama teenuse elujõu kontrollimise süsteemi, mis põhineb staatuse koodil.
200 OK terve jaoks
503 Teenus ei ole kergesti saadaval haige jaoksAllikad:
Allikas: habr.com
