Us suggereixo que us familiaritzeu amb la transcripció de l'informe d'Alexander Sigachev Service Discovery in distributed systems utilitzant Cònsol com a exemple.
Service Discovery es va crear perquè amb un cost mínim pugueu connectar una nova aplicació al nostre entorn existent. Amb Service Discovery, podem separar al màxim un contenidor en forma de docker o un servei virtual de l'entorn en què s'executa.
Dono la benvinguda a tothom! Sóc Alexander Sigachev, treballo a Inventos. I avui us presentaré un concepte com el descobriment de serveis. Considerarem el descobriment del servei fent servir Consul com a exemple.
Quins problemes soluciona Service Discovery? Service Discovery es va crear perquè amb un cost mínim pugueu connectar una nova aplicació al nostre entorn existent. Amb Service Discovery, podem separar al màxim un contenidor en forma de docker o un servei virtual de l'entorn en què s'executa.
Quin aspecte té? En un exemple clàssic a la web, es tracta d'una interfície que rep una sol·licitud d'usuari. A continuació, l'encamina al backend. En aquest exemple, aquest equilibrador de càrrega equilibra dos backends.
Aquí veiem que estem començant la tercera instància de l'aplicació. En conseqüència, quan s'inicia l'aplicació, es registra amb Service Discovery. Service Discovery notifica a l'equilibrador de càrrega. Load-balancer canvia la seva configuració automàticament i el nou backend ja està connectat al treball. Així, es poden afegir backends o, per contra, excloure del treball.
Què més és convenient fer amb Service Discovery? Service Discovery pot emmagatzemar configuracions de nginx, certificats i una llista de servidors backend actius.
Service Discovery també us permet detectar un error, detectar errors. Quins són els esquemes possibles quan es detecten falles?
- Aquesta aplicació que hem desenvolupat notifica al mateix Service Discovery que encara està operativa.
- Service Discovery, per la seva banda, sondeja la disponibilitat de l'aplicació.
- O bé, s'utilitza un script o una aplicació de tercers que comprova la disponibilitat de la nostra aplicació i notifica a Service Discovery que tot està bé i pot funcionar, o, per contra, que tot està malament i que aquesta instància de l'aplicació s'ha d'excloure de l'equilibri.
Cadascun dels esquemes es pot aplicar en funció del programari que utilitzem. Per exemple, acabem de començar a desenvolupar un projecte nou, i llavors podem proporcionar fàcilment un esquema per quan la nostra aplicació notifiqui Service Discovery. O podem connectar que Service Discovery està comprovant.
Si l'aplicació va ser heretada per nosaltres o desenvolupada per una altra persona, la tercera opció és adequada aquí, quan escrivim un controlador, i tot això entra a la nostra feina automàticament.
Aquest és un exemple. Es torna a carregar l'equilibrador de càrrega en forma de nginx. Aquesta és una utilitat opcional que ve amb Consul. Això és cònsol-plantilla. Descrivim la regla. Diem que fem servir una plantilla (motor de plantilla Golang). Quan es produeixen esdeveniments, quan s'han produït notificacions de canvis, es regenera i l'ordre "recarrega" s'envia a Service Discovery. L'exemple més senzill és quan nginx es reconfigura en un esdeveniment i es reinicia.
Què és el cònsol?
-
En primer lloc, és Service Discovery.
-
Disposa d'un mecanisme de comprovació de disponibilitat: comprovació de l'estat.
-
També té una botiga KV.
-
I es basa en la capacitat d'utilitzar Multi Datacenter.
Per a què pot servir tot això? A KV Store podem emmagatzemar exemples de configuració. Comprovació de salut podem comprovar el servei local i notificar. Multi Datacenter s'utilitza per poder construir un mapa de serveis. Per exemple, Amazon disposa de diverses zones i encamina el trànsit de la manera més òptima perquè no hi hagi sol·licituds innecessàries entre centres de dades, que es cobren a part del trànsit local i, en conseqüència, tinguin un retard menor.
Vegem una mica els termes que s'utilitzen a Cònsol.
- Cònsol és un servei escrit en Go. Un dels avantatges d'un programa Go és 1 fitxer binari que acabeu de descarregar. Llançat des de qualsevol lloc i no tens cap dependència.
- A més, utilitzant les claus, podem iniciar aquest servei ja sigui en mode client o en mode servidor.
- A més, l'atribut "datacenter" us permet establir una marca a quin centre de dades pertany aquest servidor.
- Consens - basat en el protocol de la bassa. Si algú està interessat, pot llegir-ne més informació al web del Cònsol. Aquest és un protocol que permet determinar el líder i determinar quines dades es consideren vàlides i disponibles.
- La xafarderia és un protocol que permet la comunicació entre nodes. A més, aquest sistema està descentralitzat. Dins d'un centre de dades, tots els nodes es comuniquen amb els seus veïns. I, en conseqüència, la informació sobre l'estat actual es transmet entre ells. Podem dir que això són xafarderies entre veïns.
- LAN Gossip: intercanvi de dades locals entre veïns dins del mateix centre de dades.
- WAN Gossip: s'utilitza quan necessitem sincronitzar informació entre dos centres de dades. La informació passa entre nodes que estan marcats com a servidor.
- RPC: permet fer peticions a través del client al servidor.
Descripció de RPC. Suposem que Consul s'està executant com a client en una màquina virtual o servidor físic. Ho tractem localment. A continuació, el client local demana informació al servidor i se sincronitza. La informació, segons la configuració, es pot emetre des de la memòria cau local, o es pot sincronitzar amb el líder, amb el servidor mestre.
Aquests dos esquemes tenen avantatges i inconvenients. Si estem treballant amb una memòria cau local, això és ràpid. Si treballem amb dades que s'emmagatzemen al servidor, triguen més temps, però obtenim informació més actualitzada.
Si això es representa gràficament, aquí teniu una imatge del lloc. Veiem que tenim tres mestres en marxa. Un està marcat amb un asterisc com a líder. En aquest exemple, hi ha tres clients que es comuniquen entre ells localment mitjançant UDP/TCP. I la informació entre centres de dades es transfereix entre servidors. Aquí, els clients interactuen entre ells localment.
Quina API proporciona Consul? Per obtenir informació, Consul disposa de dos tipus d'API.
Aquesta és l'API DNS. Per defecte, Consul s'executa al port 8600. Podem configurar el proxy de sol·licituds i proporcionar accés mitjançant resolució local, mitjançant DNS local. Podem consultar per domini i obtenir en resposta informació sobre l'adreça IP.
API HTTP: o podem sol·licitar informació sobre un servei específic localment al port 8500 i obtenir una resposta JSON, quina IP té el servidor, quin host, quin port està registrat. I la informació addicional es pot passar mitjançant un testimoni.
Què necessites per dirigir Cònsol?
En la primera opció, especifiquem la marca en el mode de desenvolupador que aquest és el mode de desenvolupador. L'agent comença com a servidor. I realitza tota la funció per si mateix en una màquina. Pràctic, ràpid i pràcticament no calen configuracions addicionals per al primer inici.
El segon mode s'està executant en producció. Aquí és on el llançament es fa una mica complicat. Si no tenim cap versió del cònsol, hem de posar la primera màquina en bootstrap, és a dir, aquesta màquina, que es farà càrrec de les funcions del líder. L'aixequem, després aixequem la segona instància del servidor, passant-li informació on tenim el mestre. Aixeca el tercer. Després de tenir tres màquines en funcionament, estem a la primera màquina que executa bootstrap i la reiniciem en mode normal. Les dades estan sincronitzades i el clúster inicial ja està activat.
Es recomana executar de tres a set instàncies en mode servidor. Això es deu al fet que si el nombre de servidors creix, augmenta el temps per sincronitzar la informació entre ells. El nombre de nodes ha de ser senar per proporcionar un quòrum.
Com es proporcionen els controls de salut? Al directori de configuració del Cònsol, escrivim una regla de validació en forma de Json. La primera opció és la disponibilitat en aquest exemple del domini google.com. I diem que després d'un interval de 30 segons, cal realitzar aquesta comprovació. Així, comprovem que el nostre node té accés a la xarxa externa.
La segona opció és posar-se a prova. Utilitzem el curl habitual per treure localhost al port especificat amb un interval de 10 segons.
Aquestes comprovacions es resumeixen i s'introdueixen a Service Discovery. En funció de la disponibilitat, aquests nodes s'exclouen o apareixen a la llista de màquines disponibles i que funcionen correctament.
Consul també ofereix una interfície d'interfície d'usuari que s'inicia amb una bandera independent i estarà disponible a la màquina. Això us permet veure informació i també podeu fer alguns canvis.
En aquest exemple, la pestanya Eines està oberta. Es mostren tres serveis en funcionament, un d'ells és Cònsol. El nombre de controls realitzats. I hi ha tres centres de dades on es troben les màquines.
Aquest és un exemple de la pestanya "Nodes". Veiem que tenen noms compostos amb la participació de centres de dades. També mostra quins serveis s'estan executant, és a dir, veiem que no hi ha etiquetes establertes. En aquestes etiquetes addicionals, podeu establir informació que el desenvolupador pot utilitzar per especificar paràmetres addicionals.
També podeu enviar informació a Consul sobre l'estat dels discs, sobre la càrrega mitjana.
Les vostres preguntes
Pregunta: Tenim un contenidor docker, com utilitzar-lo amb Consul?
Resposta: Hi ha diversos enfocaments per a un contenidor docker. Un dels més habituals és utilitzar un contenidor docker de tercers responsable del registre. A l'inici, s'hi llança un socket docker. Tots els esdeveniments per registrar i anul·lar la publicació d'un contenidor estan registrats a Consul.
P: Llavors, el mateix Consul executa el contenidor Docker?
Resposta: No. Estem executant un contenidor docker. I quan configurem, especifiquem: escolteu tal o tal sòcol. Això és més o menys el mateix que treballar amb un certificat quan passem informació sobre on i què tenim.
Pregunta: Resulta que dins del contenidor docker que estem intentant connectar a Service Discovery hi ha d'haver algun tipus de lògica que pugui donar dades al Consul?
Resposta: No exactament. Quan comença, passem variables per l'entorn de variables. Diguem nom del servei, port del servei. Escolta aquesta informació al registre i l'introdueix a Cònsol.
Pregunta: tinc una altra pregunta sobre la IU. Hem desplegat la interfície d'usuari, per exemple, en un servidor de producció. Què passa amb la seguretat? On s'emmagatzemen les dades? Hi ha alguna manera d'acumular dades?
Resposta: a la interfície d'usuari, només dades de la base de dades i de Service Discovery. Les contrasenyes les configurem nosaltres mateixos a la configuració.
Pregunta: Això es pot publicar a Internet?
Resposta: Consul comença a localhost de manera predeterminada. Per publicar a Internet, haureu de posar algun tipus de proxy. Nosaltres mateixos som responsables de les normes de seguretat.
Pregunta: Ofereix dades històriques fora de la caixa? És interessant veure les estadístiques dels controls de salut. També podeu diagnosticar problemes si el servidor es bloqueja amb freqüència.
Resposta: No estic segur que hi hagi detalls dels controls.
Pregunta: L'estat actual no és tant important com la dinàmica.
Resposta: Per a l'anàlisi, sí.
Pregunta: és millor no utilitzar Service Discovery for Consul Docker?
Resposta: No recomanaria utilitzar-lo. L'objectiu de l'informe és presentar què és aquest concepte. Històricament, al meu entendre, ha recorregut un llarg camí fins a la 1a versió. Ara ja hi ha solucions més completes, per exemple, Kubernetes, que té tot això sota el capó. Com a part de Kubernetes Service Discovery és inferior a Etcd. Però no el conec tant com el cònsol. Per tant, vaig decidir fer la descoberta de serveis utilitzant Consul com a exemple.
Pregunta: L'esquema amb el líder del servidor retarda l'inici de l'aplicació en conjunt? I com determina el cònsol un nou líder si aquest menteix?
Resposta: Han descrit tot un protocol. Si esteu interessats, podeu llegir.
Pregunta: Cònsol actua com a servidor complet i totes les sol·licituds passen per ell?
Resposta: no actua com a servidor complet, sinó que ocupa una zona determinada. Normalment acaba amb servei.consul. I després anem lògicament. No fem servir noms de domini en producció, és a dir, la infraestructura interna, que normalment s'amaga darrere de la memòria cau del servidor si treballem mitjançant DNS.
Pregunta: És a dir, si volem accedir a la base de dades, aleshores en qualsevol cas tirarem a Cònsol per trobar aquesta base de dades primer, oi?
Resposta: Sí. Si treballem amb DNS, funciona com sense Consul quan fem servir noms DNS. Normalment, les aplicacions modernes no treuen el nom de domini en totes les sol·licituds, perquè hem instal·lat connect, tot funciona i en un futur proper pràcticament no l'utilitzem. Si la connexió es trenca, sí, tornem a preguntar on és la nostra base i anem a ella.
— Xat dels usuaris de Hashicorp: Consul, Nomad, Terraform
PS Pel que fa als controls de salut. Consul, com Kubernetes, utilitza el mateix sistema per comprovar l'estat de salut d'un servei en funció de l'estat del codi.
200 OK for healthy
503 Service Unavailable for unhealthyFonts:
Font: www.habr.com