Service Discovery i distribuerade system med exempel från Consul. Alexander Sigajev.

Jag vill att du ska ta del av redogörelsen av Alexander Sigachevs föredrag om Service Discovery i distribuerade system med Consul som exempel.

Service Discovery är utformat för att ansluta en ny applikation till vår befintliga miljö med minimi kostnader. Genom att använda Service Discovery kan vi maximalt separera antingen en container i form av en Docker, eller en virtuell tjänst från den miljö där den körs.

Jag hälsar alla! Jag heter Alexander Sigachev, arbetar på företaget Inventos. Idag kommer jag att introducera er för konceptet Service Discovery. Vi kommer att titta på Service Discovery med Consul som exempel.

Vilka problem löser Service Discovery? Service Discovery är utformat för att ansluta en ny applikation till vår befintliga miljö med minimi kostnader. Genom att använda Service Discovery kan vi maximalt separera antingen en container i form av en Docker, eller en virtuell tjänst från den miljö där den körs.

Hur ser det ut? Ett klassiskt exempel på webben – det är frontend som tar emot användarens förfrågan. Sedan utför det routering till backend. I detta exempel balanserar load-balancern mellan två backend.

Här ser vi att vi startar en tredje instans av applikationen. När applikationen startar registrerar den sig i Service Discovery. Service Discovery informerar load-balancern. Load-balancern ändrar sin konfiguration automatiskt och den nya backend kopplas in. På så sätt kan backend läggas till eller, tvärtom, tas bort från drift.

Vad mer är praktiskt att göra med hjälp av Service Discovery? I Service Discovery kan konfigurationer av Nginx, certifikat och en lista över aktiva backend-servrar lagras.

Service Discovery möjliggör också upptäckten av fel och avbrott. Vilka möjliga scenarier finns det vid felupptäckten?

• Den här applikationen som vi har utvecklat informerar själv Service Discovery om att den fortfarande är operativ.
• Service Discovery å sin sida frågar applikationen om tillgänglighet.
• Eller så används ett externt skript eller applikation som kontrollerar vår applikation för tillgänglighet och informerar Service Discovery att allt är bra och att vi kan arbeta, eller vice versa, att något är fel och den här instansen av applikationen måste tas bort från balanseringen.

Varje schema kan tillämpas beroende på vilken programvara vi använder. Till exempel, om vi just har börjat utveckla ett nytt projekt kan vi utan problem tillhandahålla ett schema där vår applikation notifierar Service Discovery. Eller så kan vi ansluta så att Service Discovery genomför kontroller.

Om applikationen visade sig vara en arvet från någon annan eller utvecklad av en extern part, så passar den tredje varianten, där vi skriver en hanterare, och allt detta integreras automatiskt i vårt arbete.

Detta är ett av exemplen. Load-balancer i form av nginx laddas om. Detta är ett ytterligare verktyg som tillhandahålls tillsammans med Consul. Det är consul-template. Vi beskriver en regel. Vi säger att vi använder en mall (Golang-mallverktyget). Vid händelser, när notifieringar om ändringar inträffar, regenereras den och Service Discovery skickar kommandot "reload". Ett enkelt exempel är när nginx rekonfigureras och startas om vid en händelse.

Vad är Consul?

• Först och främst är det Service Discovery.

• Det har en mekanism för tillgänglighetskontroll – Health Checking.

• Det har också en KV Store.

• Och dess grund förutsätter möjlighet att använda Multi Datacenter.

Vad kan allt detta användas till? I KV Store kan vi lagra exempel på konfigurationer. Health Checking kan användas för att kontrollera lokala tjänster och notifiera. Multi Datacenter används för att kunna bygga en karta över tjänster. Till exempel har Amazon flera zoner och dirigerar trafiken på mest optimala sätt, så att det inte finns onödiga förfrågningar mellan datacentren, vilka debiteras separat från lokal trafik och därmed har lägre latens.

Låt oss ta en liten titt på de termer som används i Consul.

