"Nevarnost je moje srednje ime," je imel navado reči Austin Powers, mednarodni skrivnostni človek. Toda tisto, kar zelo cenijo superagenti in obveščevalne službe, ni prav nič primerno za računalniške storitve, kjer je dolgčas veliko boljši od nevarnosti.
In Istio, skupaj z OpenShift in Kubernetes, naredi uvajanje mikrostoritev resnično dolgočasno in predvidljivo – in to je super. O tem in še veliko več bomo govorili v četrti in zadnji objavi v seriji Istio.
Ko je dolgčas pravi
Pri nas nastopi dolgčas šele v končni fazi, ko preostane le še sedenje in opazovanje procesa. Toda za to morate najprej vse konfigurirati in tukaj vas čaka veliko zanimivih stvari.
Pri uvajanju nove različice vaše programske opreme je vredno razmisliti o vseh možnostih za zmanjšanje tveganj. Vzporedno izvajanje je zelo zmogljiv in preizkušen način testiranja, Istio pa vam omogoča, da uporabite »tajno storitev« (skrito različico vaše mikrostoritve), da to storite brez poseganja v produkcijski sistem. Za to obstaja celo poseben izraz - "Dark Launch", ki se aktivira s funkcijo s prav tako vohunskim imenom "traffic mirroring".
Upoštevajte, da je v prvem stavku prejšnjega odstavka uporabljen izraz "razporediti" namesto "izpustiti". Res bi morali imeti možnost razmestiti – in seveda uporabljati – vašo mikrostoritev tako pogosto, kot želite. Ta storitev mora biti sposobna sprejemati in obdelovati promet, ustvarjati rezultate ter pisati v dnevnike in spremljati. Toda hkrati ni nujno, da je ta storitev sama sproščena v proizvodnjo. Namestitev in izdaja programske opreme nista vedno ista stvar. Razmestite ga lahko kadarkoli želite, vendar ga sprostite šele, ko ste pripravljeni.
Organiziranje dolgčasa je zanimivo
Oglejte si naslednje pravilo usmerjanja Istio, ki vse zahteve HTTP usmerja na priporočilo mikrostoritve v1 (vsi primeri so vzeti iz ), hkrati pa jih zrcalite v mikrostoritev priporočila v2:
Bodite pozorni na oznako mirror: na dnu zaslona - to je tisto, ki nastavi zrcaljenje prometa. Da, tako preprosto je!
Rezultat tega pravila bo, da bo vaš produkcijski sistem (v1) še naprej obdeloval dohodne zahteve, vendar bodo same zahteve asinhrono zrcaljene v v2, kar pomeni, da bodo tja šli njihovi popolni dvojniki. Tako lahko testirate v2 v realnih pogojih – na realnih podatkih in prometu – brez da bi kakorkoli posegali v delovanje produkcijskega sistema. Je zaradi tega organizacija testiranja dolgočasna? Da, vsekakor. Ampak to je narejeno na zanimiv način.
Dodajmo dramo
Upoštevajte, da je treba v kodi v2 predvideti situacije, ko lahko dohodne zahteve povzročijo spremembe podatkov. Same zahteve se zrcalijo enostavno in pregledno, izbira načina obdelave v testu pa je prepuščena vam – kar je nekoliko zaskrbljujoče.
Ponovimo pomembno točko
Tajni zagon z zrcaljenjem prometa (Dark Launch/Request Mirroring) se lahko izvede, ne da bi kakor koli vplivali na kodo.
Hrana za misli
Kaj pa, če mesto, kjer so zahteve zrcaljene, nekaterih od njih ne pošlje v v1, ampak v v2? Na primer en odstotek vseh zahtev ali samo zahtev določene skupine uporabnikov. In potem, ko že pogledate, kako deluje v2, postopoma prenesite vse zahteve v novo različico. Ali obratno, vrnite vse na v1, če gre kaj narobe z v2. Mislim, da se imenuje Canary Deployment. , in če bi bilo ruskega izvora, bi verjetno vsebovalo sklicevanje na ), zdaj pa si bomo to podrobneje ogledali.
Canary Deployment v Istio: poenostavitev zagona
Previdno in postopoma
Bistvo modela uvedbe Canary Deployment je izjemno preprosto: ko zaženete novo različico vaše programske opreme (v našem primeru mikroservis), najprej omogočite dostop do nje majhni skupini uporabnikov. Če gre vse v redu, to skupino počasi povečujete, dokler nova različica ne začne delovati, ali – če ne – sčasoma vanjo preselite vse uporabnike. S premišljeno in postopno uvedbo nove različice ter kontroliranim preklopom uporabnikov nanjo lahko zmanjšate tveganja in povečate povratne informacije.
Seveda Istio poenostavlja Canary Deployment s ponudbo več dobrih možnosti za inteligentno usmerjanje zahtev. In ja, vse to je mogoče narediti, ne da bi se na kakršen koli način dotaknili vaše izvorne kode.
Filtriranje brskalnika
Eden najpreprostejših kriterijev usmerjanja je preusmeritev v brskalniku. Recimo, da želite, da gredo samo zahteve iz brskalnikov Safari na v2. Evo, kako se to naredi:
Uporabimo to pravilo usmerjanja in nato uporabimo ukaz curl V zanki bomo simulirali resnične zahteve do mikrostoritve. Kot lahko vidite na posnetku zaslona, gredo vsi na v1:
Kje je promet na v2? Ker so v našem primeru vse zahteve prihajale le iz lastne ukazne vrstice, preprosto ne obstaja. Toda bodite pozorni na spodnje vrstice na zgornjem zaslonu: to je reakcija na dejstvo, da smo izvedli zahtevo brskalnika Safari, ki je nato ustvarila tole:
Neomejena moč
Napisali smo že, da regularni izrazi zagotavljajo zelo zmogljive zmogljivosti za usmerjanje zahtev. Oglejte si naslednji primer (mislimo, da boste razumeli, kaj počne):
Zdaj verjetno že imate predstavo o tem, kaj lahko počnejo regularni izrazi.
Deluj pametno
Pametno usmerjanje, zlasti obdelava glav paketov z uporabo regularnih izrazov, vam omogoča usmerjanje prometa tako, kot želite. In to močno poenostavi implementacijo nove kode - preprosto je, ne zahteva spreminjanja same kode in po potrebi je mogoče vse hitro vrniti, kot je bilo.
Vas zanima?
Ste željni eksperimentiranja z Istio, Kubernetes in OpenShift v vašem računalniku? Ekipa pripravili odlično na to temo in javno objavil vse spremljajoče datoteke. Zato pojdi naprej in si ničesar ne odrekaj.
Istio Egress: izhod skozi trgovino s spominki
Če uporabljate Istio skupaj z Red Hat OpenShift in Kubernetes, si lahko zelo olajšate življenje z mikrostoritvami. Storitvena mreža Istio je skrita znotraj podov Kubernetes in vaša koda deluje (večinoma) izolirano. Zmogljivost, enostavnost menjave, sledenje itd. – vse to je enostavno za uporabo zahvaljujoč uporabi zabojnikov z bočno prikolico. Kaj pa, če mora vaša mikrostoritev komunicirati z drugimi storitvami, ki se nahajajo zunaj vašega sistema OpenShift-Kubernetes?
Tu na pomoč priskoči Istio Egress. Na kratko, preprosto vam omogoča dostop do virov (beri: »storitev«), ki niso del vašega sistema podov Kubernetes. Če ne izvedete dodatne konfiguracije, se v okolju Istio Egress promet usmerja samo znotraj gruče podov in med takimi gručami na podlagi notranjih tabel IP. In takšno mladičevanje deluje odlično, dokler ne potrebujete dostopa do storitev od zunaj.
Egress vam omogoča, da obidete zgornje tabele IP, bodisi na podlagi pravil Egress ali na podlagi obsega naslovov IP.
Recimo, da imamo program Java, ki pošlje zahtevo GET na httpbin.org/headers.
(httpbin.org je le priročen vir za testiranje odhodnih zahtevkov za storitve.)
Če vnesete v ukazno vrstico curl http://httpbin.org/headers, bomo videli naslednje:
Lahko pa odprete isti naslov v brskalniku:
Kot lahko vidite, tamkajšnja storitev preprosto vrne glave, ki so ji bile posredovane.
Neposredno nadomeščamo uvoz
Zdaj pa vzemimo kodo Java te storitve, ki je zunaj našega sistema, in jo zaženimo sami, kjer je, spomnimo se, nameščen Istio. (To lahko storite sami, tako da kontaktirate .) Ko zgradimo ustrezno sliko in jo zaženemo na platformi OpenShift, bomo to storitev poklicali z ukazom curl egresshttpbin-istioegress.$(minishift ip).nip.io, nato pa bomo na zaslonu videli tole:
Ups, kaj se je zgodilo? Vse je preprosto delovalo. Kaj pomeni Ni najdeno? Samo naredili smo to zanj curl.
Razširitev tabel IP na celoten internet
Istio je treba za to kriviti (ali se zahvaliti). Navsezadnje so Istio le zabojniki s prikolico, ki so odgovorni za odkrivanje in usmerjanje (ter veliko drugih stvari, o katerih smo govorili prej). Iz tega razloga tabele IP vedo samo, kaj je znotraj vašega sistema gruče. In httpbin.org se nahaja zunaj in zato nedostopen. In tukaj na pomoč priskoči Istio Egress - brez najmanjše spremembe vaše izvorne kode.
Spodnje pravilo Egress prisili Istio, da išče (če je potrebno, nato po celotnem internetu) zahtevano storitev, v tem primeru httpbin.org. Kot lahko vidite v tej datoteki (egress_httpbin.yml), je funkcionalnost tukaj precej preprosta:
Vse, kar ostane, je, da uporabite to pravilo:
istioctl create -f egress_httpbin.yml -n istioegress
Pravila Egress si lahko ogledate z ukazom istioctl get egressrules:
In končno znova zaženemo ukaz curl – in vidimo, da vse deluje:
Razmišljamo odprto
Kot lahko vidite, vam Istio omogoča organiziranje interakcije z zunanjim svetom. Z drugimi besedami, še vedno lahko ustvarite storitve OpenShift in jih upravljate prek Kubernetesa, pri čemer vse shranite v sklopih, ki se po potrebi spreminjajo navzgor in navzdol. Hkrati pa lahko varno dostopate do storitev zunaj vašega okolja. In ja, še enkrat ponavljamo, da je vse to mogoče storiti, ne da bi se na kakršen koli način dotaknili vaše kode.
To je bila zadnja objava v seriji na Istio. Ostanite z nami - čaka vas veliko zanimivega!
Vir: www.habr.com