«Fare er mellomnavnet mitt», pleide Austin Powers, en internasjonal mystikkmann, å si. Men det som er høyt aktet av superagenter og etterretningstjenester egner seg slett ikke for datatjenester, der kjedsomhet er mye bedre enn fare.
Og Istio, sammen med OpenShift og Kubernetes, gjør distribusjon av mikrotjenester virkelig kjedelig og forutsigbar – og det er flott. Vi skal snakke om dette og mye mer i det fjerde og siste innlegget i Istio-serien.
Når kjedsomhet er riktig
I vårt tilfelle oppstår kjedsomhet først i sluttfasen, når det bare gjenstår å sitte og se på prosessen. Men for dette må du konfigurere alt først, og mange interessante ting venter på deg her.
Når du distribuerer en ny versjon av programvaren din, er det verdt å vurdere alle alternativer for å minimere risiko. Å kjøre parallelt er en veldig kraftig og velprøvd måte å teste på, og Istio lar deg bruke en "hemmelig tjeneste" (en skjult versjon av mikrotjenesten din) for å gjøre dette uten å forstyrre produksjonssystemet. Det er til og med en spesiell betegnelse for dette - "Dark Launch", som igjen aktiveres av en funksjon med et like spionnavn "trafikkspeiling".
Vær oppmerksom på at den første setningen i forrige avsnitt bruker begrepet «deploy» i stedet for «release». Du bør virkelig kunne distribuere – og selvfølgelig bruke – mikrotjenesten din så ofte du vil. Denne tjenesten må kunne motta og behandle trafikk, produsere resultater, og også skrive til logger og overvåke. Men samtidig trenger ikke denne tjenesten i seg selv nødvendigvis slippes ut i produksjon. Utrulling og utgivelse av programvare er ikke alltid det samme. Du kan distribuere når du vil, men slipp bare når du er klar.
Å organisere kjedsomhet er interessant
Ta en titt på følgende Istio-rutingsregel, som ruter alle HTTP-forespørsler til microservice-anbefalingen v1 (alle eksempler hentet fra ), mens de samtidig speiles til anbefaling v2 mikrotjeneste:
Vær oppmerksom på etiketten mirror: nederst på skjermen - det er denne som setter trafikkspeiling. Ja, så enkelt er det!
Resultatet av denne regelen vil være at produksjonssystemet ditt (v1) vil fortsette å behandle innkommende forespørsler, men selve forespørslene vil bli asynkront speilet til v2, det vil si at deres fullstendige duplikater vil gå dit. På denne måten kan du teste v2 under reelle forhold - på ekte data og trafikk - uten å forstyrre driften av produksjonssystemet på noen måte. Gjør dette det kjedelig å organisere testing? Ja, definitivt. Men det er gjort på en interessant måte.
La oss legge til drama
Vær oppmerksom på at i v2-koden er det nødvendig å ta hensyn til situasjoner der innkommende forespørsler kan føre til dataendringer. Selve forespørslene speiles enkelt og transparent, men valget av behandlingsmetode i testen er opp til deg – og dette er litt bekymringsfullt.
La oss gjenta et viktig poeng
Hemmelig lansering med trafikkspeiling (Dark Launch/Request Mirroring) kan utføres uten å påvirke koden på noen måte.
Noe å tenke på
Hva om stedet der forespørsler speiles sender noen av dem ikke til v1, men til v2? For eksempel én prosent av alle forespørsler eller bare forespørsler fra en bestemt gruppe brukere. Og når du allerede ser på hvordan v2 fungerer, overfører du gradvis alle forespørsler til den nye versjonen. Eller omvendt, returner alt til v1 hvis noe går galt med v2. Jeg tror det heter Canary Deployment. , og hvis det var av russisk opprinnelse, ville det sannsynligvis inneholde en henvisning til ), og nå skal vi se på dette mer detaljert.
Canary Deployment i Istio: forenkling av igangkjøring
Forsiktig og gradvis
Essensen av Canary Deployment-implementeringsmodellen er ekstremt enkel: Når du lanserer en ny versjon av programvaren din (i vårt tilfelle en mikrotjeneste), gir du først tilgang til den til en liten gruppe brukere. Hvis alt går bra, øker du denne gruppen sakte til den nye versjonen begynner å virke, eller - hvis den ikke gjør det - til slutt migrerer alle brukere til den. Ved å omtenksomt og gradvis introdusere en ny versjon og bytte brukere til den på en kontrollert måte, kan du redusere risikoen og maksimere tilbakemeldingene.
Selvfølgelig forenkler Istio Canary Deployment ved å tilby flere gode alternativer for intelligent forespørselsruting. Og ja, alt dette kan gjøres uten å berøre kildekoden din på noen måte.
Filtrering av nettleseren
Et av de enkleste rutingkriteriene er nettleserbasert omdirigering. La oss si at du bare vil at forespørsler fra Safari-nettlesere skal gå til v2. Slik gjøres det:
La oss bruke denne rutingsregelen og deretter bruke kommandoen curl Vi vil simulere reelle forespørsler til mikrotjenesten i en loop. Som du kan se på skjermbildet, går de alle til v1:
Hvor er trafikken på v2? Siden i vårt eksempel alle forespørsler bare kom fra vår egen kommandolinje, eksisterer den rett og slett ikke. Men vær oppmerksom på de nederste linjene på skjermen ovenfor: dette er en reaksjon på det faktum at vi utførte en forespørsel fra Safari-nettleseren, som igjen produserte dette:
Ubegrenset kraft
Vi har allerede skrevet at regulære uttrykk gir svært kraftige muligheter for ruting av forespørsler. Ta en titt på følgende eksempel (vi tror du vil forstå hva det gjør):
Nå har du sannsynligvis en ide om hva regulære uttrykk kan gjøre.
Oppfør smart
Smart ruting, spesielt behandling av pakkehoder ved hjelp av regulære uttrykk, lar deg styre trafikken slik du vil. Og dette forenkler implementeringen av ny kode betydelig - det er enkelt, det krever ikke å endre selve koden, og om nødvendig kan alt raskt returneres som det var.
Interessert?
Er du ivrig etter å eksperimentere med Istio, Kubernetes og OpenShift på datamaskinen din? Team forberedt en utmerket om dette emnet og gjorde alle de medfølgende filene offentlig tilgjengelige. Så fortsett og ikke nekt deg selv noe.
Istio Egress: gå ut gjennom suvenirbutikken
Ved å bruke Istio sammen med Red Hat OpenShift og Kubernetes kan du gjøre livet ditt med mikrotjenester mye enklere. Istios servicenettverk er skjult inne i Kubernetes-pods, og koden din kjører (for det meste) isolert. Ytelse, enkel endring, sporing osv. – alt dette er enkelt å bruke takket være bruken av sidevognscontainere. Men hva om mikrotjenesten din trenger å kommunisere med andre tjenester som er plassert utenfor OpenShift-Kubernetes-systemet?
Det er her Istio Egress kommer til unnsetning. I et nøtteskall lar det deg ganske enkelt få tilgang til ressurser (les: "tjenester") som ikke er en del av systemet med Kubernetes-pods. Hvis du ikke utfører ytterligere konfigurasjon, rutes trafikk i Istio Egress-miljøet kun innenfor en klynge av pods og mellom slike klynger basert på interne IP-tabeller. Og slik forpupping fungerer utmerket så lenge du ikke trenger tilgang til tjenester utenfra.
Egress lar deg omgå IP-tabellene ovenfor, enten basert på Egress-regler eller på en rekke IP-adresser.
La oss si at vi har et Java-program som sender en GET-forespørsel til httpbin.org/headers.
(httpbin.org er bare en praktisk ressurs for å teste utgående tjenesteforespørsler.)
Hvis du skriver inn på kommandolinjen curl http://httpbin.org/headers, vil vi se følgende:
Eller du kan åpne den samme adressen i nettleseren:
Som du kan se, returnerer tjenesten som ligger der ganske enkelt overskriftene som er sendt til den.
Vi bytter ut import på front
La oss nå ta Java-koden til denne tjenesten, eksternt til systemet vårt, og kjøre den på egen hånd, der, husk, Istio er installert. (Du kan gjøre dette selv ved å kontakte .) Etter å ha bygget det riktige bildet og lansert det på OpenShift-plattformen, vil vi kalle denne tjenesten med kommandoen curl egresshttpbin-istioegress.$(minishift ip).nip.io, hvoretter vi vil se dette på skjermen:
Oops, hva skjedde? Alt bare fungerte. Hva betyr Ikke funnet? Vi gjorde det bare for ham curl.
Utvide IP-tabeller til hele Internett
Istio bør klandres (eller takkes) for dette. Tross alt er Istio bare sidevognscontainere som er ansvarlige for deteksjon og ruting (og mye annet som vi snakket om tidligere). Av denne grunn vet IP-tabeller bare hva som er inne i klyngesystemet ditt. Og httpbin.org ligger utenfor og derfor utilgjengelig. Og det er her Istio Egress kommer til unnsetning – uten den minste endring i kildekoden din.
Egress-regelen nedenfor tvinger Istio til å søke (om nødvendig, deretter på hele Internett) etter den nødvendige tjenesten, i dette tilfellet httpbin.org. Som du kan se fra denne filen (egress_httpbin.yml), er funksjonaliteten her ganske enkel:
Alt som gjenstår er å bruke denne regelen:
istioctl create -f egress_httpbin.yml -n istioegress
Du kan se utgangsregler med kommandoen istioctl get egressrules:
Og til slutt kjører vi kommandoen igjen curl – og vi ser at alt fungerer:
Vi tenker åpent
Som du kan se, lar Istio deg organisere interaksjon med omverdenen. Med andre ord, du kan fortsatt lage OpenShift-tjenester og administrere dem gjennom Kubernetes, og holde alt i pods som skaleres opp og ned etter behov. Og samtidig kan du trygt få tilgang til tjenester utenfor miljøet ditt. Og ja, vi gjentar nok en gang at alt dette kan gjøres uten å berøre koden din på noen måte.
Dette var det siste innlegget i serien på Istio. Følg med - det er mye interessant i vente!
Kilde: www.habr.com