Soovitan teil lugeda Aleksander Sigatšovi raporti "Teenuse avastamine hajutatud süsteemides" ärakirja, kasutades näitena Consulit.
Service Discovery loodi selleks, et saaksite minimaalse kuluga ühendada uue rakenduse meie olemasoleva keskkonnaga. Service Discovery abil saame maksimaalselt eraldada dokkeri konteineri või virtuaalteenuse keskkonnast, milles see töötab.
Tervitan kõiki! Olen Aleksander Sigatšov, töötan Inventoses. Ja täna tutvustan teile sellist kontseptsiooni nagu Service Discovery. Vaatame teenuse avastamist, kasutades näitena Consulit.
Milliseid probleeme teenusetuvastus lahendab? Service Discovery loodi selleks, et saaksite minimaalse kuluga ühendada uue rakenduse meie olemasoleva keskkonnaga. Service Discovery abil saame maksimaalselt eraldada dokkeri konteineri või virtuaalteenuse keskkonnast, milles see töötab.
Kuidas see välja näeb? Klassikalises näites veebis on see esiots, mis võtab kasutaja taotluse vastu. Seejärel suunab see selle taustaprogrammi. Selles näites tasakaalustab see koormuse tasakaalustaja kahte taustaprogrammi.
Siin näeme, et käivitame rakenduse kolmanda eksemplari. Seetõttu registreerub rakendus, kui rakendus käivitub, teenuses Service Discovery. Service Discovery teavitab koormuse tasakaalustajat. Load-balancer muudab oma konfiguratsiooni automaatselt ja uus taustaprogramm läheb tööle. Sel viisil saab taustaprogramme lisada või, vastupidi, tööst välja jätta.
Mida on teenusetuvastusega veel mugav teha? Service Discovery saab salvestada nginxi konfiguratsioone, sertifikaate ja aktiivsete taustaserverite loendit.
Service Discovery võimaldab teil tuvastada ka tõrkeid ja tuvastada tõrkeid. Millised on võimalikud rikete tuvastamise skeemid?
- See meie välja töötatud rakendus teavitab automaatselt teenusetuvastust, et see on endiselt töökorras.
- Service Discovery küsitleb omalt poolt rakenduse saadavust.
- Või kasutame kolmanda osapoole skripti või rakendust, mis kontrollib meie rakenduse saadavust ja teatab Service Discoveryle, et kõik on korras ja võib töötada, või vastupidi, et kõik on halvasti ja see rakenduse eksemplar tuleb tasakaalustamisest välja jätta.
Kõiki skeeme saab kasutada sõltuvalt sellest, millist tarkvara me kasutame. Näiteks alustasime just uue projekti väljatöötamisega, siis saame hõlpsasti pakkuda skeemi, kui meie rakendus teatab Service Discoveryle. Või saame ühenduse luua, mida teenusetuvastus kontrollib.
Kui rakenduse saime päranduseks või selle on arendanud keegi teine, siis sobib töötleja kirjutamisel kolmas variant ja see kõik tuleb meie töösse automaatselt.
See on üks näide. Koormuse tasakaalustaja nginxi kujul taaskäivitatakse. See on valikuline utiliit, mis on Consuliga kaasas. See on konsuli mall. Kirjeldame reeglit. Me ütleme, et kasutame malli (Golangi mallimootor). Sündmuste ilmnemisel, kui teatatakse muudatuste toimumisest, genereeritakse see uuesti ja käsk „Reload” saadetakse teenusetuvastusse. Lihtsaim näide on see, kui nginx konfigureeritakse sündmusega ümber ja taaskäivitatakse.
Mis on konsul?
-
Esiteks on see Service Discovery.
-
Sellel on saadavuse kontrollimise mehhanism – tervisekontroll.
-
Sellel on ka KV pood.
-
Ja see põhineb mitme andmekeskuse kasutamise võimalusel.
Milleks seda kõike kasutada saab? KV Store'is saame salvestada näidiskonfiguratsioone. Tervisekontrolli saame kontrollida kohalikku teenindust ja teavitada. Multi Datacenterit kasutatakse teenusekaardi koostamiseks. Näiteks Amazonil on mitu tsooni ja see suunab liiklust kõige optimaalsemal viisil, et andmekeskuste vahel ei tekiks tarbetuid päringuid, mille eest võetakse kohalikust liiklusest eraldi tasu ja mille latentsusaeg on seega väiksem.
Saagem veidi aru mõistetest, mida konsulis kasutatakse.
- Consul on Go keeles kirjutatud teenus. Üks Go programmi eeliseid on 1 binaarfail, mille te lihtsalt alla laadite. Käivitatud kõikjalt ja teil pole mingeid sõltuvusi.
- Seejärel saame klahvide abil selle teenuse käivitada kas kliendi- või serverirežiimis.
- Samuti võimaldab atribuut "andmekeskus" määrata lipu, millisesse andmekeskusesse see server kuulub.
- Konsensus – parveprotokolli alusel. Kellel on huvi, saab selle kohta täpsemalt lugeda konsuli kodulehelt. See on protokoll, mis võimaldab teil määrata juhi ja määrata, millist raha peetakse kehtivaks ja juurdepääsetavaks.
- Gossip on protokoll, mis võimaldab sõlmede vahelist suhtlust. Pealegi on see süsteem detsentraliseeritud. Ühes andmekeskuses suhtlevad kõik sõlmed oma naabritega. Ja vastavalt sellele edastatakse teave praeguse oleku kohta üksteisele. Võime öelda, et see on naabritevaheline kuulujutt.
- LAN Gossip – kohalik andmevahetus naabrite vahel samas andmekeskuses.
- WAN Gossip – kasutatakse siis, kui meil on vaja teavet kahe andmekeskuse vahel sünkroonida. Teave liigub serveriteks märgitud sõlmede vahel.
- RPC – võimaldab täita päringuid serveris oleva kliendi kaudu.
RPC kirjeldus. Oletame, et Consul töötab kliendina virtuaalses masinas või füüsilises serveris. Võtame temaga kohapeal ühendust. Seejärel küsib kohalik klient serverilt teavet ja sünkroonitakse. Sõltuvalt seadistustest saab teavet hankida kohalikust vahemälust või sünkroonida juhiga, serveri ülemseadmega.
Neil kahel skeemil on nii plusse kui ka miinuseid. Kui töötame kohaliku vahemäluga, on see kiire. Kui töötame serveris salvestatud andmetega, võtab see kauem aega, kuid saame asjakohasemat teavet.
Kui kujutate seda graafiliselt, on see saidi pilt. Näeme, et meil jookseb kolm meistrit. Üks on juhina tähistatud tärniga. Selles näites on kolm klienti, kes vahetavad omavahel UDP/TCP kaudu teavet kohapeal. Andmekeskuste vaheline teave edastatakse serverite vahel. Siin suhtlevad kliendid üksteisega kohapeal.
Millist API-d Consul pakub? Teabe hankimiseks on Consulil kahte tüüpi API.
See on DNS API. Vaikimisi töötab Consul pordil 8600. Saame konfigureerida puhverserveri taotlemise ja pakkuda juurdepääsu kohaliku eraldusvõime kaudu kohaliku DNS-i kaudu. Saame päringuid teha domeeni järgi ja vastuseks saada IP-aadressi teavet.
HTTP API - või me saame kohapeal küsida teavet konkreetse teenuse kohta pordis 8500 ja saada JSON-vastus, mis IP serveril on, milline host, milline port on registreeritud. Ja lisateavet saab edastada märgi kaudu.
Mida on teil konsuli juhtimiseks vaja?
Esimeses valikus näitame arendaja režiimis lippu, et see on arendaja režiim. Agent alustab serverina. Ja see täidab kogu funktsiooni iseseisvalt ühel masinal. Mugav, kiire ja esmakordsel käivitamisel pole praktiliselt mingeid lisaseadeid vaja.
Teine režiim käivitatakse tootmises. Siin muutub käivitamine pisut keeruliseks. Kui meil pole ühtegi konsuli versiooni, siis peame tooma alglaadimisseadmesse esimese masina, st selle masina, mis võtab enda kanda juhi kohustused. Tõstame selle üles, seejärel tõstame serveri teise eksemplari, edastades sellele teabe, kus meie ülem asub. Tõstame kolmanda. Kui meil on kolm masinat üleval, taaskäivitame selle tavalises režiimis esimeses masinas töötavast alglaadimisest. Andmed sünkroonitakse ja esialgne klaster on juba üleval.
Serverirežiimis on soovitatav käivitada kolm kuni seitse eksemplari. See on tingitud asjaolust, et kui serverite arv kasvab, pikeneb nendevahelise teabe sünkroonimise aeg. Kvoorumi tagamiseks peab sõlmede arv olema paaritu.
Kuidas tervisekontrolle tehakse? Konsuli konfiguratsioonikataloogi kirjutame kinnitusreegli Jsoni kujul. Esimene võimalus on selles näites domeeni google.com saadavus. Ja me ütleme, et seda kontrolli tuleb teha 30-sekundiliste intervallidega. Nii kontrollime, kas meie sõlmel on juurdepääs välisvõrgule.
Teine võimalus on ennast kontrollida. Me kasutame tavalist curl'i, et helistada määratud pordile 10-sekundiliste intervallidega.
Need kontrollid võetakse kokku ja saadetakse teenusetuvastusse. Olenevalt saadavusest jäetakse need sõlmed välja või kuvatakse saadaolevate ja korrektselt töötavate masinate loendis.
Consul pakub ka kasutajaliidest, mis käivitatakse eraldi lipuga ja on masinas saadaval. See võimaldab teil teavet vaadata ja teha ka mõningaid muudatusi.
Selles näites on vahekaart „Teenus” avatud. Näidatakse, et töötab kolm teenust, üks neist on konsul. Läbiviidud kontrollide arv. Ja seal on kolm andmekeskust, kus masinad asuvad.
See on näide vahekaardilt Sõlmed. Näeme, et neil on liitnimed, mis hõlmavad andmekeskusi. See näitab ka, millised teenused töötavad, st näeme, et ühtegi silti pole määratud. Need lisasildid võivad anda teavet, mida arendaja saab kasutada täiendavate parameetrite määramiseks.
Samuti saate Consulile edastada teavet ketaste oleku ja keskmise koormuse kohta.
küsimused
Küsimus: Meil on dokkimiskonteiner, kuidas seda Consuliga kasutada?
Vastus: Dockeri konteineri jaoks on mitu lähenemisviisi. Üks levinumaid on registreerimise eest vastutava kolmanda osapoole dokkimiskonteineri kasutamine. Käivitamisel antakse sellele dokkipistikupesa. Kõik konteinerite registreerimise ja avaldamise tühistamise sündmused salvestatakse Consul'is.
Küsimus: Kas konsul käivitab ise dokkeri konteineri?
Vastus: Ei. Meil töötab dokkimiskonteiner. Ja seadistamisel näitame - kuulake sellist ja sellist pistikupesa. See on ligikaudu sama, mis me töötame sertifikaadiga, kui laadime üles teavet selle kohta, kus ja mis meil on.
Küsimus: Selgub, et Dockeri konteineris, mida proovime teenuse Discoveryga ühendada, peaks olema mingi loogika, mis saab konsulile andmeid saata?
Vastus: Mitte päris. Kui see käivitub, edastame muutujad keskkonnamuutuja kaudu. Ütleme teenuse nimi, teenindusport. Register kuulab selle teabe ära ja sisestab selle konsulisse.
Küsimus: mul on kasutajaliidese kohta veel üks küsimus. UI juurutasime näiteks tootmisserveris. Aga turvalisus? Kus andmeid hoitakse? Kas andmeid on võimalik kuidagi koguda?
Vastus: UI-s on andmed andmebaasist ja teenusetuvastusest. Paroolid määrame seadetes ise.
Küsimus: Kas seda saab Internetis avaldada?
Vastus: Vaikimisi käivitub Consul localhostis. Internetis avaldamiseks peate installima mingi puhverserveri. Vastutame oma ohutusreeglite eest ise.
Küsimus: kas see pakub ajaloolisi andmeid juba karbist väljas? Huvitav on vaadata tervisekontrolli statistikat. Samuti saate probleeme diagnoosida, kui server sageli ebaõnnestub.
Vastus: Ma pole kindel, et seal on tšekkide üksikasjad.
Küsimus: hetkeseis pole nii oluline kui dünaamika.
Vastus: Analüüsiks – jah.
Küsimus: Kas Consul dockeri jaoks on parem mitte kasutada teenuse avastamist?
Vastus: Ma ei soovita seda kasutada. Aruande eesmärk on tutvustada, mida selline mõiste eksisteerib. Ajalooliselt on see minu arvates jõudnud 1. versioonini. Nüüd on olemas juba terviklikumad lahendused, näiteks Kubernetes, millel on see kõik kapoti all. Osana Kubernetes Service Discovery on halvem kui jne. Kuid ma pole sellega nii kursis kui konsuliga. Seetõttu otsustasin teha teenuse Discovery, kasutades näitena Consulit.
Küsimus: kas juhtserveriga skeem ei aeglusta rakenduse kui terviku käivitamist? Ja kuidas määrab konsul uue juhi, kui see valetab?
Vastus: Neil on kirjeldatud terve protokoll. Kel huvi, võib lugeda.
Küsimus: konsul toimib meie jaoks täisväärtusliku serverina ja kõik päringud lendavad selle kaudu?
Vastus: See ei toimi täisväärtusliku serverina, vaid võtab üle kindla tsooni. Tavaliselt lõpeb see teenusega.konsul. Ja siis liigume loogiliselt edasi. Tootmises ei kasuta me domeeninimesid, vaid pigem sisemist taristut, mis DNS-i abil töötades on tavaliselt serveri vahemälu taga peidus.
Küsimus: See tähendab, et kui tahame juurdepääsu andmebaasile, siis igal juhul tõmbame konsuli kõigepealt selle andmebaasi üles otsima, eks?
Vastus: Jah. Kui töötame DNS-i kasutades, töötab see samamoodi nagu ilma Consulita, kui kasutame DNS-i nimesid. Tavaliselt ei tõmba kaasaegsed rakendused iga päringu puhul domeeninime, sest installisime ühenduse, kõik töötab ja lähitulevikus me seda praktiliselt ei kasuta. Kui ühendus katkeb, siis jah, küsime uuesti, kus on meie baas ja läheme selle juurde.
— Hashicorpi kasutajavestlus: konsul, nomad, terraform
P.S. Mis puudutab tervisekontrolli. Consul, nagu ka Kubernetes, kasutab koodi oleku alusel teenuse ellujäämisoleku kontrollimiseks sama süsteemi.
200 OK for healthy
503 Service Unavailable for unhealthyAllikad:
Allikas: www.habr.com