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

Jag föreslår att du bekantar dig med avrapporteringen av Alexander Sigachev om Service Discovery i distribuerade system med exemplet Consul.

Service Discovery skapades för att möjliggöra anslutning av nya applikationer till vårt redan existerande miljö med minimal kostnad. Genom att använda Service Discovery kan vi maximalt separera antingen en container i form av Docker eller en virtuell tjänst från den miljö där den körs.

Jag hälsar alla! Jag är Alexander Sigachev, jobbar på företaget Inventos. Idag kommer jag att introducera er till begreppet Service Discovery. Vi kommer att titta på Service Discovery med exemplet Consul.

Vilka problem löser Service Discovery? Service Discovery skapades för att möjliggöra anslutning av nya applikationer till vår redan existerande miljö med minimal kostnad. Genom att använda Service Discovery kan vi maximalt separera antingen en container i form av Docker eller en virtuell tjänst från den miljö där den körs.

Hur ser det ut? På ett klassiskt exempel på webben – det är frontend som tar emot användarens begäran. Därefter utför det routning till backend. I det här exemplet balanserar load-balancern på två backend.

Här ser vi att vi startar en tredje instans av applikationen. När applikationen startas registreras den i Service Discovery. Service Discovery meddelar load-balancern, som automatiskt ändrar sin konfiguration och den nya backend-enheten börjar användas. På så sätt kan backend-enheter läggas till eller, å andra sidan, tas bort.

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

Dessutom gör Service Discovery det möjligt att upptäcka fel och avbrott. Vilka möjliga mönster finns det för att upptäcka avbrott?

• Denna applikation som vi har utvecklat meddelar själv Service Discovery att den fortfarande är verksam.
• Service Discovery å sin sida frågar applikationen angående dess tillgänglighet.
• Eller så används ett tredjeparts skript eller applikation som kontrollerar vår applikation för tillgänglighet och informerar Service Discovery att allt är bra och det går att arbeta, eller, å andra sidan, att allt är dåligt och denna instans av applikationen måste uteslutas 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 enkelt säkerställa ett schema där vår applikation notifierar Service Discovery. Eller så kan vi koppla in Service Discovery för att utföra kontroller.

Om applikationen däremot har ärvts till oss eller utvecklats av en tredje part, passar då det tredje alternativet, där vi skriver en hanterare och allt detta integreras automatiskt i vårt arbete.

Detta är ett exempel. Lastbalanseraren i form av nginx startar om. Det är ett extra verktyg som tillhandahålls tillsammans med Consul. Detta är consul-template. Vi beskriver en regel. Vi säger att vi använder en mall (Golang-mallmotor). Vid händelser, vid notifieringar om att förändringar har skett, regenereras den och Service Discovery får kommandot "reload". Ett enkelt exempel när nginx omkonfigureras och startas om på grund av en händelse.

Vad är Consul?

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

• Det har en mekanism för att kontrollera tillgänglighet – Health Checking.

• Det har också en KV Store.

• Och dess grundläggande funktionalitet är att använda Multi Datacenter.

Vad kan allt detta användas till? I KV Store kan vi lagra exempel på konfigurationer. Med Health Checking kan vi utföra kontroller av lokala tjänster och notifiera om status. Multi Datacenter används för att bygga en karta över tjänster. Till exempel har Amazon flera zoner och dirigerar trafik på det mest optimala sättet, så att det inte finns några onödiga förfrågningar mellan datacenter som debiteras separat från den lokala trafiken, vilket därmed ger lägre fördröjning.

Låt oss reda ut de termer som används i Consul.

• Consul är en tjänst som är skriven i Go. En av fördelarna med program som använder Go är att det är en enda binärfil som du helt enkelt laddar ner. Starta den från valfri plats och du har inga beroenden.
• Sedan kan vi med hjälp av nycklar starta denna tjänst antingen i klientläge eller i serverläge.
• Attributet "datacenter" tillåter oss också att sätta en flagga för vilket datacenter denna server tillhör.
• Konsensus baseras på raft-protokollet. För den som är intresserad kan man läsa mer om detta på Consuls webbplats. Detta är ett protokoll som gör det möjligt att bestämma en ledare och avgöra vilka data som ska anses vara giltiga och tillgängliga.
• Gossip är ett protokoll som möjliggör interaktion mellan noder. Dessutom är detta system decentraliserat. Inom ett datacenter kommunicerar alla noder med sina grannar. Informationen om det aktuella tillståndet överförs således mellan dem. Man kan säga att det är skvaller mellan grannarna.
• LAN Gossip – lokal dataöverföring mellan grannar inom ett datacenter.
• WAN Gossip – används när vi behöver synkronisera information mellan två datacenter. Informationen går mellan noder som är märkta som servrar.
• RPC – möjliggör att göra förfrågningar genom en klient på servern.

Beskrivning av RPC. Anta att Consul körs som klient på en virtuell eller fysisk server. Vi ansluter lokalt till den. Därefter begär den lokala klienten information från servern och synkroniserar. Informationen kan beroende på inställningarna ges från den lokala cachen, eller så kan den synkroniseras med ledaren, serverns master.

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 grafiskt skildrar detta ser vi en sådan bild av webbplatsen. Vi ser att vi har tre masters igång. En är markerad med en stjärna som ledare. I detta exempel finns tre klienter som lokalt utbyter information via UDP/TCP. Informationen mellan datacenter överförs mellan servrarna. Här interagerar klienterna lokalt med varandra.

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

