Ik stel voor dat u het transcript van Alexander Sigachevs rapport Service Discovery in gedistribueerde systemen leest, waarbij u Consul als voorbeeld gebruikt.
Service Discovery is in het leven geroepen zodat u tegen minimale kosten een nieuwe applicatie kunt koppelen aan onze bestaande omgeving. Met Service Discovery kunnen we een dockercontainer of een virtuele service maximaal scheiden van de omgeving waarin deze draait.
Ik heet iedereen welkom! Ik ben Alexander Sigachev, ik werk bij Inventos. En vandaag zal ik u kennis laten maken met een concept als Service Discovery. Laten we Service Discovery eens bekijken met Consul als voorbeeld.
Welke problemen lost Service Discovery op? Service Discovery is in het leven geroepen zodat u tegen minimale kosten een nieuwe applicatie kunt koppelen aan onze bestaande omgeving. Met Service Discovery kunnen we een dockercontainer of een virtuele service maximaal scheiden van de omgeving waarin deze draait.
Hoe ziet het eruit? In een klassiek voorbeeld op internet is dit de frontend die het verzoek van de gebruiker accepteert. Vervolgens wordt het doorgestuurd naar de backend. In dit voorbeeld balanceert deze load balancer twee backends.
Hier zien we dat we een derde exemplaar van de applicatie lanceren. Dienovereenkomstig wordt de toepassing bij het starten geregistreerd bij Service Discovery. Service Discovery brengt de load balancer op de hoogte. Load-balancer verandert zijn configuratie automatisch en de nieuwe backend wordt in gebruik genomen. Op deze manier kunnen backends worden toegevoegd of omgekeerd van het werk worden uitgesloten.
Wat is er nog meer handig met Service Discovery? Service Discovery kan nginx-configuraties, certificaten en een lijst met actieve backend-servers opslaan.
Met Service Discovery kunt u ook fouten detecteren en fouten detecteren. Wat zijn de mogelijke schema's voor het opsporen van fouten?
- Deze door ons ontwikkelde applicatie laat Service Discovery automatisch weten dat deze nog steeds functioneert.
- Service Discovery controleert op zijn beurt de beschikbaarheid van de applicatie.
- Of we gebruiken een script of applicatie van derden die onze applicatie controleert op beschikbaarheid en Service Discovery laat weten dat alles in orde is en kan werken, of, omgekeerd, dat alles slecht is en dat dit exemplaar van de applicatie moet worden uitgesloten van de balancering.
Elk van de schema's kan worden gebruikt, afhankelijk van de software die we gebruiken. Als we bijvoorbeeld net zijn begonnen met het ontwikkelen van een nieuw project, kunnen we eenvoudig een schema leveren wanneer onze applicatie Service Discovery meldt. Of we kunnen verbinden dat Service Discovery controleert.
Als we de applicatie hebben geërfd of door iemand anders is ontwikkeld, dan is de derde optie geschikt als we een handler schrijven, en dit komt allemaal automatisch in ons werk.
Dit is één voorbeeld. Load-balancer in de vorm van nginx wordt opnieuw opgestart. Dit is een optioneel hulpprogramma dat bij Consul wordt geleverd. Dit is een consul-sjabloon. We beschrijven de regel. We zeggen dat we een sjabloon gebruiken (Golang Template Engine). Wanneer er gebeurtenissen plaatsvinden, wanneer er meldingen zijn dat er wijzigingen hebben plaatsgevonden, wordt deze opnieuw gegenereerd en wordt de opdracht “reload” naar Service Discovery verzonden. Het eenvoudigste voorbeeld is wanneer nginx opnieuw wordt geconfigureerd door een gebeurtenis en opnieuw wordt opgestart.
Wat is consul?
-
Allereerst is dit Service Discovery.
-
Het heeft een mechanisme voor beschikbaarheidscontrole: Health Checking.
-
Het heeft ook een KV-winkel.
-
En het is gebaseerd op de mogelijkheid om Multi Datacenter te gebruiken.
Waar kan dit allemaal voor gebruikt worden? In de KV Store kunnen we voorbeeldconfiguraties opslaan. Health Checking kunnen we de lokale service controleren en op de hoogte stellen. Er wordt gebruik gemaakt van Multi Datacenter zodat een servicemap kan worden opgebouwd. Amazon beschikt bijvoorbeeld over meerdere zones en routeert het verkeer op de meest optimale manier, zodat er geen onnodige verzoeken tussen datacenters plaatsvinden, die apart van het lokale verkeer in rekening worden gebracht en daardoor minder latentie hebben.
Laten we een beetje begrijpen wat de termen zijn die in Consul worden gebruikt.
- Consul is een dienst geschreven in Go. Eén van de voordelen van een Go-programma is dat je 1 binair bestand hebt dat je gewoon downloadt. Je kunt het overal vandaan lanceren en je hebt geen afhankelijkheden.
- Vervolgens kunnen we met behulp van de sleutels deze service starten in de clientmodus of in de servermodus.
- Met het attribuut “datacenter” kunt u ook een vlag instellen waartoe deze server behoort.
- Consensus – gebaseerd op het vlotprotocol. Mocht iemand interesse hebben, dan kun je hier meer over lezen op de website van Consul. Dit is een protocol waarmee u de leider kunt bepalen en kunt bepalen welk geld als geldig en toegankelijk wordt beschouwd.
- Roddel is een protocol dat interactie tussen knooppunten mogelijk maakt. Bovendien is dit systeem gedecentraliseerd. Binnen één datacenter communiceren alle knooppunten met hun buren. En dienovereenkomstig wordt informatie over de huidige status naar elkaar verzonden. We kunnen zeggen dat dit roddels zijn tussen buren.
- LAN Gossip – lokale gegevensuitwisseling tussen buren binnen hetzelfde datacenter.
- WAN Gossip - gebruikt wanneer we informatie tussen twee datacenters moeten synchroniseren. Informatie stroomt tussen knooppunten die zijn gemarkeerd als server.
- RPC – hiermee kunt u verzoeken uitvoeren via een client op een server.
Beschrijving van RPC. Stel dat Consul als client op een virtuele machine of fysieke server draait. Wij nemen lokaal contact met hem op. En dan vraagt de lokale client informatie op bij de server en wordt gesynchroniseerd. Afhankelijk van de instellingen kan informatie worden opgehaald uit de lokale cache, of worden gesynchroniseerd met de leider, met de servermaster.
Deze twee regelingen hebben zowel voor- als nadelen. Als we met een lokale cache werken, dan gaat het snel. Als we werken met gegevens die op de server staan, duurt het langer, maar krijgen we wel relevantere informatie.
Als je dit grafisch weergeeft, dan is dit de foto van de site. We zien dat er drie meesters actief zijn. Eén is gemarkeerd met een asterisk als leider. In dit voorbeeld zijn er drie clients die lokaal informatie met elkaar uitwisselen via UDP/TCP. En informatie tussen datacenters wordt tussen servers overgedragen. Hier communiceren cliënten lokaal met elkaar.
Welke API biedt Consul? Om informatie te verkrijgen beschikt Consul over twee soorten API's.
Dit is de DNS-API. Consul draait standaard op poort 8600. We kunnen verzoekproxy configureren en toegang bieden via lokale resolutie, via lokale DNS. We kunnen per domein opvragen en als antwoord IP-adresinformatie ontvangen.
HTTP API - of we kunnen lokaal informatie opvragen over een specifieke service op poort 8500 en een JSON-antwoord ontvangen, welk IP-adres de server heeft, welke host, welke poort is geregistreerd. En aanvullende informatie kan via een token worden verzonden.
Wat heb je nodig om Consul te runnen?
In de eerste optie geven we in de ontwikkelaarsmodus de vlag aan dat dit de ontwikkelaarsmodus is. Agent begint als server. En het voert de volledige functie onafhankelijk uit op één machine. Handig, snel en vrijwel geen extra instellingen nodig voor de eerste start.
De tweede modus wordt gelanceerd in productie. Dit is waar het opstarten een beetje ingewikkeld wordt. Als we geen versie van de consul hebben, moeten we de eerste machine in de bootstrap brengen, d.w.z. deze machine, die de verantwoordelijkheden van de leider op zich zal nemen. We verhogen het, vervolgens verhogen we het tweede exemplaar van de server en geven het informatie door waar onze master zich bevindt. We verhogen de derde. Nadat we drie machines hebben opgestart, starten we deze opnieuw op in de normale modus op de eerste machine vanaf de actieve bootstrap. De gegevens worden gesynchroniseerd en het initiële cluster is al actief.
Het wordt aanbevolen om drie tot zeven instances in de servermodus uit te voeren. Dit komt door het feit dat als het aantal servers groeit, de tijd voor het synchroniseren van informatie daartussen toeneemt. Het aantal knooppunten moet oneven zijn om het quorum te garanderen.
Hoe worden gezondheidscontroles uitgevoerd? We schrijven een verificatieregel in de vorm van Json in de Consul-configuratiemap. De eerste optie is de beschikbaarheid van het google.com-domein in dit voorbeeld. En we zeggen dat deze controle met tussenpozen van 30 seconden moet worden uitgevoerd. Zo controleren we of onze node toegang heeft tot het externe netwerk.
De tweede optie is om jezelf te controleren. We gebruiken reguliere curl om localhost op de opgegeven poort aan te roepen met tussenpozen van 10 seconden.
Deze controles worden samengevat en naar Service Discovery verzonden. Op basis van beschikbaarheid worden deze knooppunten uitgesloten of verschijnen ze in de lijst met beschikbare en correct werkende machines.
Consul biedt ook een UI-interface, die wordt gestart met een aparte vlag en beschikbaar zal zijn op de machine. Hiermee kunt u informatie bekijken en kunt u ook enkele wijzigingen aanbrengen.
In dit voorbeeld is het tabblad ‘Service’ geopend. Er wordt aangetoond dat er drie diensten actief zijn, waaronder Consul. Aantal uitgevoerde controles. En er zijn drie datacenters waarin de machines staan.
Dit is een voorbeeld van het tabblad Knooppunten. We zien dat ze samengestelde namen hebben voor datacenters. Het laat ook zien welke services actief zijn, d.w.z. we zien dat er geen tags zijn ingesteld. Deze extra tags kunnen bepaalde informatie verschaffen die de ontwikkelaar kan gebruiken om aanvullende parameters op te geven.
U kunt ook informatie naar Consul verzenden over de status van schijven en de gemiddelde belasting.
vragen
Vraag: We hebben een dockercontainer, hoe gebruik ik deze met Consul?
Antwoord: Er zijn verschillende benaderingen voor docker-containers. Een van de meest voorkomende is het gebruik van een docker-container van derden die verantwoordelijk is voor de registratie. Bij het opstarten wordt er een docker-socket aan doorgegeven. Alle containerregistratie- en depublicatiegebeurtenissen worden vastgelegd in Consul.
Vraag: Consul start dus zelf de docker-container?
Antwoord: Nee. We gebruiken een dockercontainer. En bij het configureren geven we aan: luister naar die en die socket. Dit is ongeveer hetzelfde als hoe wij met een certificaat werken, waarbij we informatie uploaden over waar en wat we hebben.
Vraag: Het blijkt dat er binnen de Docker-container die we proberen te verbinden met Service Discovery een soort logica moet zitten die gegevens naar Consul kan sturen?
Antwoord: Niet echt. Wanneer het begint, geven we variabelen door via de omgevingsvariabele. Laten we zeggen servicenaam, servicepoort. Het register luistert naar deze informatie en voert deze in Consul in.
Vraag: Ik heb nog een vraag over de gebruikersinterface. We hebben de gebruikersinterface bijvoorbeeld op een productieserver geïmplementeerd. Hoe zit het met de beveiliging? Waar worden de gegevens opgeslagen? Is het mogelijk om op de een of andere manier gegevens te verzamelen?
Antwoord: In de gebruikersinterface staan gegevens uit de database en uit Service Discovery. Wachtwoorden stellen we zelf in de instellingen in.
Vraag: Mag dit op internet gepubliceerd worden?
Antwoord: Consul start standaard op localhost. Om op internet te publiceren, moet u een soort proxy installeren. Wij zijn verantwoordelijk voor onze eigen veiligheidsregels.
Vraag: Biedt het out-of-the-box historische gegevens? Het is interessant om naar de statistieken over gezondheidscontroles te kijken. U kunt ook problemen diagnosticeren als de server vaak uitvalt.
Antwoord: Ik weet niet zeker of daar details over cheques staan.
Vraag: De huidige toestand is niet zo belangrijk als de dynamiek.
Antwoord: Voor analyse – ja.
Vraag: Is het beter om Service Discovery voor Consul docker niet te gebruiken?
Antwoord: Ik zou het niet aanraden om het te gebruiken. Het doel van het rapport is om te introduceren wat een dergelijk concept bestaat. Historisch gezien heeft het, naar mijn mening, zijn weg gevonden naar de eerste versie. Nu zijn er completere oplossingen, bijvoorbeeld Kubernetes, dat dit allemaal onder de motorkap heeft. Als onderdeel van Kubernetes is Service Discovery inferieur aan Etcd. Maar ik ben er niet zo bekend mee als bij Consul. Daarom besloot ik Service Discovery te maken met Consul als voorbeeld.
Vraag: Vertraagt het schema met een leaderserver niet de start van de applicatie als geheel? En hoe bepaalt Consul een nieuwe leider als deze liegt?
Antwoord: Ze hebben een heel protocol beschreven. Als je geïnteresseerd bent, kun je het lezen.
Vraag: Consul fungeert als volwaardige server voor ons en alle verzoeken vliegen er doorheen?
Antwoord: Het fungeert niet als een volwaardige server, maar neemt een specifieke zone over. Het eindigt meestal met service.consul. En dan gaan we logisch verder. We gebruiken in de productie geen domeinnamen, maar eerder de interne infrastructuur, die meestal verborgen is achter servercaching als we met DNS werken.
Vraag: Dat wil zeggen, als we toegang willen krijgen tot een database, dan zullen we in ieder geval Consul inschakelen om deze database eerst te vinden, toch?
Antwoord: Ja. Als we met DNS werken, dan werkt het hetzelfde als zonder Consul als we DNS-namen gebruiken. Doorgaans halen moderne applicaties niet bij elk verzoek de domeinnaam op, omdat we connect hebben geïnstalleerd, alles werkt en we het in de nabije toekomst praktisch niet meer gebruiken. Als de verbinding verbroken is, dan vragen we opnieuw waar onze basis is en gaan daarheen.
- Hashicorp-gebruikerschat: Consul, Nomad, Terraform
PS Wat betreft gezondheidscontroles. Consul gebruikt, net als Kubernetes, hetzelfde systeem om de overlevingsstatus van een dienst te controleren op basis van de codestatus.
200 OK for healthy
503 Service Unavailable for unhealthyBronnen:
Bron: www.habr.com