Otkrivanje usluga u distribuiranim sustavima na primjeru Consula. Aleksandar Sigačev

Predlažem da pročitate prijepis izvješća Alexandera Sigacheva Otkrivanje usluga u distribuiranim sustavima koristeći Consul kao primjer.

Service Discovery je kreiran kako biste uz minimalne troškove mogli povezati novu aplikaciju s našim postojećim okruženjem. Koristeći Service Discovery, možemo maksimalno odvojiti docker spremnik ili virtualnu uslugu od okruženja u kojem se izvodi.

Reproduciraj videozapis

pozdravljam sve! Ja sam Alexander Sigachev, radim u Inventosu. A danas ću vas upoznati s konceptom kao što je otkrivanje usluge. Pogledajmo Service Discovery koristeći Consul kao primjer.

Otkrivanje usluga u distribuiranim sustavima na primjeru Consula. Aleksandar Sigačev

Koje probleme rješava Service Discovery? Service Discovery je kreiran kako biste uz minimalne troškove mogli povezati novu aplikaciju s našim postojećim okruženjem. Koristeći Service Discovery, možemo maksimalno odvojiti docker spremnik ili virtualnu uslugu od okruženja u kojem se izvodi.

Kako izgleda? U klasičnom primjeru na webu, ovo je front end koji prihvaća zahtjev korisnika. Zatim ga usmjerava u pozadinu. U ovom primjeru, ovaj balanser opterećenja uravnotežuje dva pozadina.

Otkrivanje usluga u distribuiranim sustavima na primjeru Consula. Aleksandar Sigačev

Ovdje vidimo da pokrećemo treću instancu aplikacije. Sukladno tome, kada se aplikacija pokrene, registrira se u Service Discovery. Otkrivanje usluge obavještava balanser opterećenja. Load-balancer automatski mijenja svoju konfiguraciju i novi backend se stavlja u rad. Na taj se način pozadine mogu dodati ili, obrnuto, isključiti iz rada.

Otkrivanje usluga u distribuiranim sustavima na primjeru Consula. Aleksandar Sigačev

Što je još zgodno raditi s Otkrivanjem usluge? Service Discovery može pohraniti nginx konfiguracije, certifikate i popis aktivnih pozadinskih poslužitelja.

Otkrivanje usluga u distribuiranim sustavima na primjeru Consula. Aleksandar SigačevOtkrivanje usluga također vam omogućuje otkrivanje kvarova i otkrivanje kvarova. Koje su moguće sheme za otkrivanje kvarova?

  • Ova aplikacija koju smo razvili automatski obavještava Service Discovery da još uvijek radi.
  • Service Discovery, sa svoje strane, ispituje dostupnost aplikacije.
  • Ili koristimo skriptu ili aplikaciju treće strane koja provjerava dostupnost naše aplikacije i obavještava Service Discovery da je sve u redu i da može raditi ili, obrnuto, da je sve loše i ovu instancu aplikacije treba isključiti iz balansiranja.

Svaka od shema se može koristiti ovisno o tome koji softver koristimo. Na primjer, tek smo započeli s razvojem novog projekta, tada možemo lako pružiti shemu kada naša aplikacija obavijesti Otkrivanje usluge. Ili možemo povezati da Otkrivanje usluge provjerava.

Ako smo aplikaciju naslijedili ili ju je razvio netko drugi, onda je treća opcija prikladna kada pišemo rukovatelj, a sve to automatski dolazi u naš posao.

Otkrivanje usluga u distribuiranim sustavima na primjeru Consula. Aleksandar Sigačev

Ovo je jedan primjer. Load-balancer u obliku nginx-a se ponovno pokreće. Ovo je izborni uslužni program koji se isporučuje uz Consul. Ovo je predložak konzula. Opisujemo pravilo. Kažemo da koristimo predložak (Golang Template Engine). Kada se dogode događaji, kada se obavijesti da je došlo do promjena, to se ponovno generira i naredba "ponovno učitaj" šalje se na otkrivanje usluge. Najjednostavniji primjer je kada se nginx rekonfigurira događajem i ponovno pokrene.

