Jeg vil gerne præsentere transskriptionen af Alexander Sigachevs rapport om Service Discovery i distribuerede systemer med eksempel fra Consul.
Service Discovery er designet til at muliggøre tilslutning af nye applikationer til vores eksisterende miljø med minimal indsats. Ved at bruge Service Discovery kan vi adskille enten en container i form af Docker eller en virtuel tjeneste fra det miljø, som den kører i.
Jeg hilser alle! Jeg er Alexander Sigachev, jeg arbejder i virksomheden Inventos. I dag vil jeg introducere jer for begrebet Service Discovery. Vi vil se nærmere på Service Discovery med fokus på Consul.
Hvilke problemer løser Service Discovery? Service Discovery er skabt for at forbinde nye applikationer til det eksisterende miljø med minimale omkostninger. Ved at anvende Service Discovery kan vi i høj grad adskille enten en container i form af Docker eller en virtuel tjeneste fra det miljø, der er i brug.
Hvordan ser det ud? I et klassisk web-eksempel er det frontend, der modtager brugerens anmodning. Derefter udfører den routingen til backend. I dette eksempel balancerer load-balanceren mellem to backends.
Her ser vi, at vi starter en tredje instans af applikationen. Når applikationen starter, registrerer den sig i Service Discovery. Service Discovery informerer load-balanceren. Load-balanceren ændrer automatisk sin konfiguration, og den nye backend tages i brug. På den måde kan backends tilføjes eller udelukkes fra driften.
Hvad er der mere praktisk ved hjælp af Service Discovery? I Service Discovery kan der gemmes konfigurationer til nginx, certifikater og en liste over aktive backend-servere.
Service Discovery muliggør også fejlopdagelse og registrering af nedbrud. Hvilke mulige ordninger findes der for fejlopdagelse?
- Denne applikation, som vi har udviklet, informerer selv Service Discovery om, at den stadig er i drift.
- Service Discovery spørger applikationen om dens tilgængelighed.
- Eller der anvendes et eksternt script eller applikation, der kontrollerer vores applikation for tilgængelighed og informerer Service Discovery om, at alt er i orden og kan fungere, eller omvendt, at alt er dårligt, og denne instans af applikationen skal udelukkes fra balanceringen.
Hver af ordningerne kan anvendes afhængigt af hvilket software, vi bruger. For eksempel, hvis vi lige er begyndt at udvikle et nyt projekt, kan vi uden problemer implementere en ordning, hvor vores applikation underretter Service Discovery. Alternativt kan vi tilslutte, at Service Discovery udfører kontrol.
Hvis applikationen derimod er overtaget fra nogen anden eller udviklet af en tredjepart, så passer den tredje mulighed, hvor vi skriver en behandler, og alt dette integreres automatisk i vores arbejde.
Dette er et eksempel. Load-balancer i form af nginx genstartes. Det er et ekstra værktøj, som leveres sammen med Consul. Dette er consul-template. Vi beskriver en regel. Vi siger, at vi bruger en skabelon (Golang skabelongenerator). Ved hændelser, når der sker ændringer, regenereres den, og Service Discovery modtager ordren "reload". Det enkleste eksempel, hvor nginx omkonfigureres og genstartes ved en hændelse.
Hvad er Consul?
Først og fremmest er det Service Discovery.
Det har en mekanisme til tilgængelighedskontrol – Health Checking.
Det har også en KV Store.
Og det har fundamentalt evnen til at anvende Multi Datacenter.
Hvad kan alt dette bruges til? I KV Store kan vi opbevare konfigurations eksempler. Vi kan udføre Health Checking for at kontrollere lokale tjenester og underrette. Multi Datacenter bruges til at opbygge et kort over tjenester. For eksempel har Amazon flere zoner og routerer trafikken mest optimalt for at undgå unødvendige anmodninger mellem datacentre, som takseres separat fra lokal trafik, og som derfor har lavere latens.
Lad os se nærmere på de termer, der anvendes i Consul.
- Consul er en service skrives på Go. En af fordelene ved programmer på Go er, at det kun er én binær fil, som man bare downloader. Man kan starte det fra hvilken som helst placering, og der er ingen afhængigheder.
- Derudover kan vi ved hjælp af nøgler starte denne service enten i klientmode eller i servermode.
- Tillige giver attributten "datacenter" mulighed for at sætte et flag for hvilket datacenter denne server tilhører.
- Konsensus – er baseret på raft-protokollen. Hvis nogen er interesserede, kan man læse nærmere om dette på Consuls hjemmeside. Det er en protokol, der gør det muligt at bestemme en leder og definere, hvilke data der skal betragtes som gyldige og tilgængelige.
- Gossip er en protokol, der muliggør interaktion mellem noder. Desuden er dette system decentraliseret. Inden for et datacenter kommunikerer alle noder med deres naboer. Informationen om den aktuelle tilstand overføres derfor mellem dem. Man kan sige, at det er rygter mellem naboerne.
- LAN Gossip – lokal datadeling mellem naboer inden for et datacenter.
- WAN Gossip – anvendes, når vi skal synkronisere information mellem to datacentre. Informationen sendes mellem noder, der er markeret som servere.
- RPC – muliggør at udføre anmodninger gennem klienten på serveren.
Beskrivelse af RPC. Antag, at Consul kører som klient på en virtuel maskine eller en fysisk server. Vi henvender os lokalt til den. Derefter anmoder den lokale klient om information fra serveren og synkroniserer sig. Informationen kan afhængigt af indstillingerne hentes fra den lokale cache eller kan synkroniseres med lederen, server-masteren.
Disse to ordninger har både fordele og ulemper. Hvis vi arbejder med den lokale cache, er det hurtigt. Hvis vi arbejder med data, der er gemt på serveren, tager det længere tid, men vi får mere актуelle oplysninger.
Hvis vi skulle illustrere det grafisk, ser vi et billede af et website. Vi ser, at vi har tre mestre kørende. En er markeret med en stjerne som leder. I dette eksempel ser vi tre klienter, der lokalt udveksler information via UDP/TCP. Og informationen mellem datacentrene overføres mellem serverne. Her interagerer klienterne lokalt med hinanden.
Hvilken API tilbyder Consul? For at få information er der to typer API'er hos Consul.
Dette er DNS API. Som standard kører Consul på port 8600. Vi kan konfigurere anmodningsproxy og sikre adgang gennem lokal opløsning, via lokal DNS. Vi kan anmode om information via domænet og få information om IP-adressen som svar.
HTTP API – vi kan lokalt anmode om information om en specifik tjeneste på port 8500 og få et JSON-svar, der viser hvilken IP serveren har, hvilken vært samt hvilken port der er registreret. Yderligere information kan også overføres via token.
Hvad kræves der for at starte Consul?
I den første variant angiver vi i udviklertilstand flaget, at det er udviklertilstand. Agenten starter som server. Og udfører allerede alle funktioner selv på én maskine. Praktisk, hurtigt og næsten ingen yderligere indstillinger kræves for første opstart.
Anden tilstand er opstart i produktion. Her er opstarten en smule mere kompliceret. Hvis vi ikke har nogen version af konsollen, skal vi sætte den første maskine i bootstrap, det vil sige denne maskine, der påtager sig lederens opgaver. Vi starter den, og derefter ophæver vi en anden serverinstans, som vi giver information om, hvor vores master er. Den tredje starter vi. Efter at vi har startet tre maskiner, genstarter vi den første maskine fra den kørende bootstrap i normal tilstand. Data synkroniseres, og det indledende cluster er nu oppe.
Det anbefales at køre fra tre til syv instanser i servertilstand. Dette skyldes, at hvis antallet af servere stiger, øges tiden til synkronisering af information mellem dem. Antallet af noder skal være ulige for at sikre quorum.
Hvordan sikres Health Checks? I konfigurationsmappen for Consul skriver vi i JSON et kontrolregel. Den første variant er tilgængeligheden af domenet google.com i dette eksempel. Og vi angiver, at denne kontrol skal udføres med et interval på 30 sekunder. På denne måde kontrollerer vi, at vores node har adgang til det ydre netværk.
Den anden mulighed er at kontrollere sig selv. Vi bruger almindelig curl til at kontakte localhost på den angivne port med et interval på 10 sekunder.
Disse kontroller summeres op og sendes til Service Discovery. Baseret på tilgængeligheden bliver noderne enten ekskluderet eller inkluderet i listen over tilgængelige og korrekt fungerende maskiner.
Consul tilbyder også en UI-grænseflade, der startes med et separat flag og vil være tilgængelig på maskinen. Dette gør det muligt at se information og desuden foretage nogle ændringer.
I dette eksempel er fanen 'Service' åben. Det vises, at der kører tre tjenester, hvoraf en er Consul. Antallet af udførte kontroller. Der er tre datacentre, hvor maskinerne befinder sig.
Dette er et eksempel på fanen «Nodes». Her ser vi, at de har sammensatte navne involverende datacentre. Her vises også, hvilke tjenester der er aktive, dvs. vi ser, at tags ikke er angivet. I disse ekstra tags kan der angives oplysninger, som udvikleren kan bruge til at angive yderligere parametre.
Man kan også videregive oplysninger til Consul om diskens tilstand og den gennemsnitlige belastning.
Spørgsmål
Spørgsmål: Vi har en Docker-container, hvordan bruger vi den med Consul?
Svar: Der er flere tilgange til Docker-containeren. En af de mest almindelige er at bruge en tredjeparts Docker-container, der er ansvarlig for registreringen. Når den startes, gives der adgang til Docker-socket. Alle begivenheder omkring registrering og de-publicering af containeren registreres i Consul.
Spørgsmål: Så Consul starter selv Docker-containeren?
Svar: Nej. Vi starter Docker-containeren. Og ved konfigurationen angiver vi - lyt på den pågældende socket. Det er omtrent det samme som arbejdet med certifikatet, når vi passerer oplysninger om, hvor og hvad vi har.
Spørgsmål: Så inde i den Docker-container, som vi forsøger at tilslutte til Service Discovery, skal der være en form for logik, der kan afgive data til Consul?
Svar: Ikke helt. Når den starter, videregiver vi variabler gennem miljøet. Lad os sige, service name, service port. I registreringen lytter denne information og indlæser det i Consul.
Spørgsmål: Jeg har også et spørgsmål om UI. Vi har udrullet UI, lad os sige, på produktionsserveren. Hvad med sikkerheden? Hvor opbevares dataene? Kan man på en eller anden måde akkumulere data?
Svar: I UI er det netop data fra databasen og Service Discovery. Koderne angiver vi selv i indstillingerne.
Spørgsmål: Kan det offentliggøres på internettet?
Svar: Som standard starter Consul på localhost. For at offentliggøre dette til internettet skal man have en form for proxy. Vi er ansvarlige for sikkerhedsreglerne selv.
Spørgsmål: Giver det historiske data ud af boksen? Det ville være interessant at se statistikken for Health Checks. Man kan diagnosticere problemer, hvis serveren ofte går ned.
Svar: Jeg er ikke sikker på, at der er detaljer om tjekkene.
Spørgsmål: Det er ikke så vigtigt, hvad den nuværende tilstand er, men hvorvidt der er en dynamik.
Svar: Til analyse – ja.
Spørgsmål: Er Service Discovery for Docker bedre ikke at bruge Consul?
Svar: Jeg ville ikke anbefale at bruge det. Formålet med præsentationen er at introducere, hvad det er for et begreb. Historisk set har det gjort et spring, efter min mening, til version 1. Nu findes der allerede mere avancerede løsninger, såsom Kubernetes, som har alt dette under motorhjelmen. I Kubernetes ligger Service Discovery under Etcd. Men jeg er ikke så fortrolig med det som med Consul. Derfor besluttede jeg at demonstrere Service Discovery med Consul som eksempel.
Spørgsmål: Bremser skemaet med lederen serveren starten af applikationen generelt? Og hvordan bestemmer Consul en ny leder, hvis den nuværende er nede?
Svar: De har beskrevet et helt protokol. Hvis det er interessant, kan man læse om det.
Spørgsmål: Er Consul vores fuldgyldige server, og flyver alle forespørgsler gennem det?
Svar: Det fungerer ikke som en fuldgyldig server, men dækker et bestemt område. Det slutter som regel med service.consul. Og derefter følger vi logikken. Vi bruger ikke domænenavne i produktionen, men internt infrastruktur, der typisk skjules bag cache-serveren, når vi arbejder med DNS.
Spørgsmål: Altså, hvis vi vil tilgå databasen, skal vi i hvert fald spørge Consul for først at finde denne database, korrekt?
Svar: Ja. Hvis vi arbejder med DNS, fungerer det som uden Consul, når vi bruger DNS-navne. Normalt foretager moderne applikationer ikke et DNS-opslag for hver forespørgsel, fordi vi har etableret forbindelsen, alt fungerer, og i den nærmeste fremtid bruger vi det næsten ikke. Hvis forbindelsen brydes, så ja, vi spørger igen, hvor databasen ligger og går til den.
— Chat for Hashicorp-brugere: Consul, Nomad, Terraform.
P.S. Om sundhedstjek. I Consul, ligesom i Kubernetes, bruges det samme system til at tjekke servicens livskvalitet baseret på statuskode.
200 OK for sund
503 Service Unavailable for usundKilder:
Kilde: habr.com
