Dark Launch i Istio: hemmelige tjenester

«Fare er ikke noe for meg», sa Austin Powers, en internasjonal gåte. Men det som er på moten blant superagenter og etterretningstjenester, er helt uegnet for datarelaterte tjenester, der kjedsomhet er mye bedre enn fare.

Istio, sammen med OpenShift og Kubernetes, gjør distribusjon av mikrotjenester til en virkelig kjedelig og forutsigbar oppgave – og det er fantastisk. Dette og mye mer skal vi diskutere i det fjerde og siste innlegget i serien om Istio.

Når kjedsomhet er riktig

I vårt tilfelle oppstår kjedsomhet kun i den avsluttende fasen, når man bare må sitte og se på prosessen. Men for dette må alt være konfigurert på forhånd, og her venter det mange interessante ting.

Når du distribuerer en ny versjon av programvaren din, bør du vurdere alle alternativer for å minimere risikoene. Å jobbe parallelt er en svært kraftig og bevist testmetode, og Istio lar deg bruke en «hemmelig tjeneste» (en skjult versjon av mikrotjenesten din) uten å blande seg inn i driften av produksjonssystemet. Det finnes til og med et spesielt begrep for dette – «Dunkel lansering» (Dark Launch), som igjen aktiveres av en funksjon med det ikke mindre hemmelige navnet «trafikk-speiling».

Legg merke til at det i den første setningen i forrige avsnitt brukes begrepet «distribuering» (deploy), og ikke «utsendelse» (release). Du bør virkelig ha muligheten til å distribuere – og selvfølgelig bruke – mikrotjenesten din så ofte du ønsker. Denne tjenesten skal kunne motta og behandle trafikk, gi resultater, samt skrive til logger og overvåkes. Men selve tjenesten trenger ikke å lanseres i produksjon. Distribuering og utsendelse av programvare er ikke alltid det samme. Du kan alltid distribuere når du ønsker det, mens utsendelse kun kan skje når du er helt klar.

Å organisere kjedsomhet er interessant

Se på følgende Istio-ruteringsregel, som dirigerer alle HTTP-forespørslene til mikrotjenesten recommendation v1 (alle eksempler er hentet fra Istio Tutorial GitHub repo), samtidig som de speiles til mikrotjenesten recommendation v2:

Legg merke til merket mirror: nederst i skjermbildet – det er det som angir trafikk-speiling. Ja, så enkelt er det!

Resultatet av denne regelen vil være at produksjonssystemet ditt (v1) fortsatt vil behandle innkommende forespørsler, men forespørslene vil bli asynkront speilet til v2, det vil si at fullstendige kopier av dem sendes dit. Dermed kan du teste v2 under reelle forhold – med ekte data og trafikk – uten å forstyrre produksjonssystemet. Gjør dette testing til en kjedelig prosess? Ja, helt klart. Men det gjøres på en interessant måte.

La oss tilføre litt dramatikk

Vær oppmerksom på at i v2-koden må du ta høyde for situasjoner der innkommende forespørsler kan føre til endringer i data. Selve forespørslene speiles lett og gjennomsiktig, men valget av behandlingsmetode i testen ligger hos deg – og det er allerede litt spennende.

La oss gjenta det viktige punktet

Hemmelige lanseringer med trafikk-speiling (Dark Launch/Request Mirroring) kan utføres uten å berøre koden.

Mat for ettertanke

Hva om man i stedet for å speile alle forespørslene sender en del av dem ikke til v1, men til v2? For eksempel én prosent av alle forespørslene eller kun forespørslene fra en bestemt gruppe brukere. Og deretter, mens man ser på hvordan v2 fungerer, gradvis overfører alle forespørslene til den nye versjonen. Eller motsatt, tilbake til v1 hvis noe går galt med v2. Det virker som dette kalles Canary Deployment (»kanarielevering« – begrepet stammer fra gruvevirksomhet, og skulle det ha russisk opprinnelse, ville det sannsynligvis ha inneholdt en referanse til katter), og nå skal vi se nærmere på dette.

Canary Deployment i Istio: forenkler implementering

Forsiktig og gradvis

Essensen i Canary Deployment-modellen er meget enkel: når du lanserer en ny versjon av programvaren din (i vårt tilfelle – mikrotjenesten), gir du først tilgang til en liten gruppe brukere. Hvis alt går bra, øker du sakte denne gruppen inntil den nye versjonen begynner å feile, eller – hvis det ikke skjer – til slutt overfører du alle brukere til den. Ved å tenke klart og gradvis innføre den nye versjonen og kontrollert bytte brukere til den, kan du redusere risikoene og maksimere tilbakemeldinger.

Selvfølgelig forenkler Istio Canary Deployment ved å tilby flere gode alternativer for intelligent ruting av forespørselen. Ja, alt dette kan gjøres uten å berøre kildekoden din.

Filtrering av nettleser

Et av de enkleste rutingskriteriene er å omdirigere basert på nettleseren. La oss si du vil at bare forespørslene fra nettleseren Safari skal gå til v2. Slik gjør du det:

Vi bruker denne rutingsregelen, og deretter skal vi med kommandoen wget simulere ekte forespørselssykluser til mikrotjenesten. Som vist på skjermbildet går alle disse til v1:

