Dark Launch i Istio: hemmelige tjenester

«Fare er mit navn», sagde Austin Powers, et internationalt mysterium. Men det, der værdsættes af superagenter og efterretningstjenester, er slet ikke passende for it-afdelinger, hvor kedsomhed er langt bedre end farer.

Og Istio sammen med OpenShift og Kubernetes gør implementeringen af mikrotjenester til en virkelig kedelig og forudsigelig opgave – og det er godt. Det og meget mere vil vi tale om i det fjerde og sidste indlæg i serien om Istio.

Når kedsomhed er korrekt

I vores tilfælde opstår kedsomhed kun i den afsluttende fase, hvor man kun skal sidde og observere processen. Men for at dette kan ske, skal alt være opsat på forhånd, og der venter dig meget interessant.

Når du implementerer en ny version af din software, er det værd at overveje alle muligheder for at minimere risici. At arbejde i parallelt tilstand er en meget effektiv og velprøvet testmetode, og Istio gør det muligt at involvere en 'hemmelig tjeneste' (en skjult version af din mikrotjeneste, ikke synlig for udenforstående) uden at forstyrre driften af produktionssystemet. Der er endda et specielt begreb for dette – 'Mørk Udgivelse' (Dark Launch), som aktiveres af funktionen med det ikke mindre spionagtige navn 'trafik spejling'.

Bemærk, at udtrykket 'implementering' (deploy) bruges i den første sætning i det foregående afsnit, ikke 'udgivelse' (release). Du skal virkelig kunne implementere – og naturligvis bruge – din mikrotjeneste så ofte som ønsket. Denne tjeneste skal kunne modtage og behandle trafik, returnere resultater samt logge og overvåge. Men dette betyder ikke nødvendigvis, at selve tjenesten skal frigives til produktionen. Implementering og udgivelse af software er ikke altid det samme. Du kan implementere når som helst du vil, men udgivelse kan kun ske, når du er helt klar.

At organisere kedsomhed er interessant

Tag et kig på følgende Istio routingregel, der dirigerer alle HTTP-anmodninger til mikrotjeneste recommendation v1 (alle eksempler er hentet fra Istio Tutorial GitHub repo), samtidig med at de spejles til mikrotjeneste recommendation v2:

Bemærk mærkaten mirror: i bunden af skærmbilledet – det er den, der angiver trafikspejling. Ja, det er så enkelt!

Resultatet af denne regel vil være, at dit produktionssystem (v1) fortsat vil behandle indkommende anmodninger, men anmodningerne vil blive asynkront spejlet til v2, hvilket betyder, at deres fulde duplikater vil blive sendt derhen. På denne måde kan du teste v2's funktion i virkelige forhold – med rigtige data og trafik – uden at blande dig i produktionens drift. Gør dette testprocessen kedelig? Ja, uden tvivl. Men det gøres på en interessant måde.

Lad os tilføje drama

Bemærk, at koden i v2 skal tage højde for situationer, hvor indkommende anmodninger kan føre til ændringer i data. Anmodningerne spejles let og gennemsigtigt, men måden at behandle i testen ligger i dine hænder - og det er lidt spændende.

Lad os gentage et vigtigt punkt

Den hemmelige lancering med trafikspejling (Dark Launch/Request Mirroring) kan udføres uden at berøre koden.

Til eftertanke

Hvad nu hvis vi sendte en del af anmodningerne ikke til v1, men til v2? For eksempel, en procentdel af alle anmodninger eller kun anmodninger fra en bestemt brugergruppe. Og så, ved at se på hvordan v2 fungerer, gradvist overføre alle anmodninger til den nye version. Eller omvendt, tilbage til v1, hvis noget går galt med v2. Det ser ud til, at dette kaldes Canary Deployment ("kanariedistribution" - termen henviser til minedrift, og havde det haft russisk oprindelse, ville det sandsynligvis have inkluderet en henvisning til katte), og nu vil vi se nærmere på dette.

Canary Deployment i Istio: forenkler implementeringen

Forsigtigt og gradvist

Essensen af Canary Deployment-modellen er meget simpel: når du lancerer en ny version af din software (i vores tilfælde - mikrotjenesten), giver du først en lille gruppe brugere adgang til den. Hvis alt går godt, øger du langsomt denne gruppe, indtil den nye version begynder at have problemer, eller - hvis det ikke sker - til sidst overfører du alle brugere til den. Ved omhyggeligt og gradvist at implementere den nye version og kontrolleret skifte brugerne til den, kan man reducere risiciene og maksimere feedbacken.

Selvfølgelig forenkler Istio Canary Deployment ved at tilbyde flere gode muligheder for intelligent anmodningsrouting. Og ja, alt dette kan gøres uden at røre ved din kildekode.

Filtrering af browser

Et af de enkleste kriterier for routing er omdirigering baseret på browser. Antag, at du kun vil have, at anmodninger fra Safari-browseren går til v2. Sådan gør du det:

