Jag föreslår att du läser utskriften av Alexander Sigachevs rapport Service Discovery i distribuerade system med Consul som exempel.
Service Discovery skapades så att du till en minimal kostnad kan ansluta en ny applikation till vår befintliga miljö. Med hjälp av Service Discovery kan vi maximalt separera antingen en dockningscontainer eller en virtuell tjänst från miljön där den körs.
Jag välkomnar alla! Jag heter Alexander Sigachev, jag jobbar på Inventos. Och idag kommer jag att introducera dig för ett sådant koncept som Service Discovery. Låt oss titta på Service Discovery med Consul som exempel.
Vilka problem löser Service Discovery? Service Discovery skapades så att du till en minimal kostnad kan ansluta en ny applikation till vår befintliga miljö. Med hjälp av Service Discovery kan vi maximalt separera antingen en dockningscontainer eller en virtuell tjänst från miljön där den körs.
Vad ser det ut som? I ett klassiskt exempel på webben är detta gränssnittet som accepterar användarens begäran. Sedan dirigerar den den till backend. I det här exemplet balanserar denna lastbalanserare två backends.
Här ser vi att vi lanserar en tredje instans av applikationen. Följaktligen, när applikationen startar, registreras den med Service Discovery. Service Discovery meddelar load-balancer. Load-balancer ändrar sin konfiguration automatiskt och den nya backend tas i drift. På detta sätt kan backends läggas till, eller omvänt, uteslutas från arbetet.
Vad mer är bekvämt att göra med Service Discovery? Service Discovery kan lagra nginx-konfigurationer, certifikat och en lista över aktiva backend-servrar.
Service Discovery låter dig också upptäcka fel och upptäcka fel. Vilka är de möjliga systemen för att upptäcka fel?
- Denna applikation som vi utvecklade meddelar automatiskt Service Discovery att den fortfarande fungerar.
- Service Discovery å sin sida undersöker applikationen för tillgänglighet.
- Eller så använder vi ett skript eller applikation från tredje part som kontrollerar vår applikation för tillgänglighet och meddelar Service Discovery att allt är bra och kan fungera, eller omvänt att allt är dåligt och att denna instans av applikationen måste uteslutas från balansering.
Vart och ett av scheman kan användas beroende på vilken programvara vi använder. Till exempel har vi precis börjat utveckla ett nytt projekt, då kan vi enkelt tillhandahålla ett schema när vår applikation meddelar Service Discovery. Eller så kan vi ansluta som Service Discovery kontrollerar.
Om vi ärvde applikationen eller utvecklades av någon annan, är det tredje alternativet lämpligt när vi skriver en hanterare, och allt detta kommer in i vårt arbete automatiskt.
Detta är ett exempel. Load-balancer i form av nginx startas om. Detta är ett valfritt verktyg som tillhandahålls med Consul. Detta är en konsul-mall. Vi beskriver regeln. Vi säger att vi använder en mall (Golang Template Engine). När händelser inträffar, när aviseringar om ändringar har inträffat, genereras det på nytt och kommandot "reload" skickas till Service Discovery. Det enklaste exemplet är när nginx omkonfigureras av en händelse och startas om.
Vad är konsul?
-
Först och främst är detta Service Discovery.
-
Den har en tillgänglighetskontrollmekanism - Health Checking.
-
Den har också en KV Store.
-
Och det är baserat på möjligheten att använda Multi Datacenter.
Vad kan allt detta användas till? I KV Store kan vi lagra exempelkonfigurationer. Hälsokontroll vi kan kontrollera den lokala tjänsten och meddela. Multi Datacenter används så att en servicekarta kan byggas. Amazon har till exempel 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 lokal trafik och följaktligen har mindre latens.
Låt oss förstå lite om termerna som används i Consul.
- Consul är en tjänst skriven i Go. En av fördelarna med ett Go-program är 1 binär fil som du precis laddar ner. Lanseras var som helst och du har inga beroenden.
- Sedan, med hjälp av nycklarna, kan vi starta denna tjänst antingen i klientläge eller i serverläge.
- Dessutom låter attributet "datacenter" dig ställa in en flagga till vilket datacenter denna server tillhör.
- Konsensus – baserat på flottprotokollet. Om någon är intresserad kan du läsa mer om detta på Consuls hemsida. Detta är ett protokoll som låter dig bestämma ledaren och bestämma vilka pengar som anses vara giltiga och tillgängliga.
- Skvaller är ett protokoll som möjliggör interaktion mellan noder. Dessutom är detta system decentraliserat. Inom ett datacenter kommunicerar alla noder med sina grannar. Och följaktligen överförs information om det aktuella tillståndet till varandra. Vi kan säga att detta är skvaller mellan grannar.
- LAN Gossip – lokalt datautbyte mellan grannar inom samma datacenter.
- WAN Gossip – används när vi behöver synkronisera information mellan två datacenter. Information flödar mellan noder som är markerade som en server.
- RPC – låter dig utföra förfrågningar via en klient på en server.
Beskrivning av RPC. Låt oss säga att Consul körs som en klient på en virtuell maskin eller fysisk server. Vi kontaktar honom lokalt. Och sedan begär den lokala klienten information från servern och synkroniseras. Beroende på inställningarna kan information hämtas från den lokala cachen, eller kan synkroniseras med ledaren, med servermastern.
Dessa två system har både för- och nackdelar. Om vi arbetar med en lokal cache så är det snabbt. Arbetar vi med data som lagras på servern tar det längre tid, men vi får mer relevant information.
Om du avbildar detta grafiskt är det här bilden av webbplatsen. Vi ser att vi har tre mästare igång. En är markerad med en asterisk som ledare. I det här exemplet finns det tre klienter som utbyter information lokalt med varandra via UDP/TCP. Och information mellan datacenter överförs mellan servrar. Här interagerar kunder med varandra lokalt.
Vilket API tillhandahåller Consul? För att få information har Consul två typer av API.
Detta är DNS API. Som standard körs Consul på port 8600. Vi kan konfigurera begäran om proxy och ge åtkomst genom lokal upplösning, genom lokal DNS. Vi kan fråga efter domän och ta emot IP-adressinformation som svar.
HTTP API – eller så kan vi lokalt begära information om en specifik tjänst på port 8500 och få ett JSON-svar, vilken IP servern har, vilken värd, vilken port som är registrerad. Och ytterligare information kan överföras via token.
Vad behöver du för att driva Consul?
I det första alternativet, i utvecklarläge, indikerar vi flaggan att detta är utvecklarläge. Agenten startar som en server. Och den utför hela funktionen oberoende på en maskin. Bekvämt, snabbt och praktiskt taget inga ytterligare inställningar krävs för första starten.
Det andra läget är lansering i produktion. Det är här att starta upp blir lite komplicerat. Om vi inte har någon version av konsuln måste vi ta med den första maskinen i bootstrap, det vill säga denna maskin, som tar på sig ledarens ansvar. Vi höjer den, sedan höjer vi den andra instansen av servern och skickar information till den där vår master finns. Vi höjer den tredje. Efter att vi har tre maskiner uppe startar vi om den i normalt läge på den första maskinen från den löpande bootstrap. Datan är synkroniserad och det ursprungliga klustret är redan uppe.
Det rekommenderas att köra tre till sju instanser i serverläge. Detta beror på det faktum att om antalet servrar växer så ökar tiden för synkronisering av information mellan dem. Antalet noder måste vara udda för att säkerställa kvorum.
Hur tillhandahålls hälsokontroller? Vi skriver en verifieringsregel i form av Json i Consuls konfigurationskatalog. Det första alternativet är tillgängligheten för domänen google.com i det här exemplet. Och vi säger att denna kontroll måste utföras med 30 sekunders intervall. På så sätt kontrollerar vi att vår nod har tillgång till det externa nätverket.
Det andra alternativet är att kontrollera dig själv. Vi använder vanlig curl för att anropa localhost på den angivna porten med intervaller på 10 sekunder.
Dessa kontroller sammanfattas och skickas till Service Discovery. Baserat på tillgänglighet är dessa noder antingen exkluderade eller visas i listan över tillgängliga och korrekt fungerande maskiner.
Consul tillhandahåller också ett UI-gränssnitt, som lanseras med en separat flagga och kommer att finnas tillgängligt på maskinen. Detta gör att du kan se information och du kan även göra vissa ändringar.
I det här exemplet är fliken "Tjänst" öppen. Det visas att tre tjänster är igång, en av dem är Consul. Antal utförda kontroller. Och det finns tre datacenter där maskinerna finns.
Detta är ett exempel på fliken Noder. Vi ser att de har sammansatta namn som involverar datacenter. Det visar också vilka tjänster som körs, det vill säga vi ser att inga taggar har satts. Dessa ytterligare taggar kan ge viss information som utvecklaren kan använda för att ange ytterligare parametrar.
Du kan också överföra information till Consul om status för diskar och genomsnittlig belastning.
frågor
Fråga: Vi har en hamnarcontainer, hur använder man den med Consul?
Svar: Det finns flera metoder för hamnarbetare. En av de vanligaste är att använda en tredje parts docker-container som ansvarar för registreringen. Vid start skickas en docker-socket till den. Alla containerregistrerings- och avpubliceringshändelser registreras i Consul.
Fråga: Så Consul startar dockarcontainern själv?
Svar: Nej. Vi kör en hamnarcontainer. Och när vi konfigurerar anger vi - lyssna på ett sådant och ett uttag. Det är ungefär detsamma som hur vi arbetar med ett certifikat, när vi laddar upp information om var och vad vi har.
Fråga: Det visar sig att det inuti Docker-behållaren som vi försöker koppla till Service Discovery borde finnas någon form av logik som kan skicka data till Consul?
Svar: Inte riktigt. När den startar skickar vi variabler genom miljövariabeln. Låt oss säga tjänstens namn, serviceport. Registret lyssnar på denna information och för in den i Consul.
Fråga: Jag har en annan fråga om användargränssnittet. Vi distribuerade gränssnittet, till exempel, på en produktionsserver. Hur är det med säkerheten? Var lagras uppgifterna? Är det möjligt att på något sätt samla data?
Svar: I användargränssnittet finns data från databasen och från Service Discovery. Vi ställer in lösenord i inställningarna själva.
Fråga: Kan detta publiceras på Internet?
Svar: Som standard startar Consul på localhost. För att publicera på Internet måste du installera någon form av proxy. Vi ansvarar för våra egna säkerhetsregler.
Fråga: Tillhandahåller den historiska data direkt? Det är intressant att titta på statistiken om hälsokontroller. Du kan också diagnostisera problem om servern ofta misslyckas.
Svar: Jag är inte säker på att det finns detaljer om kontroller där.
Fråga: Det nuvarande tillståndet är inte så viktigt som dynamiken.
Svar: För analys – ja.
Fråga: Är det bättre att inte använda Service Discovery för Consul docker?
Svar: Jag skulle inte rekommendera att använda den. Syftet med rapporten är att presentera vad ett sådant begrepp finns. Historiskt sett har den, enligt min mening, tagit sig till den första versionen. Nu finns det fler kompletta lösningar, till exempel Kubernetes, som har allt detta under huven. Som en del av Kubernetes Service Discovery är sämre än Etcd. Men jag är inte lika bekant med det som jag är med konsul. Därför bestämde jag mig för att göra Service Discovery med Consul som exempel.
Fråga: Saknar inte schemat med en ledarserver upp starten av applikationen som helhet? Och hur avgör konsul en ny ledare om den här ljuger?
Svar: De har ett helt protokoll beskrivet. Om du är intresserad kan du läsa den.
Fråga: Consul fungerar som en fullfjädrad server för oss och alla förfrågningar flyger igenom den?
Svar: Den fungerar inte som en fullfjädrad server, utan tar över en specifik zon. Det slutar vanligtvis med service.consul. Och sedan går vi vidare logiskt. Vi använder inte domännamn i produktionen utan snarare den interna infrastrukturen, som vanligtvis döljs bakom servercache om vi arbetar med DNS.
Fråga: Det vill säga, om vi vill komma åt en databas, så kommer vi i alla fall att dra Consul för att hitta den här databasen först, eller hur?
Svar: Ja. Om vi arbetar med DNS så fungerar det på samma sätt som utan Consul när vi använder DNS-namn. Vanligtvis drar moderna applikationer inte domännamnet i varje begäran, eftersom vi installerade connect, allt fungerar och inom en snar framtid använder vi det praktiskt taget inte. Om anslutningen är bruten, så frågar vi igen var vår bas är och går till den.
— Hashicorp användarchatt: Consul, Nomad, Terraform
P.S. Angående hälsokontroller. Consul, som Kubernetes, använder samma system för att kontrollera överlevnadsstatusen för en tjänst baserat på kodstatus.
200 OK for healthy
503 Service Unavailable for unhealthyKällor:
Källa: will.com