Otkrivanje usluga u distribuiranim sustavima na primjeru Consula. Aleksandar Sigačev

Što je konzul?

  • Prije svega, ovo je otkrivanje usluge.

  • Ima mehanizam provjere dostupnosti - Health Checking.

  • Također ima KV Store.

  • I temelji se na mogućnosti korištenja Multi Datacenter.

Čemu sve to može poslužiti? U KV Storeu možemo pohraniti primjere konfiguracija. Zdravstveni pregled možemo provjeriti lokalnu službu i obavijestiti. Multi Datacenter se koristi kako bi se mogla izgraditi karta usluge. Primjerice, Amazon ima nekoliko zona i usmjerava promet na najoptimalniji način kako nema nepotrebnih zahtjeva između podatkovnih centara, koji se naplaćuju odvojeno od lokalnog prometa i, sukladno tome, imaju manju latenciju.

Otkrivanje usluga u distribuiranim sustavima na primjeru Consula. Aleksandar Sigačev

Hajdemo malo razumjeti pojmove koji se koriste u Konzulu.

  • Consul je usluga napisana u Go. Jedna od prednosti Go programa je 1 binarna datoteka koju samo preuzmete. Pokreće se s bilo kojeg mjesta i nemate nikakvih ovisnosti.
  • Zatim pomoću tipki možemo pokrenuti ovu uslugu bilo u načinu rada klijenta ili u načinu rada poslužitelja.
  • Također, atribut “datacenter” omogućuje vam da postavite oznaku kojem podatkovnom centru ovaj poslužitelj pripada.
  • Konsenzus – temeljen na protokolu splavi. Ako nekoga zanima, više o tome možete pročitati na stranicama Konzula. Ovo je protokol koji vam omogućuje da odredite vođu i odredite koji se novac smatra valjanim i dostupnim.
  • Gossip je protokol koji omogućuje interakciju između čvorova. Štoviše, ovaj sustav je decentraliziran. Unutar jednog podatkovnog centra svi čvorovi komuniciraju sa svojim susjedima. I, sukladno tome, informacije o trenutnom stanju prenose se jedni drugima. Možemo reći da je ovo međususjedsko ogovaranje.
  • LAN Gossip – lokalna razmjena podataka između susjeda unutar istog podatkovnog centra.
  • WAN Gossip - koristi se kada trebamo sinkronizirati informacije između dva podatkovna centra. Informacije teku između čvorova koji su označeni kao poslužitelji.
  • RPC – omogućuje vam izvršavanje zahtjeva putem klijenta na poslužitelju.

Opis RPC-a. Recimo da Consul radi kao klijent na virtualnom računalu ili fizičkom poslužitelju. Kontaktiramo ga lokalno. A onda lokalni klijent traži informacije od poslužitelja i sinkronizira se. Ovisno o postavkama, informacije se mogu dohvatiti iz lokalne predmemorije ili se mogu sinkronizirati s voditeljem, s glavnim poslužiteljem.

Ove dvije sheme imaju i prednosti i nedostatke. Ako radimo s lokalnom predmemorijom, onda je brza. Ako radimo s podacima koji su pohranjeni na poslužitelju, to traje duže, ali dobivamo relevantnije informacije.

Otkrivanje usluga u distribuiranim sustavima na primjeru Consula. Aleksandar Sigačev

Ako ovo prikažete grafički, onda je ovo slika stranice. Vidimo da trče tri majstora. Jedan je označen zvjezdicom kao vodeći. U ovom primjeru postoje tri klijenta koji lokalno međusobno razmjenjuju informacije putem UDP/TCP-a. A informacije između podatkovnih centara prenose se između poslužitelja. Ovdje klijenti komuniciraju jedni s drugima lokalno.

Otkrivanje usluga u distribuiranim sustavima na primjeru Consula. Aleksandar Sigačev

Koji API nudi Consul? Za dobivanje informacija Consul ima dvije vrste API-ja.

Ovo je DNS API. Prema zadanim postavkama, Consul radi na portu 8600. Možemo konfigurirati zahtjev za proxy i omogućiti pristup putem lokalne rezolucije, putem lokalnog DNS-a. Možemo postavljati upite prema domeni i kao odgovor primati informacije o IP adresi.

