Suosittelen, että luet Alexander Sigachevin raportin Service Discovery hajautetuissa järjestelmissä transkription käyttämällä esimerkkiä Consulista.
Service Discovery luotiin niin, että voit liittää uuden sovelluksen olemassa olevaan ympäristöömme mahdollisimman pienin kustannuksin. Service Discoveryn avulla voimme maksimaalisesti erottaa joko telakointikontin tai virtuaalisen palvelun ympäristöstä, jossa se toimii.
Toivotan kaikki tervetulleiksi! Olen Alexander Sigachev, työskentelen Inventoksella. Ja tänään esittelen sinulle sellaisen käsitteen kuin Service Discovery. Katsotaanpa Service Discovery -palvelua käyttämällä esimerkkinä Consulia.
Mitä ongelmia Service Discovery ratkaisee? Service Discovery luotiin niin, että voit liittää uuden sovelluksen olemassa olevaan ympäristöömme mahdollisimman pienin kustannuksin. Service Discoveryn avulla voimme maksimaalisesti erottaa joko telakointikontin tai virtuaalisen palvelun ympäristöstä, jossa se toimii.
Miltä se näyttää? Klassisessa esimerkissä verkossa tämä on käyttöliittymä, joka hyväksyy käyttäjän pyynnön. Sitten se reitittää sen taustajärjestelmään. Tässä esimerkissä tämä kuormituksen tasapainottaja tasapainottaa kaksi taustaohjelmaa.
Tässä näemme, että käynnistämme sovelluksen kolmannen esiintymän. Vastaavasti, kun sovellus käynnistyy, se rekisteröityy Service Discovery -palveluun. Service Discovery ilmoittaa kuormituksen tasapainottajalle. Load-balancer muuttaa konfiguraatiotaan automaattisesti ja uusi taustaosa otetaan käyttöön. Tällä tavalla taustaohjelmia voidaan lisätä tai päinvastoin sulkea pois toiminnasta.
Mitä muuta on kätevää tehdä Service Discoveryn avulla? Service Discovery voi tallentaa nginx-määrityksiä, varmenteita ja luettelon aktiivisista taustapalvelimista.
Palvelun etsinnän avulla voit myös havaita vikoja ja havaita vikoja. Mitkä ovat mahdolliset menetelmät vikojen havaitsemiseksi?
- Tämä kehittämämme sovellus ilmoittaa automaattisesti Service Discoverylle, että se on edelleen toiminnassa.
- Service Discovery puolestaan tekee kyselyn sovelluksen saatavuudesta.
- Tai käytämme kolmannen osapuolen komentosarjaa tai sovellusta, joka tarkistaa sovelluksemme saatavuuden ja ilmoittaa Service Discoverylle, että kaikki on kunnossa ja voi toimia, tai päinvastoin, että kaikki on huonosti ja tämä sovelluksen esiintymä on jätettävä tasapainotuksen ulkopuolelle.
Jokaista mallia voidaan käyttää riippuen siitä, mitä ohjelmistoja käytämme. Esimerkiksi aloitimme juuri uuden projektin kehittämisen, jolloin voimme helposti tarjota järjestelmän, kun sovelluksemme ilmoittaa Service Discoverylle. Tai voimme yhdistää sen Service Discovery -toiminnon tarkistamaan.
Jos olemme perineet sovelluksen tai sen on kehittänyt joku muu, niin kolmas vaihtoehto sopii käsittelijän kirjoittamiseen, ja kaikki tämä tulee työhön automaattisesti.
Tämä on yksi esimerkki. Kuormituksen tasapainottaja nginxin muodossa käynnistetään uudelleen. Tämä on valinnainen apuohjelma, joka toimitetaan Consulin mukana. Tämä on konsulimalli. Kuvaamme sääntöä. Sanomme, että käytämme mallia (Golang Template Engine). Kun tapahtumia tapahtuu, kun ilmoituksia muutoksista on tapahtunut, se luodaan uudelleen ja "reload"-komento lähetetään Service Discoverylle. Yksinkertaisin esimerkki on, kun tapahtuma määrittää nginxin uudelleen ja käynnistetään uudelleen.
Mikä on konsuli?
-
Ensinnäkin tämä on Service Discovery.
-
Siinä on saatavuuden tarkistusmekanismi - Health Checking.
-
Siinä on myös KV Store.
-
Ja se perustuu kykyyn käyttää Multi Datacenteria.
Mihin tätä kaikkea voidaan käyttää? KV Storessa voimme tallentaa esimerkkikonfiguraatioita. Terveystarkastuksessa voimme tarkistaa paikallisen palvelun ja ilmoittaa. Multi Datacenteria käytetään palvelukartan rakentamiseen. Esimerkiksi Amazonilla on useita vyöhykkeitä ja se reitittää liikenteen optimaalisella tavalla, jotta konesalien välillä ei tule tarpeettomia pyyntöjä, jotka veloitetaan erikseen paikallisesta liikenteestä ja vastaavasti niillä on vähemmän latenssia.
Ymmärrämme vähän termejä, joita käytetään konsulissa.
- Consul on Go-kielellä kirjoitettu palvelu. Yksi Go-ohjelman eduista on yksi binääritiedosto, jonka lataat vain. Käynnistetty mistä tahansa, eikä sinulla ole riippuvuuksia.
- Tämän jälkeen voimme avainten avulla käynnistää tämän palvelun joko asiakastilassa tai palvelintilassa.
- Lisäksi “datacenter”-attribuutin avulla voit määrittää lipun, mihin datakeskukseen tämä palvelin kuuluu.
- Konsensus – lauttaprotokollan perusteella. Jos jotakuta kiinnostaa, voit lukea aiheesta lisää konsulin sivuilta. Tämä on protokolla, jonka avulla voit määrittää johtajan ja määrittää, mitkä rahat ovat kelvollisia ja saatavilla.
- Gossip on protokolla, joka mahdollistaa solmujen välisen vuorovaikutuksen. Lisäksi tämä järjestelmä on hajautettu. Yhdessä datakeskuksessa kaikki solmut kommunikoivat naapuriensa kanssa. Ja vastaavasti tiedot nykyisestä tilasta välitetään toisilleen. Voimme sanoa, että tämä on naapureiden välistä juorua.
- LAN Gossip – paikallinen tiedonvaihto naapureiden välillä saman datakeskuksen sisällä.
- WAN Gossip - käytetään, kun meidän on synkronoitava tietoja kahden datakeskuksen välillä. Tieto kulkee palvelimeksi merkittyjen solmujen välillä.
- RPC – mahdollistaa pyyntöjen suorittamisen palvelimella olevan asiakkaan kautta.
RPC:n kuvaus. Oletetaan, että Consul toimii asiakkaana virtuaalikoneella tai fyysisellä palvelimella. Otamme häneen yhteyttä paikallisesti. Ja sitten paikallinen asiakas pyytää tietoja palvelimelta ja synkronoituu. Asetuksista riippuen tiedot voidaan hakea paikallisesta välimuistista tai synkronoida johtajan kanssa palvelimen isäntäpalvelimen kanssa.
Näillä kahdella järjestelmällä on sekä hyviä että huonoja puolia. Jos työskentelemme paikallisen välimuistin kanssa, se on nopeaa. Jos työskentelemme palvelimelle tallennettujen tietojen kanssa, se kestää kauemmin, mutta saamme asiaankuuluvampaa tietoa.
Jos kuvaat tämän graafisesti, tämä on sivuston kuva. Näemme, että meillä on kolme mestaria käynnissä. Yksi on merkitty tähdellä johtajana. Tässä esimerkissä on kolme asiakasta, jotka vaihtavat tietoja paikallisesti toistensa kanssa UDP/TCP:n kautta. Ja tietokeskusten välinen tieto siirretään palvelimien välillä. Täällä asiakkaat ovat vuorovaikutuksessa toistensa kanssa paikallisesti.
Minkä API:n Consul tarjoaa? Tietojen saamiseksi Consulilla on kahden tyyppinen API.
Tämä on DNS API. Oletuksena Consul toimii portissa 8600. Voimme määrittää välityspalvelinpyynnön ja tarjota pääsyn paikallisen resoluution, paikallisen DNS:n kautta. Voimme tehdä kyselyn verkkotunnuksen mukaan ja saada IP-osoitetiedot vastauksena.
HTTP API - tai voimme paikallisesti pyytää tietoja tietystä palvelusta portissa 8500 ja saada JSON-vastauksen, mikä IP palvelimella on, mikä isäntä, mikä portti on rekisteröity. Ja lisätietoa voidaan välittää tunnuksen kautta.
Mitä tarvitset konsulin johtamiseen?
Ensimmäisessä vaihtoehdossa, kehittäjätilassa, osoitamme lipun, että tämä on kehittäjätila. Agentti aloittaa palvelimena. Ja se suorittaa koko toiminnon itsenäisesti yhdessä koneessa. Kätevä, nopea ja käytännössä ei vaadi lisäasetuksia ensimmäiseen käynnistykseen.
Toinen tila käynnistetään tuotantoon. Tässä aloittaminen on hieman monimutkaista. Jos meillä ei ole mitään versiota konsulista, meidän on tuotava ensimmäinen kone bootstrapiin, eli tämä kone, joka ottaa johtajan vastuut. Nostamme sen, sitten nostamme palvelimen toisen esiintymän ja välitämme sille tiedot, missä isäntämme sijaitsee. Nostamme kolmannen. Kun meillä on kolme konetta käytössä, käynnistämme sen uudelleen normaalitilassa ensimmäisessä koneessa käynnissä olevasta bootstrapista. Tiedot synkronoidaan ja alkuperäinen klusteri on jo valmis.
On suositeltavaa suorittaa kolmesta seitsemään esiintymää palvelintilassa. Tämä johtuu siitä, että jos palvelimien määrä kasvaa, niiden välinen tietojen synkronointiaika kasvaa. Solmujen määrän on oltava pariton päätösvaltaisuuden varmistamiseksi.
Miten terveystarkastukset tarjotaan? Kirjoitamme vahvistussäännön Json-muodossa Consul-määrityshakemistoon. Ensimmäinen vaihtoehto on google.com-verkkotunnuksen saatavuus tässä esimerkissä. Ja sanomme, että tämä tarkistus on suoritettava 30 sekunnin välein. Tällä tavalla tarkistamme, että solmullamme on pääsy ulkoiseen verkkoon.
Toinen vaihtoehto on tarkistaa itsesi. Käytämme tavallista curl-toimintoa soittaaksemme localhostille määritetyssä portissa 10 sekunnin välein.
Näistä tarkistuksista tehdään yhteenveto ja lähetetään Service Discovery -palveluun. Saatavuuden perusteella nämä solmut joko suljetaan pois tai näkyvät saatavilla olevien ja oikein toimivien koneiden luettelossa.
Consul tarjoaa myös käyttöliittymän, joka käynnistetään erillisellä lipulla ja on käytettävissä koneessa. Tämän avulla voit tarkastella tietoja ja voit myös tehdä joitain muutoksia.
Tässä esimerkissä "Palvelu"-välilehti on auki. On osoitettu, että kolme palvelua on käynnissä, yksi niistä on konsuli. Tehtyjen tarkastusten määrä. Ja siellä on kolme datakeskusta, joissa koneet sijaitsevat.
Tämä on esimerkki Solmut-välilehdestä. Näemme, että niillä on yhdistetyt nimet, joihin liittyy datakeskuksia. Se näyttää myös, mitkä palvelut ovat käynnissä, eli näemme, ettei tunnisteita ole asetettu. Nämä lisätunnisteet voivat tarjota tietoja, joita kehittäjä voi käyttää lisäparametrien määrittämiseen.
Voit myös välittää Consulille tietoa levyjen tilasta ja keskimääräisestä kuormituksesta.
kysymykset
Kysymys: Meillä on telakointikontti, kuinka sitä käytetään Consulin kanssa?
Vastaus: Docker-konttiin on olemassa useita lähestymistapoja. Yksi yleisimmistä on rekisteröinnistä vastaavan kolmannen osapuolen telakointisäiliön käyttö. Käynnistettäessä siihen välitetään telakointiasema. Kaikki konttien rekisteröinti- ja julkaisutapahtumat kirjataan Consuliin.
Kysymys: Joten konsul itse käynnistää telakointikontin?
Vastaus: Ei. Meillä on käytössä telakointikontti. Ja konfiguroitaessa ilmoitamme - kuuntele sellaista ja sellaista pistorasiaa. Tämä on suunnilleen sama kuin työskentely varmenteen kanssa, kun lataamme tietoja siitä, missä ja mitä meillä on.
Kysymys: Osoittautuu, että Docker-kontin sisällä, jota yritämme yhdistää Service Discoveryyn, pitäisi olla jonkinlainen logiikka, joka voi lähettää tietoja konsulille?
Vastaus: Ei oikeastaan. Kun se alkaa, siirrämme muuttujat ympäristömuuttujan läpi. Sanotaan palvelun nimi, huoltoportti. Rekisteri kuuntelee nämä tiedot ja syöttää ne konsulille.
Kysymys: Minulla on toinen kysymys käyttöliittymästä. Otimme käyttöliittymän käyttöön esimerkiksi tuotantopalvelimella. Entä turvallisuus? Mihin tiedot tallennetaan? Onko mahdollista kerätä tietoja jotenkin?
Vastaus: Käyttöliittymässä on tietoa tietokannasta ja Service Discoverysta. Asetamme salasanat asetuksiin itse.
Kysymys: Voiko tämän julkaista Internetissä?
Vastaus: Oletuksena Consul käynnistyy localhostissa. Jos haluat julkaista Internetissä, sinun on asennettava jonkinlainen välityspalvelin. Olemme vastuussa omista turvallisuussäännöistämme.
Kysymys: Tarjoaako se historiallisia tietoja heti valmiina? On mielenkiintoista katsoa terveystarkastuksia koskevia tilastoja. Voit myös diagnosoida ongelmia, jos palvelin usein epäonnistuu.
Vastaus: En ole varma, onko siellä tarkat tiedot shekistä.
Kysymys: Nykytila ei ole niin tärkeä kuin dynamiikka.
Vastaus: Analyysi - kyllä.
Kysymys: Onko parempi olla käyttämättä Service Discovery for Consul dockeria?
Vastaus: En suosittele sen käyttöä. Raportin tarkoituksena on esitellä, mitä tällainen käsite on olemassa. Historiallisesti se on mielestäni päässyt tiensä ensimmäiseen versioon. Nyt on jo valmiimpia ratkaisuja, esimerkiksi Kubernetes, jolla on kaikki tämä konepellin alla. Osana Kubernetes Service Discovery on huonompi kuin Etcd. Mutta en ole niin perehtynyt siihen kuin konsulin. Siksi päätin tehdä Service Discoveryn käyttämällä esimerkkiä Consulista.
Kysymys: Eikö järjestelmä johtajapalvelimella hidasta sovelluksen käynnistymistä kokonaisuudessaan? Ja miten konsuli määrittää uuden johtajan, jos tämä valehtelee?
Vastaus: Heillä on kuvattu koko protokolla. Jos olet kiinnostunut, voit lukea sen.
Kysymys: Konsuli toimii täysimittaisena palvelimena meille ja kaikki pyynnöt lentävät sen kautta?
Vastaus: Se ei toimi täysimittaisena palvelimena, vaan hallitsee tietyn alueen. Yleensä se päättyy palveluun.konsuli. Ja sitten mennään loogisesti. Emme käytä tuotannossa verkkotunnuksia, vaan sisäistä infrastruktuuria, joka on yleensä piilotettu palvelimen välimuistin taakse, jos työskentelemme DNS:n avulla.
Kysymys: Eli jos haluamme käyttää tietokantaa, vedämme joka tapauksessa konsulin etsimään tämän tietokannan ensin, eikö niin?
Vastaus: Kyllä. Jos käytämme DNS-nimiä, se toimii samoin kuin ilman Consulia, kun käytämme DNS-nimiä. Tyypillisesti nykyaikaiset sovellukset eivät vedä verkkotunnusta jokaiseen pyyntöön, koska asensimme yhteyden, kaikki toimii ja lähitulevaisuudessa emme käytännössä käytä sitä. Jos yhteys katkeaa, niin kyllä, kysymme jälleen missä tukikohtamme on ja menemme siihen.
— Hashicorpin käyttäjäkeskustelu: konsuli, Nomad, Terraform
PS Mitä tulee terveystarkastuksiin. Consul, kuten Kubernetes, käyttää samaa järjestelmää palvelun selviytymistilan tarkistamiseen koodin tilan perusteella.
200 OK for healthy
503 Service Unavailable for unhealthyLähteet:
Lähde: will.com