• Consul är en tjänst skriven i Go. En av fördelarna med programmet skrivet i Go är att det är en binärfil som du helt enkelt laddar ner. Du startar den från valfri plats och har inga beroenden.
• Sedan kan vi med hjälp av nycklar starta den här tjänsten antingen i klientläge eller i serverläge.
• Attributet "datacenter" låter oss sätta en flagga för vilket datacenter denna server tillhör.
• Consensus baseras på raft-protokollet. Om någon är intresserad kan man läsa mer om det på Consuls webbplats. Det är ett protokoll som gör det möjligt att bestämma ledaren och avgöra vilka data som ska beaktas som giltiga och tillgängliga.
• Gossip – en protokoll som möjliggör interaktion mellan noder. Detta system är decentraliserat. Inom ett datacenter kommunicerar alla noder med sina grannar. Och därmed överförs information om aktuellt tillstånd mellan dem. Man kan säga att det här är skvaller mellan grannarna.
• LAN Gossip – lokal datadelning mellan grannar inom ett datacenter.
• WAN Gossip – används när vi behöver synkronisera information mellan två datacenter. Informationen överförs mellan noder som markeras som servrar.
• RPC – möjliggör att utföra förfrågningar via en klient på servern.

Beskrivning av RPC. Anta att Consul körs som en klient på en virtuell eller fysisk server. Vi kommunicerar lokalt med den. Sedan begär den lokala klienten information från servern och synkroniseras. Beroende på inställningarna kan informationen ges från den lokala cachen eller synkroniseras med ledaren, servermaster.

Dessa två scheman har både fördelar och nackdelar. Om vi arbetar med lokal cache, är det snabbt. Om vi arbetar med data som lagras på servern, tar det längre tid, men vi får mer aktuell information.

Om vi skulle illustrera detta grafiskt, skulle det se ut som en webbplatsbild. Vi ser att tre masters körs. En markerad med en stjärna som ledare. I det här exemplet finns tre klienter som utbyter information lokalt via UDP/TCP. Och information mellan datacentren överförs mellan servrar. Här interagerar klienterna lokalt med varandra.

Vilken API tillhandahåller Consul? För att få information finns det två typer av API i Consul.

Detta är DNS API. Som standard körs Consul på port 8600. Vi kan konfigurera en proxyfråga och säkerställa tillgång genom lokal upplösning, via lokal DNS. Vi kan göra ett domänanrop och få information om IP-adressen som svar.

HTTP API – antingen kan vi på 8500-porten lokalt begära information om en specifik tjänst och få ett JSON-svar som visar vilken IP som servern har, vilken värd, vilken port som är registrerad. Ytterligare information kan också överföras via token.

Vad behövs för att starta Consul?

I den första versionen anger vi i utvecklarläge en flagga som visar att detta är utvecklarläge. Agenten startar som en server och utför hela funktionen självständigt på en och samma maskin. Bekvämt, snabbt och det krävs praktiskt taget inga ytterligare inställningar för första start.

Det andra läget är produktionsstart. Här blir lanseringen något mer komplicerad. Om vi inte har någon version av konsolen måste vi starta det första systemet i bootstrap-berget, d.v.s. denna maskin kommer att ta ansvar som ledare. Vi startar den, och sedan startar vi den andra serverinstansen, och överför informationen om var vår huvudserver ligger. Den tredje startas. Efter att tre maskiner har blivit aktiverade, startar vi den första maskinen från det pågående bootstrapet i normalt läge. Data synkroniseras, och den inledande klustret är redan aktivt.

Det rekommenderas att starta mellan tre och sju instanser i serverläge. Detta beror på att om antalet servrar ökar, ökar tiden för informationssynkronisering mellan dem. Antalet noder bör vara ojämnt för att säkerställa kvorum.

Hur säkerställs Health Checks? I konfigurationskatalogen för Consul skriver vi en kontrollregel i JSON-format. Första alternativet är tillgängligheten av, i detta exempel, domen google.com. Och vi anger att denna kontroll ska göras var 30:e sekund. På så sätt kontrollerar vi att vår nod har tillgång till det externa nätverket.

Det andra alternativet är självkontroll. Vi skickar en vanlig curl-anrop till localhost på den angivna porten med ett intervall på 10 sekunder.

Dessa kontroller summeras och går till Service Discovery. Baserat på tillgängligheten antingen utesluts noderna eller läggs till i listan över tillgängliga och korrekt fungerande maskiner.

Consul tillhandahåller också ett användargränssnitt som startas med en separat flagga och som kommer att finnas tillgängligt på maskinen. Detta gör att man kan visa information och också göra vissa ändringar.

I detta exempel har fliken "Tjänst" öppnats. Det visas att tre tjänster körs, varav en är Consul. Antalet verifieringar som har utförts. Och det finns tre datacenter där maskinerna befinner sig.