HTTP API - ili možemo lokalno zatražiti informacije o određenoj usluzi na portu 8500 i dobiti JSON odgovor, koji IP poslužitelj ima, koji host, koji je port registriran. I dodatne informacije mogu se prenijeti putem tokena.

Otkrivanje usluga u distribuiranim sustavima na primjeru Consula. Aleksandar Sigačev

Što vam je potrebno za pokretanje Consula?

U prvoj opciji, u načinu rada za razvojne programere označavamo oznaku da je ovo način rada za programere. Agent počinje kao poslužitelj. I obavlja cijelu funkciju neovisno na jednom stroju. Praktično, brzo i praktički bez dodatnih postavki za prvo pokretanje.

Drugi način je pokretanje u proizvodnji. Ovdje se pokretanje malo komplicira. Ako nemamo nijednu verziju konzula, onda moramo ubaciti prvi stroj u bootstrap, tj. ovaj stroj koji će preuzeti odgovornosti vođe. Podižemo ga, zatim podižemo drugu instancu poslužitelja, prosljeđujući mu informacije gdje se nalazi naš master. Podižemo treći. Nakon što imamo tri stroja u pogonu, ponovno ga pokrećemo u normalnom načinu rada na prvom stroju iz pokrenutog bootstrapa. Podaci su sinkronizirani i početni klaster je već pokrenut.

Preporuča se pokretanje tri do sedam instanci u poslužiteljskom načinu rada. To je zbog činjenice da ako broj poslužitelja raste, tada se povećava vrijeme za sinkronizaciju informacija između njih. Broj čvorova mora biti neparan kako bi se osigurao kvorum.

Otkrivanje usluga u distribuiranim sustavima na primjeru Consula. Aleksandar Sigačev

Kako se pružaju zdravstveni pregledi? Pravilo provjere pišemo u obliku Json u konfiguracijskom direktoriju Consul. Prva opcija je dostupnost domene google.com u ovom primjeru. A mi kažemo da je ovu provjeru potrebno provoditi u intervalima od 30 sekundi. Na taj način provjeravamo ima li naš čvor pristup vanjskoj mreži.

Druga opcija je da sami provjerite. Koristimo obični curl za pozivanje lokalnog hosta na navedenom portu u intervalima od 10 sekundi.

Ove se provjere sažimaju i šalju u Service Discovery. Ovisno o dostupnosti, ovi su čvorovi ili isključeni ili se pojavljuju na popisu dostupnih strojeva koji ispravno rade.

Otkrivanje usluga u distribuiranim sustavima na primjeru Consula. Aleksandar Sigačev

Consul također nudi UI sučelje, koje se pokreće s zasebnom zastavom i bit će dostupno na stroju. To vam omogućuje pregled informacija, a također možete napraviti neke promjene.

U ovom primjeru otvorena je kartica "Usluga". Prikazuje se da rade tri službe, jedna od njih je Konzul. Broj obavljenih provjera. A tu su i tri podatkovna centra u kojima se nalaze strojevi.

Otkrivanje usluga u distribuiranim sustavima na primjeru Consula. Aleksandar Sigačev

Ovo je primjer kartice Čvorovi. Vidimo da imaju složena imena koja uključuju podatkovne centre. Također pokazuje koje su usluge pokrenute, tj. vidimo da nema postavljenih oznaka. Ove dodatne oznake mogu pružiti neke informacije koje programer može koristiti za određivanje dodatnih parametara.

Također možete prenijeti informacije Consulu o statusu diskova i prosječnom opterećenju.

pitanja

Pitanje: Imamo docker kontejner, kako ga koristiti s Consulom?

Odgovor: Postoji nekoliko pristupa za docker spremnik. Jedan od najčešćih je korištenje docker spremnika treće strane odgovornog za registraciju. Prilikom pokretanja, docker socket mu se prosljeđuje. Svi događaji registracije i poništenja objave spremnika bilježe se u Consulu.

Pitanje: Dakle, Consul sam pokreće docker kontejner?

