„Nevarnost je moje drugo ime“, je dejal Austin Powers, človek-zagonetka mednarodnega obsega. A kar je cenjeno pri superagentih in obveščevalnih agencijah, ni primerno za računalniške storitve, kjer je dolgočasje veliko boljše od nevarnosti.
Istio, skupaj z OpenShift in Kubernetes, spreminja uvajanje mikroservisov v resnično dolgočasen in predvidljiv postopek - in to je čudovito. O tem in še marsičem bomo govorili v četrtem in zadnjem prispevku v seriji o Istio.
Ko je dolgočasje točno tisto, kar potrebujemo.
V našem primeru dolgočasje nastane le v končni fazi, ko ostane le še opazovati postopek. Toda pred tem je treba vse ustrezno nastaviti, in tukaj vas čaka veliko zanimivega.
Pri uvajanju nove različice vašega programske opreme je vredno razmisliti o vseh možnostih za zmanjšanje tveganja. Delo v paralelnem režimu je zelo močan in preizkušen način testiranja, Istio pa omogoča uporabo »tajne službe« (skrite različice vašega mikroservisa, ki ni dostopna zunanjim opazovalcem) brez motenj v produkcijski sistem. Za to obstaja celo poseben izraz - „Temno zagon“ (Dark Launch), ki se aktivira z funkcijo s prav tako vohunsko ime „zrcaljenje prometa“.
Upoštevajte, da se v prvem stavku prejšnjega odstavka uporablja izraz „uvajanje“ (deploy), ne pa „izdaja“ (release). Resnično bi morali imeti možnost uvajanja - in seveda, izvajanja - svojega mikroservisa tako pogosto, kot želite. Ta storitev bi morala biti sposobna sprejeti in obdelati promet, dajati rezultate ter pisati v dnevnike in biti pod nadzorom. Vendar pa same te storitve ni nujno izdajati v produkcijo. Uvajanje in izdaja programske opreme nista vedno isto. Uvajanje lahko izvajate kadarkoli, kadar želite, medtem ko lahko izdajo izvedete šele, ko ste dokončno pripravljeni.
Organizacija dolgočasa je zanimiva.
Oglejte si naslednje pravilo usmerjanja Istio, ki usmerja vse HTTP poizvedbe na mikroservis recommendation v1 (vse primere smo vzeli iz ), pri čemer jih hkrati zrcali na mikroservis recommendation v2:
Upoštevajte oznako mirror: na dnu zaslona - prav ona nastavi zrcaljenje prometa. Da, tako preprosto!
Rezultat tega pravila bo, da bo vaš produkcijski sistem (v1) še naprej obdeloval podatke, vendar se bodo ti podatki hkrati asinhrono preusmerjali na v2, torej bodo tam odhajali njihovi popolni podvojeni primerki. Tako boste lahko preizkusili delovanje v2 v realnih razmerah – na pravih podatkih in prometu – brez kakršnegakoli posega v delo produkcijskega sistema. Ali to organizacijo testiranja spremeni v dolgočasno opravilo? Da, nedvomno. A to je vseeno zanimivo.
Dodajmo dramo
Upoštevajte, da morajo biti v kodi v2 predvideni scenariji, ko lahko prejete zahteve privedejo do sprememb podatkov. Same zahteve se preusmerjajo enostavno in pregledno, a izbira načina obravnave v testnem okolju je prepuščena vam – in to je že nekoliko vznemirljivo.
Ponovimo pomembno točko
Tajni zagon s preusmerjanjem prometa (Dark Launch/Request Mirroring) lahko poteka brez poseganja v kodo.
Hrana za razmislek
Kaj pa, če bi del preusmerjenih zahtev pošiljali ne na v1, ampak na v2? Na primer, en odstotek vseh zahtev ali pa le zahteve od določene skupine uporabnikov. In nato, ko gledamo, kako deluje v2, postopoma preusmerimo vse zahteve na novo različico. Ali pa nasprotno, vrnemo vse na v1, če bo z v2 nekaj narobe. Zdi se, da se to imenuje Canary Deployment («kanarijevo razporejanje» – termin , in če bi imel ruski izvor, bi verjetno vseboval sklicevanje na ), in to bomo zdaj podrobneje obravnavali.
Canary Deployment v Istio: poenostavitev uvajanja
Skrbno in postopno
Bistvo modela Canary Deployment je izjemno preprosto: ko zagnate novo različico svoje programske opreme (v našem primeru – mikroservisa), najprej omogočite dostop majhni skupini uporabnikov. Če vse poteka normalno, postopoma povečujete to skupino, dokler nova različica ne začne slabo delovati, ali – če se to ne zgodi – na koncu preusmerite vse uporabnike. S premišljenim in postopnim uvajanjem nove različice ter nadzorovanim preklapljanjem uporabnikov lahko zmanjšate tveganja in maksimalizirate povratne informacije.
Seveda, Istio poenostavi Canary Deployment, saj ponuja več odličnih možnosti za inteligentno usmerjanje zahtevkov. In da, vse to lahko storite, ne da bi se dotaknili vaše izvorne kode.
Filtriramo brskalnik
E enostavnejših kriterijev usmerjanja je preusmeritev glede na brskalnik. Recimo, da želite, da gredo na v2 samo zahtevki iz brskalnika Safari. Tako to storite:
Uporabimo to pravilo usmerjanja in nato z ukazom curl v zanki possimuliramo prave zahteve do mikrostoritve. Kot je razvidno na posnetku zaslona, vsi gredo na v1:
Kje pa je promet na v2? Ker so v našem primeru vse zahteve prihajale le iz naše ukazne vrstice, ga enostavno ni. Vendar pa bodite pozorni na spodnje vrstice na zgornjem posnetku zaslona: to je odziv na to, da smo izvedli zahtevo iz brskalnika Safari, ki je podal naslednje:
Neomejena moč
Že smo pisali, da redni izrazi ponujajo zelo močne možnosti za usmerjanje zahtevkov. Poglejte naslednji primer (menimo, da boste tudi sami razumeli, kaj počne):
Zdaj si verjetno že predstavljate, kaj vse lahko redni izrazi zmorejo.
Delajte pametno
Pametno usmerjanje, še posebej obdelava naslovov paketov z uporabo rednih izrazov, omogoča upravljanje prometa, kot si želite. In to znatno poenostavi uvedbo nove kode – preprosto je, ne zahteva sprememb v sami kodi, in po potrebi je vse mogoče hitro vrniti nazaj.
Vas zanima?
Ste se zasidralo v želji po eksperimentiranju z Istio, Kubernetes in OpenShift na svojem računalniku? Ekipa je pripravila odličen v tej temi in objavila vse pripadajoče datoteke. Torej naprej, in si ne odrežite ničesar.
Istio Egress: izhod skozi spominsko trgovino
Z uporabo Istio skupaj z Red Hat OpenShift in Kubernetes si lahko precej olajšate življenje z mikrostoritvami. Servisna mreža Istio je skrita znotraj Kubernetes podov, vaš kod pa se izvaja (predvsem) izolirano. Učinkovitost, enostavnost sprememb, sledenje in drugo – vse to je enostavno uporabiti ravno zaradi uporabe sidecar kontejnerjev. Ampak kaj storiti, če mora vaš mikrostoritev komunicirati z drugimi storitvami, ki se nahajajo zunaj vašega sistema OpenShift-Kubernetes?
Tukaj na pomoč prihaja Istio Egress. Če povzamemo, omogoča dostop do virov (beri: «storitev»), ki niso vključeni v vaše Kubernetes pod sisteme. Brez dodatne nastavitve se v okolju Istio Egress promet usmerja le znotraj klasterjev pod in med temi klasterji na podlagi notranjih IP tabel. Takšno zaprtje odlično deluje, dokler ne potrebujete dostopa do storitev zunaj.
Egress omogoča obhod zgoraj omenjenih IP tabel, bodisi na podlagi pravil Egress, bodisi za obseg IP naslovov.
Recimo, da imamo Java program, ki izvaja GET zahtevek na httpbin.org/headers.
(httpbin.org je preprosto priročen vir za testiranje izhodnih storitvenih zahtevkov.)
Če vnesemo v ukazno vrstico curl http://httpbin.org/headers, bomo videli naslednje:
Ali pa lahko odprete isto naslov v brskalniku:
Kot vidimo, storitev tam preprosto vrne poslane glave.
Nadomeščamo neposredno
Sedaj vzamemo Java kodo te zunanje storitve glede na naš sistem in jo zaženemo pri sebi, kjer je, spomnimo, Istio. (To lahko storite sami, tako da se obrnete na .) Po izvedbi sestave ustrezne slike in njeni odpravi na platformi OpenShift, bomo to storitev poklicali z ukazom curl egresshttpbin-istioegress.$(minishift ip).nip.io, nato bomo na zaslonu videli tole:
He, kaj se je zgodilo? Še pred kratkim je delovalo. Kaj pomeni Not Found? Le nekaj minut nazaj smo to omogočili. curl.
Razširjanje IP tabel na celoten internet
Kriviti (ali zahvaliti) je treba Istio. Kajti Istio so preprosto sidecar kontejnerji, ki skrbijo za odkrivanje in usmerjanje (pa tudi številne druge stvari, o katerih smo govorili prej). Zaradi tega IP tabele poznajo le to, kar je znotraj vašega sistema klasterjev. httpbin.org je zunaj in torej nedostopen. Tukaj pa pomaga Istio Egress – brez kakršnihkoli sprememb v vašem izvorni kodi.
Spodnje pravilo Egress povzroči, da Istio išče (po potrebi tudi v celotnem svetovnem internetu) potrebno storitev, v tem primeru httpbin.org. Kot je razvidno iz tega dokumenta (egress_httpbin.yml), je funkcionalnost tukaj precej preprosta:
Samo še to pravilo je treba uporabiti:
istioctl create -f egress_httpbin.yml -n istioegress
Pravila Egress si lahko ogledate z ukazom istioctl get egressrules:
In končno, ponovno zagnamo ukaz curl – in vidimo, da vse deluje:
Razmišljamo odprto
Kot vidite, Istio omogoča organizacijo interakcij tudi z zunanjim svetom. Z drugimi besedami, še vedno lahko ustvarjate storitve OpenShift in jih upravljate prek Kubernetes-a, pri čemer vse shranjujete v pod-e, ki se po potrebi prilagajajo navzgor ali navzdol. Ob tem lahko brez skrbi dostopate do zunanjih storitev v svojem okolju. In ja, še enkrat ponavljamo, da lahko vse to počnete, ne da bi se dotaknili vašega kode.
To je bila zadnja objava iz serije o Istio. Ostajte z nami – še naprej vas čaka mnogo zanimivega!
Izvor: habr.com