Lad os anvende denne routingregel og derefter med kommandoen curl vil vi i en loop simulere reelle anmodninger til mikrotjenesten. Som det kan ses på skærmbilledet, går alle anmodninger til v1:

Men hvor er trafikken til v2? Da alle anmodninger i vores eksempel kom fra vores kommandoprompt, er der simpelthen ingen. Men bemærk de nederste linjer på skærmen ovenfor: det er reaktionen på, at vi udførte en anmodning fra Safari-browseren, som dernæst gav følgende:

Ubegribelig magt

Vi har tidligere nævnt, at regulære udtryk giver meget kraftfulde muligheder for routing af anmodninger. Se på følgende eksempel (vi tror, du selv forstår, hvad det gør):

Nu kan du sikkert allerede forestille dig, hvad regulære udtryk er i stand til.

Handling med omtanke

Intelligent routing, især behandling af pakkeshoveder ved hjælp af regulære udtryk, giver mulighed for at styre trafikken, som du ønsker. Og det gør det meget lettere at implementere ny kode – det er simpelt, det kræver ikke ændring af selve koden, og alt kan hurtigt tilbageføres, hvis det er nødvendigt.

Interesseret?

Er du klar til at eksperimentere med Istio, Kubernetes og OpenShift på din egen computer? Holdet Red Hat Developer Team har forberedt en fremragende håndbogen om dette emne og delt alle relaterede filer offentligt. Så kom i gang, og lad ikke noget tilbageholde dig.
 

Istio Egress: udgangen gennem gavebutikken

Ved at anvende Istio sammen med Red Hat OpenShift og Kubernetes kan du betydeligt forenkle dit arbejde med mikrotjenester. Istio-servicegitteret er skjult inde i Kubernetes' pods, mens din kode udføres (for det meste) isoleret. Ydeevne, let at ændre, sporing og meget mere - alt dette er nemt at bruge netop på grund af anvendelsen af sidecar-containere. Men hvad gør man, hvis din mikrotjeneste skal kommunikere med andre tjenester, der ligger uden for dit OpenShift-Kubernetes-system?

Her kommer Istio Egress til hjælp. Kort sagt giver det adgang til ressourcer (læs: «tjenester»), som ikke er en del af dine Kubernetes-pods. Uden yderligere konfiguration bliver trafikken i Istio Egress kun routet internt mellem pod'erne og mellem sådanne klynger baseret på interne IP-tabeller. Denne indkapsling fungerer fint, indtil du har brug for adgang til tjenester uden for systemet.

Egress tillader at omgå de nævnte IP-tabeller, enten baseret på Egress-regler eller for et interval af IP-adresser.

Lad os sige, at vi har et Java-program, der udfører en GET-anmodning til httpbin.org/headers.

(httpbin.org er bare en nyttig ressource til at teste udgående service-anmodninger.)

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

Eller vi kan åbne den samme adresse i browseren:

Som vi kan se, returnerer den tjeneste, der ligger der, blot de hænder, der sendes til den.

Importeres direkte

Nu tager vi Java-koden fra denne eksterne tjeneste i forhold til vores system og kører den, hvor vi minder om, at Istio er installeret. (Du kan gøre dette selv ved at gå til vores Istio tutorial.) Ved at bygge det relevante billede og køre det på OpenShift-platformen, vil vi kalde denne tjeneste med kommandoen curl egresshttpbin-istioegress.$(minishift ip).nip.io, hvorefter vi vil se følgende på skærmen:

Hov, hvad skete der? Det virkede jo lige før. Hvad betyder Not Found? Vi oprettede jo lige til det. curl.

Udvider IP-tabellerne til hele internettet

Det skal være Istio, der skal klandres (eller takkes). For Istio er der blot sidecar-containere, der er ansvarlige for opdagelse og routing (samt en masse andre ting, som vi tidligere har beskrevet). Derfor ved IP-tabellerne kun om, hvad der findes inde i dine klynge-systemer. Og httpbin.org ligger udenfor og er dermed utilgængeligt. Her kommer Istio Egress til undsætning – uden ændringer i din kildekode.

Den nedenstående Egress-regel får Istio til at søge (om nødvendigt i hele det globale internet) efter den ønskede tjeneste, i dette tilfælde httpbin.org. Som vist i denne fil (egress_httpbin.yml) er funktionaliteten her ret enkel:

Det er nu kun at anvende denne regel:

istioctl create -f egress_httpbin.yml -n istioegress

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

Og til sidst kører vi kommandoen igen curl – og ser, at alt fungerer:

Tænk åbent

Som du kan se, gør Istio det muligt at organisere interaktioner med verden udenfor. Med andre ord kan du stadig oprette OpenShift-tjenester og styre dem via Kubernetes, alt imens du holder det hele i pod'er, der skal skaleres op og ned efter behov. Og du kan trygt URL'e til tjenester, der er eksterne i forhold til dit miljø. Og ja, lad os gentage, at alt dette kan gøres, uden at røre ved din kode.

Dette var det sidste indlæg i serien om Istio. Bliv hos os – der er meget spændende i vente!

Kilde: habr.com