Odgovor: Ne. Pokrećemo docker kontejner. A prilikom konfiguriranja označavamo - slušajte tu i takvu utičnicu. To je otprilike isto kao što mi radimo s certifikatom, kada učitavamo podatke o tome gdje i što imamo.

Pitanje: Ispada da bi unutar Docker spremnika koji pokušavamo spojiti na Service Discovery trebala postojati neka vrsta logike koja može poslati podatke Consulu?

Odgovor: Ne baš. Kada se pokrene, propuštamo varijable kroz varijablu okruženja. Recimo naziv usluge, servisni port. Registar preslušava te podatke i unosi ih u Consul.

Pitanje: Imam još jedno pitanje o korisničkom sučelju. Postavili smo korisničko sučelje, na primjer, na produkcijski poslužitelj. Što je sa sigurnošću? Gdje su podaci pohranjeni? Je li moguće nekako akumulirati podatke?

Odgovor: U korisničkom sučelju postoje podaci iz baze podataka i iz Service Discovery. Sami postavljamo lozinke u postavkama.

Pitanje: Može li se ovo objaviti na internetu?

Odgovor: Prema zadanim postavkama, Consul se pokreće na lokalnom hostu. Za objavljivanje na Internetu morat ćete instalirati neku vrstu proxyja. Odgovorni smo za vlastita sigurnosna pravila.

Pitanje: Pruža li povijesne podatke izvan okvira? Zanimljivo je pogledati statistiku o zdravstvenim pregledima. Također možete dijagnosticirati probleme ako poslužitelj često kvari.

Odgovor: Nisam siguran da tamo postoje detalji o provjerama.

Pitanje: Trenutno stanje nije toliko važno koliko dinamika.

Odgovor: Za analizu – da.

Pitanje: Je li bolje ne koristiti Service Discovery za Consul docker?

Odgovor: Ne bih preporučio korištenje. Svrha izvješća je predstaviti što takav koncept postoji. Povijesno gledano, dospjela je, po mom mišljenju, do 1. verzije. Sada postoje cjelovitija rješenja, na primjer, Kubernetes, koji sve to ima ispod haube. Kao dio Kubernetes Service Discovery je inferioran u odnosu na Etcd. Ali nisam upoznat s tim kao s Consulom. Stoga sam odlučio napraviti Service Discovery koristeći Consul kao primjer.

Pitanje: Ne usporava li shema s vodećim poslužiteljem pokretanje aplikacije u cjelini? I kako će konzul odrediti novog vođu ako ovaj laže?

Odgovor: Imaju cijeli opisani protokol. Ako vas zanima, možete pročitati.

Pitanje: Consul za nas djeluje kao punopravni poslužitelj i svi zahtjevi lete preko njega?

Odgovor: Ne djeluje kao potpuni poslužitelj, već preuzima određenu zonu. Obično završava službom.konzula. I onda idemo dalje logično. U proizvodnji ne koristimo imena domena, već internu infrastrukturu, koja je obično skrivena iza predmemoriranja poslužitelja ako radimo pomoću DNS-a.

Pitanje: Odnosno, ako želimo pristupiti bazi podataka, onda ćemo u svakom slučaju prvo povući Consul da pronađe tu bazu podataka, zar ne?

Odgovor: Da. Ako radimo koristeći DNS, onda radi isto kao i bez Consula kada koristimo DNS imena. Obično moderne aplikacije ne povlače naziv domene u svakom zahtjevu, jer smo instalirali povezivanje, sve radi i u bliskoj budućnosti ga praktički nećemo koristiti. Ako je veza prekinuta, onda da, ponovno pitamo gdje nam je baza i idemo do nje.

chat proizvoda hashicorp — Hashicorp korisnički chat: Consul, Nomad, Terraform

PS Što se tiče zdravstvenih pregleda. Consul, poput Kubernetesa, koristi isti sustav za provjeru statusa preživljavanja usluge na temelju statusa koda.

200 OK for healthy
503 Service Unavailable for unhealthy

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

Izvor: www.habr.com

Kupite pouzdan hosting za stranice s DDoS zaštitom, VPS VDS poslužiteljima 🔥 Kupite pouzdan web hosting sa DDoS zaštitom, VPS VDS servere | ProHoster