Detta är ett exempel på fliken «Nodes». Vi ser att de har sammansatta namn med data-center involverade. Här visas också vilka tjänster som är aktiverade, det vill säga vi ser att taggarna inte är angivna. I dessa extra taggar kan man ange viss information som utvecklaren kan använda för att ange ytterligare parametrar.

Man kan också skicka information till Consul om diskarnas status, om den genomsnittliga belastningen.

Frågor

Fråga: Vi har en docker-container, hur använder man den med Consul?

Svar: Det finns flera metoder för docker-containern. En av de vanligaste är att använda en extern docker-container ansvarig för registreringen. Vid start överförs dockersocket. Alla händelser kring registrering och avpublisering av containern registreras i Consul.

Fråga: Det vill säga, startar Consul docker-containern själv?

Svar: Nej. Vi startar docker-containern. Och vid konfiguration anger vi – lyssna på den här soketen. Det fungerar ungefär på samma sätt som med certifikatet, när vi överför information om var och vad som finns.

Fråga: Så inuti docker-containern som vi försöker koppla till Service Discovery måste det finnas någon logik som kan skicka data till Consul?

Svar: Inte riktigt. När den startar skickar vi genom miljövariabler. Till exempel, servicens namn, serviceport. I registret lyssnar den på denna information och registrerar den i Consul.

Fråga: Jag har ännu en fråga om UI. Vi har distribuerat UI, säg, på produktionsservern. Vad händer med säkerheten? Var lagras data? Kan man på något sätt samla data?

Svar: I UI kommer faktiskt datan från databasen och från Service Discovery. Lösenord anges manuellt i inställningarna.

Fråga: Kan detta publiceras på internet?

Svar: Som standard startar Consul på localhost. För att publicera detta på internet måste man installera en proxy. Vi ansvarar själva för säkerhetsregler.

Fråga: Ger den historiska data direkt ur lådan? Det skulle vara intressant att se statistik om Health Checks. Man kan ju diagnostisera problem om servern ofta går ner.

Svar: Jag är inte säker på att det finns detaljer om kontrollerna där.

Fråga: Inte så mycket det aktuella tillståndet, utan mer dynamiken är viktig.

Svar: För analys – ja.

Fråga: Bättre att inte använda Service Discovery för docker med Consul?

Svar: Jag skulle inte rekommendera att använda det. Syftet med presentationen är att introducera vad detta begrepp innebär. Historiskt sett har det utvecklats till, enligt min mening, version 1. Nu finns det mer fullfjädrade lösningar, som Kubernetes, som har allt detta under huven. Inom Kubernetes Service Discovery är Etcd underlägsen. Men jag känner inte till det så väl som jag gör med Consul. Därför bestämde jag mig för att demonstrera Service Discovery med hjälp av Consul.

Fråga: Fördröjer schemat med ledarservrar applikationens start överlag? Och hur identifierar Consul en ny ledare om den nuvarande ligger nere?

Svar: De har beskrivit en hel protokoll. Om du är intresserad kan du läsa om det.

Fråga: Aggerar Consul som en fullständig server och går alla förfrågningar genom den?

Svar: Den fungerar inte som en fullständig server utan tar en viss zon. Den slutar vanligtvis med service.consul. Och så följer vi logiken. Vi använder inte domännamn i produktion, utan specifikt intern infrastruktur, som oftast döljs bakom cachelagring av servern, om vi arbetar med DNS.

Fråga: Så, om vi vill komma åt databasen, kommer vi på ett eller annat sätt att behöva konsultera Consul för att först hitta den databasen, rätt?

Svar: Ja. Om vi arbetar med DNS fungerar det som utan Consul när vi använder DNS-namn. Vanligtvis gör inte moderna applikationer en DNS-förfrågan för varje begäran, eftersom vi har upprättat en anslutning och allt fungerar. Under en tid använder vi praktiskt taget inte det. Om anslutningen bryts, ja, då frågar vi igen var vår databas är och går dit.

Chat om Hashicorp-produkter — Användarchatt för Hashicorp: Consul, Nomad, Terraform

P.S. Angående hälsokontroller. I Consul som i Kubernetes används samma system för att kontrollera tjänsters hälsostatus baserat på statuskoden.

200 OK för hälsosam
503 Tjänst otillgänglig för ohälsosam

Källor:
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/

Källa: habr.com