Jeg foreslår, at du læser udskriften af Alexander Sigachevs rapport Service Discovery i distribuerede systemer ved at bruge Consul som eksempel.
Service Discovery blev oprettet, så du med minimale omkostninger kan tilslutte en ny applikation til vores eksisterende miljø. Ved at bruge Service Discovery kan vi maksimalt adskille enten en docker-container eller en virtuel tjeneste fra det miljø, den kører i.
Jeg byder alle velkommen! Jeg er Alexander Sigachev, jeg arbejder hos Inventos. Og i dag vil jeg introducere dig til et koncept som Service Discovery. Lad os se på Service Discovery ved at bruge Consul som eksempel.
Hvilke problemer løser Service Discovery? Service Discovery blev oprettet, så du med minimale omkostninger kan tilslutte en ny applikation til vores eksisterende miljø. Ved at bruge Service Discovery kan vi maksimalt adskille enten en docker-container eller en virtuel tjeneste fra det miljø, den kører i.
Hvordan ser det ud? I et klassisk eksempel på nettet er dette frontend, der accepterer brugerens anmodning. Derefter dirigerer den den til backend. I dette eksempel balancerer denne load-balancer to backends.
Her ser vi, at vi lancerer en tredje instans af applikationen. Derfor, når applikationen starter, registreres den med Service Discovery. Service Discovery underretter load-balancer. Load-balancer ændrer automatisk sin konfiguration, og den nye backend sættes i drift. På denne måde kan backends tilføjes eller omvendt udelukkes fra arbejde.
Hvad er ellers praktisk at gøre med Service Discovery? Service Discovery kan gemme nginx-konfigurationer, certifikater og en liste over aktive backend-servere.
Service Discovery giver dig også mulighed for at opdage fejl og opdage fejl. Hvad er de mulige ordninger til at opdage fejl?
- Denne applikation, som vi udviklede, giver automatisk Service Discovery besked om, at den stadig er funktionel.
- Service Discovery undersøger på sin side applikationen for tilgængelighed.
- Eller vi bruger et tredjepartsscript eller en applikation, der tjekker vores applikation for tilgængelighed og giver Service Discovery besked om, at alt er i orden og kan fungere, eller omvendt, at alt er dårligt, og at denne forekomst af applikationen skal udelukkes fra balancering.
Hver af ordningerne kan bruges afhængigt af hvilken software vi bruger. For eksempel er vi lige begyndt at udvikle et nyt projekt, så kan vi nemt levere en ordning, når vores applikation giver Service Discovery besked. Eller vi kan forbinde, at Service Discovery tjekker.
Hvis vi har arvet applikationen eller blev udviklet af en anden, så er den tredje mulighed velegnet, når vi skriver en handler, og alt dette kommer automatisk ind i vores arbejde.
Dette er et eksempel. Load-balancer i form af nginx genstartes. Dette er et valgfrit hjælpeprogram, der leveres med Consul. Dette er en konsul-skabelon. Vi beskriver reglen. Vi siger, at vi bruger en skabelon (Golang Template Engine). Når hændelser opstår, når meddelelser om ændringer er sket, gendannes den, og kommandoen "genindlæs" sendes til Service Discovery. Det enkleste eksempel er, når nginx omkonfigureres af en hændelse og genstartes.
Hvad er konsul?
-
Først og fremmest er dette Service Discovery.
-
Den har en tilgængelighedskontrolmekanisme - Health Checking.
-
Det har også en KV Store.
-
Og det er baseret på muligheden for at bruge Multi Datacenter.
Hvad kan alt dette bruges til? I KV Store kan vi gemme eksempler på konfigurationer. Sundhedstjek vi kan tjekke den lokale service og give besked. Multi Datacenter bruges, så der kan bygges et servicekort. Eksempelvis har Amazon flere zoner og dirigerer trafik på den mest optimale måde, så der ikke er unødvendige forespørgsler mellem datacentre, som opkræves separat fra lokal trafik og dermed har mindre latency.
Lad os forstå lidt om de udtryk, der bruges i Consul.
- Consul er en tjeneste skrevet i Go. En af fordelene ved et Go-program er 1 binær fil, som du lige downloader. Lanceret hvor som helst, og du har ingen afhængigheder.
- Derefter kan vi ved hjælp af tasterne starte denne tjeneste enten i klienttilstand eller i servertilstand.
- Desuden giver attributten "datacenter" dig mulighed for at angive et flag, hvilket datacenter denne server tilhører.
- Konsensus – baseret på flådeprotokollen. Hvis nogen er interesseret, kan du læse mere om dette på Consuls hjemmeside. Dette er en protokol, der giver dig mulighed for at bestemme lederen og bestemme, hvilke penge der anses for gyldige og tilgængelige.
- Sladder er en protokol, der muliggør interaktion mellem noder. Desuden er dette system decentraliseret. Inden for ét datacenter kommunikerer alle noder med deres naboer. Og følgelig overføres oplysninger om den aktuelle tilstand til hinanden. Vi kan sige, at det er sladder mellem naboer.
- LAN Gossip – lokal dataudveksling mellem naboer inden for samme datacenter.
- WAN Gossip - bruges når vi skal synkronisere information mellem to datacentre. Informationsstrømme mellem noder, der er markeret som en server.
- RPC – giver dig mulighed for at udføre anmodninger gennem en klient på en server.
Beskrivelse af RPC. Lad os sige, at Consul kører som en klient på en virtuel maskine eller fysisk server. Vi kontakter ham lokalt. Og så anmoder den lokale klient om information fra serveren og synkroniseres. Afhængigt af indstillingerne kan information hentes fra den lokale cache eller synkroniseres med lederen med servermasteren.
Disse to ordninger har både fordele og ulemper. Hvis vi arbejder med en lokal cache, så er den hurtig. Arbejder vi med data, der er gemt på serveren, tager det længere tid, men vi får mere relevant information.
Hvis du afbilder dette grafisk, så er dette billedet af webstedet. Vi ser, at vi har tre mestre kørende. Den ene er markeret med en stjerne som leder. I dette eksempel er der tre klienter, der udveksler information lokalt med hinanden via UDP/TCP. Og information mellem datacentre overføres mellem servere. Her interagerer klienter med hinanden lokalt.
Hvilken API tilbyder Consul? For at få information har Consul to typer API.
Dette er DNS API. Som standard kører Consul på port 8600. Vi kan konfigurere anmodnings-proxy og give adgang gennem lokal opløsning, gennem lokal DNS. Vi kan forespørge efter domæne og modtage IP-adresseoplysninger som svar.
HTTP API - eller vi kan lokalt anmode om information om en specifik service på port 8500 og modtage et JSON svar, hvilken IP serveren har, hvilken vært, hvilken port er registreret. Og yderligere information kan overføres via token.
Hvad skal du bruge for at drive Consul?
I den første mulighed, i udviklertilstand, angiver vi flaget, at dette er udviklertilstand. Agent starter som en server. Og den udfører hele funktionen uafhængigt på én maskine. Praktisk, hurtig og praktisk talt ingen yderligere indstillinger kræves til den første start.
Den anden tilstand er lancering i produktion. Det er her opstart bliver lidt kompliceret. Hvis vi ikke har nogen version af konsulen, så skal vi bringe den første maskine i bootstrap, altså denne maskine, som vil påtage sig lederens ansvar. Vi hæver det, så rejser vi den anden forekomst af serveren og sender den information, hvor vores master er placeret. Vi rejser den tredje. Når vi har tre maskiner op, genstarter vi den i normal tilstand på den første maskine fra den kørende bootstrap. Dataene er synkroniseret, og den oprindelige klynge er allerede oppe.
Det anbefales at køre tre til syv forekomster i servertilstand. Dette skyldes det faktum, at hvis antallet af servere vokser, så øges tiden til at synkronisere information mellem dem. Antallet af noder skal være ulige for at sikre quorum.
Hvordan udføres sundhedstjek? Vi skriver en verifikationsregel i form af Json i Consul-konfigurationsmappen. Den første mulighed er tilgængeligheden af google.com-domænet i dette eksempel. Og vi siger, at denne kontrol skal udføres med intervaller på 30 sekunder. På denne måde tjekker vi, at vores node har adgang til det eksterne netværk.
Den anden mulighed er at tjekke dig selv. Vi bruger almindelig curl til at kalde localhost på den angivne port med intervaller på 10 sekunder.
Disse kontroller opsummeres og sendes til Service Discovery. Baseret på tilgængelighed er disse noder enten udelukket eller vises på listen over tilgængelige og korrekt fungerende maskiner.
Consul leverer også en UI-grænseflade, som lanceres med et separat flag og vil være tilgængelig på maskinen. Dette giver dig mulighed for at se oplysninger, og du kan også foretage nogle ændringer.
I dette eksempel er fanen "Service" åben. Det er vist, at tre tjenester kører, en af dem er konsul. Antal udførte kontroller. Og der er tre datacentre, hvori maskinerne er placeret.
Dette er et eksempel på fanen Noder. Vi ser, at de har sammensatte navne, der involverer datacentre. Det viser også, hvilke tjenester der kører, det vil sige vi ser, at der ikke er sat tags. Disse ekstra tags kan give nogle oplysninger, som udvikleren kan bruge til at angive yderligere parametre.
Du kan også sende information til Consul om status for diske og gennemsnitlig belastning.
R'RѕRїSЂRѕSЃS <
Spørgsmål: Vi har en docker-container, hvordan bruger man den med Consul?
Svar: Der er flere tilgange til havnemandscontainere. En af de mest almindelige er at bruge en tredjeparts docker-container, der er ansvarlig for registrering. Ved opstart sendes en docker-socket til den. Alle containerregistrerings- og de-publiceringshændelser registreres i Consul.
Spørgsmål: Så Consul starter selv docker-containeren?
Svar: Nej. Vi kører en havnemandscontainer. Og når vi konfigurerer, angiver vi - lyt til sådan og sådan en stikkontakt. Det er nogenlunde det samme, som vi arbejder med et certifikat, når vi uploader information om hvor og hvad vi har.
Spørgsmål: Det viser sig, at der inde i Docker-containeren, som vi forsøger at forbinde til Service Discovery, skulle være en form for logik, der kan sende data til Consul?
Svar: Ikke rigtig. Når den starter, sender vi variabler gennem miljøvariablen. Lad os sige servicenavn, serviceport. Registeret lytter til disse oplysninger og indtaster dem i konsul.
Spørgsmål: Jeg har et andet spørgsmål om brugergrænsefladen. Vi implementerede f.eks. brugergrænsefladen på en produktionsserver. Hvad med sikkerheden? Hvor opbevares dataene? Er det muligt på en eller anden måde at akkumulere data?
Svar: I brugergrænsefladen er der data fra databasen og fra Service Discovery. Vi sætter selv adgangskoder i indstillingerne.
Spørgsmål: Kan dette publiceres på internettet?
Svar: Som standard starter Consul på localhost. For at publicere på internettet skal du installere en form for proxy. Vi er ansvarlige for vores egne sikkerhedsregler.
Spørgsmål: Giver det historiske data ud af boksen? Det er interessant at se på statistikken om sundhedstjek. Du kan også diagnosticere problemer, hvis serveren ofte fejler.
Svar: Jeg er ikke sikker på, at der er detaljer om kontrol der.
Spørgsmål: Den nuværende tilstand er ikke så vigtig som dynamikken.
Svar: Til analyse – ja.
Spørgsmål: Er det bedre ikke at bruge Service Discovery til Consul docker?
Svar: Jeg vil ikke anbefale at bruge det. Formålet med rapporten er at introducere, hvad et sådant begreb findes. Historisk har den efter min mening fundet vej til 1. version. Nu er der mere komplette løsninger, for eksempel Kubernetes, som har alt dette under motorhjelmen. Som en del af Kubernetes Service Discovery er ringere end Etcd. Men jeg er ikke så bekendt med det, som jeg er med konsul. Derfor besluttede jeg at lave Service Discovery med Consul som eksempel.
Spørgsmål: Forsinker ordningen med en lederserver ikke starten af applikationen som helhed? Og hvordan bestemmer konsul en ny leder, hvis denne lyver?
Svar: De har en hel protokol beskrevet. Hvis du er interesseret, kan du læse den.
Spørgsmål: Consul fungerer som en fuldgyldig server for os, og alle anmodninger flyver igennem den?
Svar: Den fungerer ikke som en fuldgyldig server, men overtager en bestemt zone. Det ender normalt med service.consul. Og så går vi logisk videre. Vi bruger ikke domænenavne i produktionen, men derimod den interne infrastruktur, som normalt er gemt bag server caching, hvis vi arbejder med DNS.
Spørgsmål: Det vil sige, hvis vi vil have adgang til en database, så vil vi under alle omstændigheder trække Consul for at finde denne database først, ikke?
Svar: Ja. Hvis vi arbejder med DNS, så fungerer det på samme måde som uden Consul, når vi bruger DNS-navne. Typisk trækker moderne applikationer ikke domænenavnet i hver anmodning, fordi vi installerede connect, alt fungerer, og i den nærmeste fremtid bruger vi det praktisk talt ikke. Hvis forbindelsen er brudt, så ja, vi spørger igen, hvor vores base er og går til den.
— Hashicorp brugerchat: Consul, Nomad, Terraform
PS Angående sundhedstjek. Consul, ligesom Kubernetes, bruger det samme system til at kontrollere overlevelsesstatussen for en tjeneste baseret på kodestatus.
200 OK for healthy
503 Service Unavailable for unhealthyKilder:
Kilde: www.habr.com