Vă invit să luați cunoștință de transcrierea raportului lui Alexander Sigachev despre Service Discovery în sistemele distribuite, folosind ca exemplu Consul.
Service Discovery este creat pentru a permite conectarea unui nou aplicație în deja existentul nostru mediu cu costuri minime. Folosind Service Discovery, putem separa maximum fie un container sub formă de Docker, fie un serviciu virtual de mediu în care este lansat.
Salut tuturor! Sunt Alexander Sigachev și lucrez la compania Inventos. Astăzi vă voi familiariza cu conceptul de Service Discovery, pe care îl vom analiza prin intermediul exemplului Consul.
Ce probleme rezolvă Service Discovery? Service Discovery este creat pentru a permite conectarea unui nou aplicație în deja existentul nostru mediu cu costuri minime. Folosind Service Discovery, putem separa maximum fie un container sub formă de Docker, fie un serviciu virtual de mediu în care este lansat.
Cum arată acest lucru? Într-un exemplu clasic pe web - este frontend-ul care primește solicitările utilizatorului. Apoi, acesta efectuează rutarea către backend. În acest exemplu, un load-balancer echilibrează între două backend-uri.
Aici vedem că lansăm a treia instanță a aplicației. Astfel, când aplicația este lansată, aceasta se înregistrează în Service Discovery. Service Discovery notifică load-balancer-ul. Load-balancer-ul își schimbă automat configurația, iar noul backend începe să funcționeze. Astfel, backend-uri pot fi adăugate sau, dimpotrivă, excluse din funcționare.
Ce altceva este convenabil să facem cu ajutorul Service Discovery? În Service Discovery pot fi stocate configurațiile Nginx, certificatele și lista serverelor backend active.
De asemenea, Service Discovery permite detectarea unui eșec, identificarea defecțiunilor. Ce scheme pot exista pentru a detecta eșecurile?
- Aceasta este aplicația pe care am dezvoltat-o, care notifică singură Service Discovery că este încă funcțională.
- Service Discovery, la rândul său, interoghează aplicația pentru a verifica disponibilitatea acesteia.
- Sau se folosește un script sau o aplicație externă care verifică disponibilitatea aplicației noastre și notifică Service Discovery că totul este bine și poate funcționa sau, dimpotrivă, că ceva nu este în regulă și este necesară excluderea acestei instanțe a aplicației din balansare.
Fiecare schemă poate fi aplicată în funcție de software-ul pe care îl folosim. De exemplu, dacă am început să dezvoltăm un nou proiect, putem să asigurăm fără probleme o schemă în care aplicația noastră notifică Service Discovery. Sau putem conecta Service Discovery pentru a efectua verificarea.
Dacă aplicația ne-a fost lăsată în urma altcuiva sau a fost dezvoltată de o terță parte, atunci se potrivește a treia variantă, când scriem un handler, iar totul se integrează automat în munca noastră.
Aceasta este unul dintre exemple. Load-balancerul sub formă de nginx se reîncarcă. Este o utilitate suplimentară care vine împreună cu Consul. Acesta este consul-template. Descriem o regulă. Spunem că folosim un șablon (Șablonizator Golang). La efectuarea evenimentelor, la notificările că s-au produs modificări, acesta se regăsește și Service Discovery primește comanda „reload”. Un exemplu simplu, când nginx se reconfigurează și se repornește la un eveniment.
Ce este Consul?
În primul rând, este un Service Discovery.
Are un mecanism de verificare a disponibilității – Health Checking.
De asemenea, are un KV Store.
Și în baza sa este posibilă utilizarea Multi Datacenter.
La ce poate fi folosit tot acest lucru? În KV Store putem stoca exemple de configurări. Prin Health Checking putem verifica serviciul local și trimite notificări. Multi Datacenter este folosit pentru a construi o hartă a serviciilor. De exemplu, Amazon are mai multe zone și își rootează traficul cel mai optim, pentru a evita cererile suplimentare între data center-e, care sunt tarifate separat de traficul local și, prin urmare, au o latență mai mică.
Să ne familiarizăm puțin cu termenii folosiți în Consul.
- Consul este un serviciu scris în Go. Unul dintre avantajele programării în Go este faptul că avem un singur fișier binar pe care îl descarci. Îl rulezi din orice locație și nu ai dependențe.
- Apoi, folosind cheile, putem porni acest serviciu fie în modul client, fie în modul server.
- De asemenea, atributul „datacenter” permite semnalarea la ce data center aparține acest server.
- Consensus se bazează pe protocolul raft. Dacă cineva este interesat, poate citi mai multe despre acesta pe site-ul Consul. Este un protocol care permite definirea unui lider și determinarea datelor care să fie considerate valide și disponibile.
- Gossip este un protocol care facilitează interacțiunea între noduri. Acest sistem este descentralizat. În cadrul unui singur centru de date, toate nodurile comunică cu vecinii lor, iar informațiile despre starea actuală sunt transmise reciproc. Putem spune că este vorba de gossip-uri între vecini.
- LAN Gossip – schimb local de date între vecini în cadrul unui singur centru de date.
- WAN Gossip – este utilizat atunci când trebuie să sincronizăm informațiile între două centre de date. Informația circulă între noduri marcate ca servere.
- RPC – permite efectuarea de cereri prin client la server.
Descrierea RPC. Să presupunem că pe o mașină virtuală sau pe un server fizic rulează Consul ca un client. Ne adresăm acestuia local. Apoi, clientul local solicită informații de la server și se sincronizează. Informația, în funcție de configurații, poate fi oferită din cache-ul local sau poate fi sincronizată cu liderul, cu masterul serverului.
Aceste două scheme au atât avantaje, cât și dezavantaje. Dacă lucrăm cu cache-ul local, atunci este rapid. Dacă lucrăm cu date stocate pe server, atunci durează mai mult, dar obținem informații mai actuale.
Dacă am ilustra grafic, ar arăta astfel pe site. Vedem că avem trei mastere pornite. Unul este marcat cu stea ca lider. În acest exemplu, trei clienți schimbă între ei informații local prin UDP/TCP. Informația între centrele de date este transmisă între servere. Aici, clienții interacționează local între ei.
Ce API oferă Consul? Pentru a obține informații, Consul are două tipuri de API-uri.
Acesta este DNS API. În mod implicit, Consul rulează pe portul 8600. Putem configura proxying pentru cerere și asigura accesul prin rezolvarea locală, prin DNS local. Putem solicita pe domeniu și vom primi ca răspuns informații despre adresa IP.
HTTP API – sau putem solicita local pe portul 8500 informații despre un anumit serviciu și vom primi un răspuns JSON, ce IP are serverul, ce host, ce port este înregistrat. Informații suplimentare pot fi transmise prin token.
Ce este necesar pentru a porni Consul?
În prima variantă, în modul dezvoltator, specificăm un steag care indică faptul că acesta este modul dezvoltator. Agentul pornește ca server. Și întreaga funcție este deja îndeplinită de el însuși pe o singură mașină. Convenabil, rapid și fără practic nicio configurație suplimentară necesară pentru prima pornire.
A doua variantă este pornirea în production. Aici, pornirea este puțin mai complicată. Dacă nu avem nicio versiune a consolei, trebuie să aducem în bootstrap prima mașină, adică această mașină care va prelua responsabilitățile liderului. O ridicăm, apoi ridicăm al doilea exemplar al serverului, transmițându-i informații despre unde se află masterul. Ridicăm al treilea. După ce avem trei mașini active, pe prima mașină din bootstrap-ul pornit, o repornim în modul obișnuit. Datele sunt sincronizate și clusterul inițial este deja ridicat.
Se recomandă să ruleze între trei și șapte exemplare în modul server. Acest lucru se datorează faptului că, pe măsură ce numărul serverelor crește, timpul de sincronizare a informațiilor între ele se mărește. Numărul de noduri trebuie să fie impar pentru a asigura quorum.
Cum se asigură Health Checks? În directorul pentru configurația Consul, scriem în format Json regula de verificare. Prima variantă este disponibilitatea în acest exemplu a domeniului google.com. Și spunem că, la un interval de 30 de secunde, trebuie să efectueze această verificare. Astfel ne asigurăm că nodul nostru are acces la rețeaua externă.
A doua variantă este auto-verificarea. Facem o solicitare curl către localhost pe portul specificat la un interval de 10 secunde.
Aceste verificări se sumază și sunt transmise în Service Discovery. Pe baza disponibilității, aceste noduri sunt fie excluse, fie apar în lista mașinilor disponibile și care funcționează corect.
De asemenea, Consul oferă o interfață UI, care pornește cu un steag separat și va fi disponibilă pe mașină. Aceasta permite vizualizarea informațiilor, iar unele modificări pot fi de asemenea efectuate.
În acest exemplu, este deschis tab-ul „Serviciu”. Se arată că sunt active trei servicii, unul dintre ele fiind Consul. Numărul de verificări efectuate. Și există trei centre de date în care se află mașinile.
Acesta este un exemplu de tab nouă „Nodes”. Se observă că au denumiri compuse care implică centre de date. Aici sunt prezentate și serviciile active, adică observăm că etichetele nu sunt setate. În aceste etichete suplimentare, poate fi specificată o anumită informație pe care dezvoltatorul o poate utiliza pentru a indica parametrii suplimentari.
De asemenea, se poate transmite informații în Consul despre starea discurilor și despre încărcarea medie.
Întrebări
Întrebare: Avem un container Docker, cum îl putem folosi cu Consul?
Răspuns: Pentru containerul Docker există mai multe abordări. Una dintre cele mai comune este utilizarea unui container Docker de terță parte responsabil pentru înregistrare. La lansare, acesta primește un socket Docker. Toate evenimentele de înregistrare și de publicare a containerului sunt salvate în Consul.
Întrebare: Așadar, Consul pornește singur containerul Docker?
Răspuns: Nu. Noi pornim containerul Docker. Și la configurare specificăm – ascultă acel socket. Este aproximativ la fel ca atunci când lucrăm cu un certificat, când transmitem informații despre unde și ce avem.
Întrebare: Deci, în interiorul containerului Docker, pe care încercăm să-l conectăm la Service Discovery, ar trebui să existe o logică care poate să returneze date către Consul?
Răspuns: Nu neapărat. Atunci când pornește, transmitem variabilele prin mediul înconjurător. De exemplu, numele serviciului, portul serviciului. Registry-ul ascultă aceste informații și le înregistrează în Consul.
Întrebare: Am o întrebare despre UI. Am desfășurat UI, să zicem, pe serverul de producție. Ce se întâmplă cu securitatea? Unde sunt stocate datele? Există vreo modalitate de a acumula date?
Răspuns: În UI, datele provin din baza de date și din Service Discovery. Parolele le setăm noi în configurații.
Întrebare: Este permis să fie publicat pe internet?
Răspuns: În mod implicit, Consul pornește pe localhost. Pentru a publica pe internet, va trebui să configurăm un proxy. Noi ne asumăm responsabilitatea pentru regulile de securitate.
Întrebare: Oferă date istorice din cutie? M-ar interesa să văd statistici despre Health Checks. Se pot diagnostica problemele, dacă serverul se oprește frecvent.
Răspuns: Nu sunt sigur că există detalii despre verificări acolo.
Întrebare: Nu este atât de important starea actuală, cât dinamica.
Răspuns: Pentru analiză – da.
Întrebare: Este mai bine să nu utilizăm Service Discovery pentru docker în Consul?
Răspuns: Nu aș recomanda să-l folosești. Scopul raportului este de a te familiariza cu acest concept. Istoric, el a parcurs un drum până la versiunea 1. Acum există soluții mai complete, cum ar fi Kubernetes, care include toate acestea în fundal. În cadrul Kubernetes, descoperirea serviciilor este inferioară Etcd. Dar nu mă cunosc la fel de bine cu acesta ca și cu Consul. De aceea am decis să fac descoperirea serviciilor pe exemplul Consul.
Întrebare: Schema cu serverul lider nu încetinește pornirea aplicației în ansamblu? Și cum determină Consul un nou lider dacă acesta este căzut?
Răspuns: Ei au un protocol întreaga descris. Dacă ești interesat, poți citi.
Întrebare: Consul acționează ca un server complet și toate cererile trec prin el?
Răspuns: El nu acționează ca un server complet, ci preia o zonă specifică. Aceasta, de obicei, se termină cu service.consul. Apoi ne ghidăm după logica specifică. Nu utilizăm nume de domeniu în producție, ci o infrastructură internă, care de obicei este ascunsă în spatele serverului de caching, atunci când lucrăm prin DNS.
Întrebare: Adică, dacă dorim să ne conectăm la baza de date, trebuie să consultăm Consul pentru a găsi mai întâi această bază, corect?
Răspuns: Da. Dacă lucrăm prin DNS, atunci asta funcționează la fel ca fără Consul, atunci când folosim nume DNS. De obicei, aplicațiile moderne nu interoghează numele de domeniu la fiecare cerere, pentru că am stabilit o conexiune și totul funcționează, iar în perioada apropiată NU utilizăm practic. Dacă conexiunea s-a rupt, atunci - da, întrebăm din nou unde se află baza noastră și mergem către ea.
— Chatul utilizatorilor Hashicorp: Consul, Nomad, Terraform
P.S. În ceea ce privește verificările de sănătate. În Consul, la fel ca și în Kubernetes, se folosește un sistem similar de verificare a sănătății serviciului bazat pe codul de stare.
200 OK pentru sănătos
503 Serviciu indisponibil pentru nesănătosSurse:
Sursa: habr.com
