Ik stel voor om de uiteenzetting van Alexander Sigachev over Service Discovery in gedistribueerde systemen aan de hand van Consul te bekijken.
Service Discovery is ontworpen om nieuwe applicaties met minimale kosten aan te sluiten op onze bestaande omgeving. Met Service Discovery kunnen we een container, zoals een Docker-container, of een virtuele service maximaal isoleren van de omgeving waarin deze draait.
Hallo iedereen! Ik ben Alexander Sigachev, werk bij Inventos. Vandaag ga ik jullie kennis laten maken met het concept Service Discovery. We gaan Service Discovery bekijken aan de hand van Consul.
Welke problemen lost Service Discovery op? Service Discovery is ontworpen om nieuwe applicaties met minimale kosten aan te sluiten op onze bestaande omgeving. Met Service Discovery kunnen we een container, zoals een Docker-container, of een virtuele service maximaal isoleren van de omgeving waarin deze draait.
Hoe ziet dat eruit? In een klassiek voorbeeld op het web ā het is de frontend die het verzoek van de gebruiker ontvangt. Vervolgens voert het de routering naar de backend uit. In dit voorbeeld balanceert de load-balancer tussen twee backends.
Hier zien we dat we een derde exemplaar van de applicatie starten. Wanneer de applicatie wordt gestart, registreert deze zich bij Service Discovery. Service Discovery meldt dit aan de load-balancer. De load-balancer past zijn configuratie automatisch aan en de nieuwe backend wordt in gebruik genomen. Op deze manier kunnen backend-servers worden toegevoegd of juist worden uitgesloten van gebruik.
Wat is er nog meer handig te doen met Service Discovery? In Service Discovery kunnen configuraties van nginx, certificaten en een lijst van actieve backend-servers worden opgeslagen.
Bovendien maakt Service Discovery het mogelijk om storingen te detecteren. Wat zijn de mogelijke schema's voor het detecteren van storingen?
- Deze applicatie die we hebben ontwikkeld, meldt zelf aan Service Discovery dat hij nog steeds operationeel is.
- Service Discovery vraagt aan zijn kant de applicatie om de beschikbaarheid te controleren.
- Of er wordt een extern script of applicatie gebruikt die onze applicatie op beschikbaarheid controleert en Service Discovery informeert dat alles goed is en ermee kan worden gewerkt of, in tegendeel, dat er problemen zijn en dat dit exemplaar van de applicatie moet worden uitgesloten van de load balancing.
Elke schematische opzet kan worden toegepast, afhankelijk van de software die we gebruiken. Bijvoorbeeld, als we net zijn begonnen met het ontwikkelen van een nieuw project, kunnen we gemakkelijk een schema bieden waarin onze applicatie Service Discovery op de hoogte brengt. Of we kunnen aansluiten dat Service Discovery controles uitvoert.
Als de applicatie ons is nagelaten of is ontwikkeld door een externe partij, dan is er een derde optie geschikt, waarbij we een handler schrijven en al dit automatisch in ons werk komt.
Dit is een van de voorbeelden. De load-balancer in de vorm van Nginx wordt opnieuw opgestart. Dit is een aanvullende tool die samen met Consul wordt geleverd. Dit is consul-template. We beschrijven een regel. We geven aan dat we een sjabloon gebruiken (Golang-sjablonizer). Bij gebeurtenismeldingen van wijzigingen wordt het opnieuw gegenereerd en Service Discovery ontvangt een 'reload'-opdracht. Een eenvoudig voorbeeld wanneer Nginx opnieuw wordt geconfigureerd en opnieuw wordt opgestart op een gebeurtenis.
Wat is Consul?
In de eerste plaats is het Service Discovery.
Het heeft een beschikbaarheidscontrolemechanisme - Health Checking.
Het heeft ook een KV Store.
En het biedt de mogelijkheid om Multi Datacenter te gebruiken.
Waarvoor kan dit allemaal worden gebruikt? In de KV Store kunnen we configuratievoorbeelden opslaan. Met Health Checking kunnen we de lokale service controleren en meldingen verzenden. Multi Datacenter wordt gebruikt om een kaart van de services te maken. Bijvoorbeeld, Amazon heeft meerdere zones en routeert het verkeer optimaal, zodat er geen onnodige verzoeken zijn tussen datacenters die afzonderlijk worden gefactureerd van lokaal verkeer en bijgevolg een lagere latentie hebben.
Laten we eens kijken naar de termen die in Consul worden gebruikt.
- Consul is een service geschreven in Go. Een van de voordelen van een Go-programma is dat het uit Ć©Ć©n binaire bestand bestaat, dat je gewoon kunt downloaden. Voer het uit vanaf elke locatie en je hebt geen afhankelijkheden.
- Vervolgens kunnen we met behulp van sleutels deze service ofwel in clientmodus ofwel in servermodus starten.
- Ook kan de 'datacenter'-attribuut een vlag instellen voor welk datacenter deze server toebehoort.
- Consensus is gebaseerd op het raft-protocol. Voor degenen die geĆÆnteresseerd zijn, kan hierover meer worden gelezen op de Consul-website. Dit is een protocol dat het mogelijk maakt om een leider te bepalen en te bepalen welke gegevens als geldig en toegankelijk moeten worden beschouwd.
- Gossip is een protocol dat interactie tussen knooppunten mogelijk maakt. Dit systeem is bovendien gedecentraliseerd. Binnen Ć©Ć©n datacenter communiceren alle knooppunten met hun buren. En zo wordt informatie over de actuele status uitgewisseld. Je zou kunnen zeggen dat dit geruchten zijn tussen buren.
- LAN Gossip is de lokale gegevensuitwisseling tussen buren binnen Ć©Ć©n datacenter.
- WAN Gossip wordt gebruikt wanneer we informatie tussen twee datacenters moeten synchroniseren. De informatie gaat tussen knooppunten die zijn gemarkeerd als server.
- RPC maakt het mogelijk om verzoeken via de client naar de server uit te voeren.
Beschrijving van RPC. Stel dat Consul als client draait op een virtuele of fysieke server. We benaderen het lokaal. Vervolgens vraagt de lokale client informatie aan de server en synchroniseert deze. Afhankelijk van de instellingen kan de informatie afkomstig zijn uit de lokale cache, of kan deze gesynchroniseerd worden met de leider, de master server.
Deze twee schema's hebben zowel pluspunten als minpunten. Als we met de lokale cache werken, is dit snel. Als we werken met gegevens die op de server zijn opgeslagen, duurt dit langer, maar krijgen we meer actuele informatie.
Als we dit grafisch weergeven, zien we een afbeelding van de site. We zien dat we drie masters hebben draaien. EĆ©n is met een ster gemarkeerd als leider. In dit voorbeeld zijn er drie clients die lokaal informatie uitwisselen via UDP/TCP. En de informatie tussen de datacenters wordt overgedragen tussen servers. Hier interageren de clients lokaal met elkaar.
Welke API biedt Consul? Om informatie te verkrijgen, zijn er twee soorten API's van Consul.
Dit is de DNS API. Standaard draait Consul op poort 8600. We kunnen proxyverzoeken instellen en toegang krijgen via lokale resolutie, via lokale DNS. We kunnen een aanvraag doen op basis van een domein en krijgen als antwoord informatie over het IP-adres.
HTTP API - of we kunnen lokaal op poort 8500 informatie opvragen over een specifieke service en we krijgen een JSON-antwoord met welk IP de server heeft, welke host, welke poort is geregistreerd. En extra informatie kan worden doorgegeven via een token.
Wat is er nodig om Consul te starten?
In de eerste optie geven we in de ontwikkelaarsmodus een vlag op dat dit de ontwikkelaarsmodus is. Agent start als server. En voert de hele functie al zelfstandig uit op Ć©Ć©n machine. Handig, snel en er zijn praktisch geen extra instellingen vereist voor de eerste start.
De tweede modus is de productie-start. Hier wordt de start iets gecompliceerder. Als we geen enkele versie van de consul hebben, moeten we de eerste machine in bootstrap brengen, dat wil zeggen deze machine die de verantwoordelijkheden van de leider op zich neemt. We starten deze, daarna starten we een tweede serverexemplaar en geven het informatie over waar onze master zich bevindt. We starten de derde. Zodra we drie machines hebben opgestart, herstarten we de eerste machine van de opgestarte bootstrap in de normale modus. De gegevens worden gesynchroniseerd en het initiƫle cluster is al opgestart.
Het wordt aanbevolen om tussen de drie en zeven exemplaren in servermodus te draaien. Dit komt doordat als het aantal servers toeneemt, de tijd voor het synchroniseren van informatie tussen hen ook toeneemt. Het aantal knooppunten moet oneven zijn om quorum te waarborgen.
Hoe worden Health Checks gegarandeerd? In de configuratiemap voor Consul schrijven we een controleregel in Json. De eerste optie is de beschikbaarheid van het domein google.com in dit voorbeeld. We geven aan dat deze controle elke 30 seconden moet worden uitgevoerd. Op deze manier controleren we of onze node toegang heeft tot het externe netwerk.
De tweede optie is een zelfcontrole. We gebruiken gewone curl om localhost aan te roepen op de aangegeven poort met een interval van 10 seconden.
Deze controles worden opgeteld en komen in Service Discovery. Op basis van de beschikbaarheid worden deze nodes ofwel uitgesloten, of ze verschijnen op de lijst van beschikbare en correct functionerende machines.
Consul biedt ook een UI-interface die met een aparte vlag wordt gestart en beschikbaar zal zijn op de machine. Dit stelt ons in staat om informatie te bekijken en ook enkele wijzigingen aan te brengen.
In dit voorbeeld is het tabblad 'Service' geopend. Het toont dat er drie services zijn gestart, waarvan er Ć©Ć©n Consul is. Het aantal uitgevoerde controles. En er zijn drie datacentra waar de machines zich bevinden.
Dit is een voorbeeld van het tabblad 'Nodes'. We zien dat ze samengestelde namen hebben met betrekking tot datacenters. Hier wordt ook getoond welke services actief zijn, dat wil zeggen, we zien dat de tags niet zijn ingesteld. In deze aanvullende tags kan informatie worden vastgelegd die een ontwikkelaar kan gebruiken om extra parameters aan te geven.
Er kan ook informatie naar Consul worden verzonden over de status van de schijven, over de gemiddelde belasting.
Vragen
Vraag: We hebben een Docker-container, hoe gebruiken we deze met Consul?
Antwoord: Voor de Docker-container zijn er verschillende benaderingen. Een van de meest gebruikelijke is het gebruik van een externe Docker-container die verantwoordelijk is voor registratie. Bij het opstarten wordt de Docker-socket doorgegeven. Alle registraties en publicaties van de container worden in Consul vastgelegd.
Vraag: Dat wil zeggen, start Consul de Docker-container zelf?
Antwoord: Nee. Wij starten de Docker-container. En bij de configuratie geven we aan - luister naar deze socket. Dit is ongeveer hetzelfde als wanneer we met een certificaat werken, waarbij we informatie doorgeven over waar en wat we hebben.
Vraag: Het lijkt erop dat er binnen de Docker-container die we proberen te verbinden met Service Discovery enige logica moet zijn die gegevens naar Consul kan sturen?
Antwoord: Niet helemaal. Wanneer hij opstart, geven we via omgevingsvariabelen waarden door. Bijvoorbeeld, service naam, service poort. De register luistert naar deze informatie en legt deze vast in Consul.
Vraag: Ik heb nog een vraag over de UI. We hebben de UI uitgerold, bijvoorbeeld op de productie-server. Hoe zit het met de veiligheid? Waar worden de gegevens opgeslagen? Is het mogelijk om gegevens te accumuleren?
Antwoord: In de UI worden de gegevens uit de database en uit Service Discovery gehaald. Wachtwoorden stellen we zelf in de instellingen in.
Vraag: Is het mogelijk om dit op internet te publiceren?
Antwoord: Standaard start Consul op localhost. Om dit op internet te publiceren, moet er een proxy worden ingesteld. Wij zijn zelf verantwoordelijk voor de veiligheidsregels.
Vraag: Levert het historische gegevens uit de doos? Ik ben benieuwd naar de statistieken van de Health Checks. We kunnen immers problemen diagnosticeren als de server vaak uitvalt.
Antwoord: Ik ben niet zeker of daar details van de controles zijn.
Vraag: Het gaat niet zozeer om de huidige status, maar om de dynamiek.
Antwoord: Voor analyse ā ja.
Vraag: Is het beter om Service Discovery voor Docker Consul niet te gebruiken?
Antwoord: Ik zou het niet aanbevelen om het te gebruiken. Het doel van het rapport is om kennis te maken met het begrip. Historisch gezien heeft het volgens mij een reis doorgemaakt tot de eerste versie. Nu zijn er al vollediger oplossingen, zoals Kubernetes, die dit allemaal onder de motorkap hebben. In Kubernetes is de Service Discovery minderwaardig aan Etcd. Maar ik ben er niet zo vertrouwd mee als met Consul. Daarom heb ik de Service Discovery op het voorbeeld van Consul gedaan.
Vraag: Vertraagt het schema met de leidende server de start van de applicatie in het algemeen? En hoe bepaalt Consul een nieuwe leider als deze offline is?
Antwoord: Ze hebben een compleet protocol beschreven. Als je het interessant vindt, kun je het lezen.
Vraag: Functioneert Consul als een volwaardige server en verlopen alle aanvragen via hem?
Antwoord: Hij fungeert niet als een volwaardige server, maar neemt een bepaalde zone op zich. Deze eindigt doorgaans op service.consul. En dan gaan we verder volgens de logica. We gebruiken in productie geen domeinnamen, maar interne infrastructuur, die meestal achter servercaching verborgen is als we met DNS werken.
Vraag: Dus als we naar de database willen verwijzen, moeten we in elk geval Consul aanroepen om deze database eerst te vinden, klopt dat?
Antwoord: Ja. Als we via DNS werken, functioneert het hetzelfde als zonder Consul, wanneer we DNS-namen gebruiken. Moderne applicaties roepen niet bij elk verzoek een domeinnaam aan, omdat we de connectie hebben gelegd, alles werkt en we in de nabije toekomst iets minder vragen. Als de connectie verbroken is, dan ā ja, vragen we weer waar onze database zich bevindt en gaan we naar haar toe.
ā Chat voor gebruikers van Hashicorp: Consul, Nomad, Terraform
P.S. Over health checks. In Consul, net als in Kubernetes, wordt een vergelijkbaar systeem voor de gezondheidstoestand van de dienst op basis van de statuscode gebruikt.
200 OK voor gezond
503 Service Unavailable voor ongezondBronnen:
Bron: habr.com