Men hvor er trafikken til v2? Siden i vårt eksempel alle forespørslene kom fra kommandolinjen vår, er det rett og slett ingen. Men merk de nederste linjene på skjermbildet ovenfor: dette er reaksjonen på at vi utførte en forespørsel fra nettleseren Safari, som i sin tur ga dette:

Ubegrenset makt

Vi har allerede nevnt at regulære uttrykk gir svært kraftige muligheter for ruting av forespørselen. Ta en titt på følgende eksempel (vi tror du selv forstår hva det gjør):

Nå har du sikkert allerede en idé om hva regulære uttrykk kan gjøre.

Vær smart

Intelligent ruting, spesielt behandling av pakkens overskrifter ved hjelp av regulære uttrykk, lar deg styre trafikk slik du ønsker. Dette forenkler også innføringen av ny kode – det er enkelt, det krever ingen endring av selve koden, og om nødvendig kan alt raskt tilbakeføres til hvordan det var.

Er du interessert?

Har du fått lyst til å eksperimentere med Istio, Kubernetes og OpenShift på datamaskinen din? Teamet Red Hat Developer Team har laget en flott veiledning om dette emnet og gjort alle tilknyttede filer tilgjengelige. Så gå videre, og ikke hold tilbake.
 

Istio Egress: utgang gjennom suvenirbutikken

Ved å bruke Istio sammen med Red Hat OpenShift og Kubernetes kan du betydelig forenkle livet med mikrotjenester. Istio-service-mesh er skjult inne i Kubernetes-podene, og koden din kjører (hovedsakelig) isolert. Ytelse, enkelhet i endringer, sporing og mer – alt dette er lett tilgjengelig nettopp takket være bruken av sidecar-containere. Men hva gjør du hvis mikrotjenesten din må kommunisere med andre tjenester som ligger utenfor OpenShift-Kubernetes-systemet ditt?

Her er Istio Egress til hjelp. Kort sagt, det lar deg få tilgang til ressurser (les: «tjenester») som ikke er en del av Kubernetes-podene dine. Med mindre du gjør ekstra konfigurasjon, blir trafikken i Istio Egress rutet kun internt i pod-klyngene og mellom slike klynger, basert på interne IP-tabeller. Og denne isolasjonen fungerer utmerket så lenge du ikke trenger tilgang til tjenester utenfor.

Egress lar deg omgå de nevnte IP-tabellene, enten basert på Egress-regler eller for et IP-adresseområde.

La oss si at vi har et Java-program som gjør en GET-forespørsel til httpbin.org/headers.

(httpbin.org er bare en praktisk ressurs for å teste utgående tjenesteforespørsel.)

Hvis vi skriver inn i kommandolinjen curl http://httpbin.org/headers, vil vi se følgende:

Eller vi kan åpne den samme adressen i nettleseren:

Som vi ser, returnerer tjenesten som ligger der bare de oversendte overskriftene.

Importerer direkte

Nå tar vi Java-koden til denne eksterne tjenesten i forhold til systemet vårt og kjører den på vårt sted, hvor, la oss minne om, Istio er installert. (Du kan gjøre dette selv ved å kontakte vår veiledning for Istio.) Etter å ha bygget den tilsvarende imagen og kjørt den på OpenShift-plattformen, vil vi kalle denne tjenesten med kommandoen curl egresshttpbin-istioegress.$(minishift ip).nip.io, og så vil vi se dette på skjermen:

Hva skjedde nå? Det fungerte akkurat før. Hva betyr Not Found? Vi opprettet jo nettopp tilgangen. wget.

Utvider IP-tabellene til hele internett

Skylden (eller takken) for dette må gå til Istio. For Istio er rett og slett sidecar-containere som er ansvarlige for oppdagelse og ruting (og en rekke andre ting vi har snakket om tidligere). Av denne grunn vet IP-tabellene kun om det som er internt i klyngesystemene dine. Og httpbin.org ligger utenfor og er derfor utilgjengelig. Og her kommer Istio Egress til unnsetning – uten noen endringer i kildekoden din.

Den følgende Egress-regelen får Istio til å søke (hvis nødvendig, også i hele internett) etter den nødvendige tjenesten, i dette tilfellet httpbin.org. Som vi kan se fra denne filen (egress_httpbin.yml), er funksjonaliteten ganske enkel:

Det er bare å bruke denne regelen:

istioctl create -f egress_httpbin.yml -n istioegress

Du kan se Egress-reglene med kommandoen istioctl get egressrules:

Og til slutt, kjører vi kommandoen igjen wget – og ser at alt fungerer:

Tenk åpent

Som du ser, lar Istio deg organisere interaksjonen med omverdenen. Med andre ord kan du fortsatt opprette OpenShift-tjenester og styre dem via Kubernetes, mens alt holdes i pod-er som skaleres opp og ned etter behov. Og samtidig kan du trygt henvende deg til eksterne tjenester relatert til ditt miljø. Ja, la oss igjen gjenta at alt dette kan gjøres uten å endre koden din.

Dette var det siste innlegget i serien om Istio. Fortsett å følge med oss – mange spennende ting ligger foran!

Kilde: habr.com