Detta är DNS API. Som standard startar Consul på port 8600. Vi kan konfigurera proxyförfrågningar och säkerställa åtkomst via lokal upplösning, genom lokal DNS. Vi kan göra en förfrågan via domännamn och får svar med information om IP-adressen.

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

Vad behövs för att starta Consul?

I det första alternativet anger vi i utvecklarläget en flagga som indikerar att detta är utvecklarläge. Agenten startar som en server och utför hela funktionen självständigt på en enda maskin. Det är bekvämt, snabbt och kräver knappt några extra inställningar för första gången.

Det andra läget är start i produktion. Här blir starten något mer komplicerad. Om vi inte har någon version av konsolen måste vi sätta upp den första maskinen i bootstrap, det vill säga den maskin som kommer att ta på sig ledarrollen. Vi startar den, och därefter startar vi en andra serverinstans och överför informationen om var vår mästare befinner sig. Den tredje startar vi också. Efter att vi har fått upp tre maskiner, startar vi den första maskinen från den aktiva bootstrappen i ett normalt läge. Data synkroniseras, och den initiala klustret är nu igång.

Det rekommenderas att köra mellan tre och sju instanser i serverläge. Detta beror på att ju fler servrar vi har, desto längre tid tar det att synkronisera informationen mellan dem. Antalet noder bör vara udda för att säkerställa kvorum.

Hur säkerställs Health Checks? I konfigurationsmappen för Consul skriver vi en kontrollregel i Json. Det första alternativet är tillgängligheten i detta exempel av domänen google.com. Vi anger att kontrollen ska utföras var 30:e sekund. På detta sätt kontrollerar vi att vår nod har tillgång till det externa nätet.

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

Dessa kontroller summeras och skickas till Service Discovery. Baserat på tillgängligheten utesluts dessa noder eller läggs till i listan över tillgängliga och korrekt fungerande maskiner.

Consul erbjuder också ett UI-gränssnitt som startas med en separat flagga och kommer att vara tillgängligt på maskinen. Detta möjliggör visning av information samt att vissa ändringar kan göras.

I detta exempel är fliken "Tjänst" öppen. Det visas att tre tjänster körs, en av dem är Consul. Antalet genomförda kontroller och det finns tre datacenter där maskinerna finns.

Detta är ett exempel på fliken «Nodes». Vi ser att de har sammansatta namn med inblandning av datacenter. Här visas också vilka tjänster som är aktiverade, dvs. vi ser att taggarna inte är angivna. I dessa ytterligare taggar kan man ange viss information som utvecklaren kan använda för att specificera ytterligare parametrar.

Det går också att överföra information till Consul om disksystemets tillstånd och genomsnittlig belastning.

Frågor

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

Svar: För Docker-containrar finns det flera tillvägagångssätt. En av de vanligaste metoderna är att använda en tredjeparts Docker-container som ansvarar för registreringen. Vid start skickas en Docker-socket till den. Alla händelser kring registrering och avpublicering av containern registreras i Consul.

Fråga: Alltså, startar Consul Docker-containern själv?

Svar: Nej. Vi startar Docker-containern. Och vid konfiguration anger vi – lyssna på den specifika socket. Det är ungefär på samma sätt som när man arbetar med certifikat, när vi skickar information om var och vad vi har.

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

Svar: Inte riktigt. När den startar skickar vi via miljövariabler parametrarna. Till exempel, tjänstnamn, tjänstport. I registret lyssnar den på denna information och registrerar den i Consul.

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

Svar: I UI finns uppgifter från databasen och från Service Discovery. Vi ställer själva in lösenorden 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 vi ställa in någon form av proxy. Vi ansvarar själva för säkerhetsregler.

Fråga: Ger det historiska data direkt? Jag skulle vara intresserad av att se statistik över Health Checks. Man kan diagnostisera problem om servern ofta går ner.

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

Fråga: Det är inte så viktigt med det aktuella tillståndet, utan snarare dynamiken som är viktig.

Svar: För analys – ja.

Fråga: Är Service Discovery för Docker med Consul något man bör undvika?

Svar: Jag skulle inte rekommendera att använda den. Syftet med rapporten är att introducera konceptet. Historiskt sett har det kommit en lång väg, enligt mig, till den första versionen. Nu finns det mer omfattande lösningar, som Kubernetes, som har allt detta under huven. Inom Kubernetes Service Discovery ger Etcd avkall. Men jag är inte så välbekant med det som med Consul. Därför bestämde jag mig för att göra Service Discovery med Consul som exempel.

Fråga: Schematiseringen med en ledarserver fördröjer inte hela applikationens start? Och hur identifierar Consul en ny ledare om den gamla ligger nere?

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

Fråga: Aggerar Consul som en komplett server och skickas alla förfrågningar genom den?

Svar: Det fungerar inte som en komplett server, utan täcker ett visst område. Detta slutar oftast med service.consul. Och vidare följer vi logiken. Vi använder inte domännamn i produktion, utan intern infrastruktur som vanligtvis döljs bakom serverns cachning om vi arbetar med DNS.

Fråga: Det vill säga, om vi vill komma åt databasen, så kommer vi nödvändigtvis att fråga Consul för att först hitta denna databas, eller hur?

Svar: Ja. Om vi arbetar med DNS fungerar det som utan Consul när vi använder domännamn. Vanligtvis gör inte moderna applikationer en förfrågan om domännamnet vid varje begäran, eftersom vi har upprättat en anslutning, allt fungerar och på kort sikt använder vi knappt det. Om anslutningen bryts, ja, då frågar vi igen var vår databas ligger och går dit.

Chat om produkter från hashicorp — HashiCorp-användarchatt: Consul, Nomad, Terraform

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

200 OK för frisk
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