Jeg foreslår at du leser utskriften av Alexander Sigachevs rapport Service Discovery i distribuerte systemer ved å bruke Consul som eksempel.
Service Discovery ble opprettet slik at du med minimale kostnader kan koble en ny applikasjon til vårt eksisterende miljø. Ved å bruke Service Discovery kan vi maksimalt skille enten en docker-beholder eller en virtuell tjeneste fra miljøet den kjører i.
Jeg ønsker alle velkommen! Jeg er Alexander Sigachev, jeg jobber på Inventos. Og i dag vil jeg introdusere deg for et konsept som Service Discovery. La oss se på Service Discovery ved å bruke Consul som eksempel.
Hvilke problemer løser Service Discovery? Service Discovery ble opprettet slik at du med minimale kostnader kan koble en ny applikasjon til vårt eksisterende miljø. Ved å bruke Service Discovery kan vi maksimalt skille enten en docker-beholder eller en virtuell tjeneste fra miljøet den kjører i.
Hvordan ser det ut? I et klassisk eksempel på nettet er dette grensesnittet som godtar brukerens forespørsel. Deretter rutes den til backend. I dette eksemplet balanserer denne lastbalanseren to backends.
Her ser vi at vi lanserer en tredje instans av applikasjonen. Følgelig, når applikasjonen starter, registreres den med Service Discovery. Service Discovery varsler load-balancer. Load-balancer endrer konfigurasjonen automatisk og den nye backend-en settes i drift. På denne måten kan backends legges til, eller omvendt ekskluderes fra arbeid.
Hva annet er praktisk å gjøre med Service Discovery? Service Discovery kan lagre nginx-konfigurasjoner, sertifikater og en liste over aktive backend-servere.
Service Discovery lar deg også oppdage feil og oppdage feil. Hva er de mulige ordningene for å oppdage feil?
- Denne applikasjonen som vi utviklet gir automatisk melding til Service Discovery om at den fortsatt er funksjonell.
- Service Discovery, på sin side, spørre søknaden om tilgjengelighet.
- Eller vi bruker et tredjepartsskript eller -program som sjekker applikasjonen vår for tilgjengelighet og varsler Service Discovery om at alt er bra og kan fungere, eller omvendt at alt er dårlig og denne forekomsten av applikasjonen må utelukkes fra balansering.
Hver av ordningene kan brukes avhengig av hvilken programvare vi bruker. For eksempel har vi nettopp begynt å utvikle et nytt prosjekt, så kan vi enkelt tilby et opplegg når applikasjonen vår varsler Service Discovery. Eller vi kan koble til at Service Discovery sjekker.
Hvis vi har arvet applikasjonen eller ble utviklet av noen andre, er det tredje alternativet egnet når vi skriver en behandler, og alt dette kommer automatisk inn i arbeidet vårt.
Dette er ett eksempel. Load-balancer i form av nginx startes på nytt. Dette er et valgfritt verktøy som følger med Consul. Dette er konsul-mal. Vi beskriver regelen. Vi sier at vi bruker en mal (Golang Template Engine). Når hendelser inntreffer, når varsler om at endringer har skjedd, blir det regenerert og kommandoen "reload" sendes til Service Discovery. Det enkleste eksemplet er når nginx rekonfigureres av en hendelse og startes på nytt.
Hva er konsul?
-
Først av alt er dette Service Discovery.
-
Den har en tilgjengelighetskontrollmekanisme - Health Checking.
-
Den har også en KV Store.
-
Og det er basert på muligheten til å bruke Multi Datacenter.
Hva kan alt dette brukes til? I KV Store kan vi lagre eksempelkonfigurasjoner. Helsekontroll vi kan sjekke den lokale tjenesten og varsle. Multi Datacenter brukes slik at et tjenestekart kan bygges. Amazon har for eksempel flere soner og ruter trafikk på den mest optimale måten slik at det ikke er unødvendige forespørsler mellom datasentre, som belastes separat fra lokal trafikk og følgelig har mindre ventetid.
La oss forstå litt om begrepene som brukes i Consul.
- Consul er en tjeneste skrevet i Go. En av fordelene med et Go-program er 1 binær fil som du bare laster ned. Lansert fra hvor som helst og du har ingen avhengigheter.
- Deretter, ved hjelp av nøklene, kan vi starte denne tjenesten enten i klientmodus eller i servermodus.
- Dessuten lar "datasenter"-attributtet deg sette et flagg til hvilket datasenter denne serveren tilhører.
- Konsensus – basert på flåteprotokollen. Hvis noen er interessert kan du lese mer om dette på Consul-nettstedet. Dette er en protokoll som lar deg bestemme lederen og bestemme hvilke penger som anses som gyldige og tilgjengelige.
- Sladder er en protokoll som muliggjør interaksjon mellom noder. Dessuten er dette systemet desentralisert. Innenfor ett datasenter kommuniserer alle noder med sine naboer. Og følgelig blir informasjon om den nåværende tilstanden overført til hverandre. Vi kan si at dette er sladder mellom naboer.
- LAN Gossip – lokal datautveksling mellom naboer innenfor samme datasenter.
- WAN Gossip – brukes når vi skal synkronisere informasjon mellom to datasentre. Informasjon flyter mellom noder som er merket som en server.
- RPC – lar deg utføre forespørsler gjennom en klient på en server.
Beskrivelse av RPC. La oss si at Consul kjører som en klient på en virtuell maskin eller fysisk server. Vi kontakter ham lokalt. Og så ber den lokale klienten om informasjon fra serveren og synkroniseres. Avhengig av innstillingene kan informasjon hentes fra den lokale cachen, eller kan synkroniseres med lederen, med servermasteren.
Disse to ordningene har både fordeler og ulemper. Hvis vi jobber med en lokal cache, så er den rask. Arbeider vi med data som er lagret på serveren tar det lengre tid, men vi får mer relevant informasjon.
Hvis du skildrer dette grafisk, så er dette bildet av nettstedet. Vi ser at vi har tre mastere i gang. Den ene er merket med en stjerne som leder. I dette eksemplet er det tre klienter som utveksler informasjon lokalt med hverandre via UDP/TCP. Og informasjon mellom datasentre overføres mellom servere. Her samhandler klienter med hverandre lokalt.
Hvilken API tilbyr Consul? For å få informasjon har Consul to typer API.
Dette er DNS API. Som standard kjører Consul på port 8600. Vi kan konfigurere forespørsler om proxy og gi tilgang gjennom lokal oppløsning, gjennom lokal DNS. Vi kan spørre etter domene og motta IP-adresseinformasjon som svar.
HTTP API – eller vi kan lokalt be om informasjon om en spesifikk tjeneste på port 8500 og motta et JSON-svar, hvilken IP serveren har, hvilken vert, hvilken port som er registrert. Og tilleggsinformasjon kan overføres via token.
Hva trenger du for å drive Consul?
I det første alternativet, i utviklermodus, indikerer vi flagget at dette er utviklermodus. Agent starter som en server. Og den utfører hele funksjonen uavhengig på én maskin. Praktisk, rask og praktisk talt ingen ekstra innstillinger kreves for første start.
Den andre modusen er lansering i produksjon. Det er her oppstarten blir litt komplisert. Hvis vi ikke har noen versjon av konsulen, må vi bringe den første maskinen inn i bootstrap, dvs. denne maskinen, som vil ta på seg ansvaret til lederen. Vi hever den, så hever vi den andre forekomsten av serveren, og sender den informasjon der masteren vår befinner seg. Vi hever den tredje. Etter at vi har tre maskiner oppe, starter vi den på nytt i normal modus på den første maskinen fra den kjørende bootstrap. Dataene er synkronisert og den første klyngen er allerede oppe.
Det anbefales å kjøre tre til syv forekomster i servermodus. Dette skyldes det faktum at hvis antallet servere vokser, øker tiden for synkronisering av informasjon mellom dem. Antall noder må være oddetall for å sikre quorum.
Hvordan utføres helsesjekker? Vi skriver en verifikasjonsregel i form av Json i konfigurasjonskatalogen for Consul. Det første alternativet er tilgjengeligheten til google.com-domenet i dette eksemplet. Og vi sier at denne kontrollen må utføres med intervaller på 30 sekunder. På denne måten sjekker vi at noden vår har tilgang til det eksterne nettverket.
Det andre alternativet er å sjekke deg selv. Vi bruker vanlig curl for å ringe localhost på den angitte porten med intervaller på 10 sekunder.
Disse sjekkene oppsummeres og sendes til Service Discovery. Basert på tilgjengelighet er disse nodene enten ekskludert eller vises i listen over tilgjengelige og riktig fungerende maskiner.
Consul tilbyr også et UI-grensesnitt, som lanseres med et eget flagg og vil være tilgjengelig på maskinen. Dette lar deg se informasjon og du kan også gjøre noen endringer.
I dette eksemplet er "Service"-fanen åpen. Det er vist at tre tjenester kjører, en av dem er Consul. Antall kontroller utført. Og det er tre datasentre der maskinene er plassert.
Dette er et eksempel på fanen Noder. Vi ser at de har sammensatte navn som involverer datasentre. Den viser også hvilke tjenester som kjører, det vil si at vi ser at ingen tagger er satt. Disse tilleggstaggene kan gi noe informasjon som utvikleren kan bruke til å spesifisere tilleggsparametere.
Du kan også overføre informasjon til Consul om status for disker og gjennomsnittlig belastning.
spørsmål
Spørsmål: Vi har en docker-container, hvordan bruker vi den med Consul?
Svar: Det er flere tilnærminger for docker-container. En av de vanligste er å bruke en tredjeparts docker-beholder som er ansvarlig for registrering. Ved oppstart sendes en docker-socket til den. Alle containerregistreringer og depubliseringshendelser registreres i Consul.
Spørsmål: Så Consul starter selve docker-containeren?
Svar: Nei. Vi kjører en docker-container. Og når vi konfigurerer, indikerer vi - lytt til en slik og en slik kontakt. Dette er omtrent det samme som hvordan vi jobber med sertifikat, når vi laster opp informasjon om hvor og hva vi har.
Spørsmål: Det viser seg at inne i Docker-beholderen som vi prøver å koble til Service Discovery, burde det være en slags logikk som kan sende data til Consul?
Svar: Egentlig ikke. Når den starter, sender vi variabler gjennom miljøvariabelen. La oss si tjenestenavn, tjenesteport. Registeret lytter til denne informasjonen og legger den inn i Consul.
Spørsmål: Jeg har et annet spørsmål om brukergrensesnittet. Vi distribuerte brukergrensesnittet, for eksempel på en produksjonsserver. Hva med sikkerhet? Hvor lagres dataene? Er det mulig å samle data på en eller annen måte?
Svar: I brukergrensesnittet er det data fra databasen og fra Service Discovery. Vi setter selv passord i innstillingene.
Spørsmål: Kan dette publiseres på Internett?
Svar: Som standard starter Consul på localhost. For å publisere på Internett, må du installere en slags proxy. Vi er ansvarlige for våre egne sikkerhetsregler.
Spørsmål: Gir det historiske data ut av boksen? Det er interessant å se på statistikken om helsesjekker. Du kan også diagnostisere problemer hvis serveren ofte svikter.
Svar: Jeg er ikke sikker på at det er detaljer om sjekker der.
Spørsmål: Den nåværende tilstanden er ikke så viktig som dynamikken.
Svar: For analyse – ja.
Spørsmål: Er det bedre å ikke bruke Service Discovery for Consul docker?
Svar: Jeg vil ikke anbefale å bruke den. Hensikten med rapporten er å introdusere hva et slikt konsept eksisterer. Historisk sett har den, etter min mening, gått til 1. versjon. Nå er det flere komplette løsninger, for eksempel Kubernetes, som har alt dette under panseret. Som en del av Kubernetes Service Discovery er dårligere enn Etcd. Men jeg er ikke så kjent med det som jeg er med konsul. Derfor bestemte jeg meg for å gjøre Service Discovery ved å bruke Consul som eksempel.
Spørsmål: Brekker ikke opplegget med en lederserver starten av applikasjonen som helhet? Og hvordan bestemmer konsul en ny leder hvis denne lyver?
Svar: De har en hel protokoll beskrevet. Hvis du er interessert, kan du lese den.
Spørsmål: Consul fungerer som en fullverdig server for oss og alle forespørsler flyr gjennom den?
Svar: Den fungerer ikke som en fullverdig server, men tar over en bestemt sone. Det ender vanligvis med service.consul. Og så går vi logisk videre. Vi bruker ikke domenenavn i produksjonen, men heller den interne infrastrukturen, som vanligvis er skjult bak server-caching dersom vi jobber med DNS.
Spørsmål: Det vil si, hvis vi ønsker å få tilgang til en database, så vil vi i alle fall trekke Consul for å finne denne databasen først, ikke sant?
Svar: Ja. Hvis vi jobber med DNS, fungerer det på samme måte som uten Consul når vi bruker DNS-navn. Vanligvis trekker moderne applikasjoner ikke domenenavnet i hver forespørsel, fordi vi installerte Connect, alt fungerer og i nær fremtid bruker vi det praktisk talt ikke. Hvis tilkoblingen er brutt, ja, vi spør igjen hvor basen vår er og går til den.
— Hashicorp brukerchat: Consul, Nomad, Terraform
PS Angående helsesjekker. Consul, som Kubernetes, bruker det samme systemet for å sjekke overlevelsesstatusen til en tjeneste basert på kodestatus.
200 OK for healthy
503 Service Unavailable for unhealthyKilder:
Kilde: www.habr.com