Dark Launch Istios: salajased teenistused

«Oht on minu teine nimi,» ütles Austin Powers, rahvusvaheline mõistatus. Kuid see, mis on superagentide ja salateenistuste seas au sees, ei sobi arvutiteenistustele, kus igavus on palju parem kui oht.

Ja Istio koos OpenShift ja Kubernetesega muudavad mikroteenuste juurutamise tõeliselt igavaks ja ennustatavaks – ja see on suurepärane. Sellest ja paljust muust räägime neljandas ja viimases postituses Istio seeriast.

Kui igavus on õige

Meie puhul tekib igavus alles lõppfaasis, kui jääb vaid istuda ja protsessi vaadata. Kuid selleks tuleb kõik eelnevalt seadistada, ja siin ootab teid palju huvitavat.

Uue tarkvara versiooni juurutamisel tasub kaaluda kõiki riski vähendamise võimalusi. Paralleelne töörežiim on väga võimas ja tõestatud testimismeetod ning Istio võimaldab selleks kasutada "salajast teenust" (teise, välistele silmadele peidetud versiooni teie mikroteenustest) ilma tootmisüsteemi töösse sekkumata. Selle jaoks on isegi spetsiaalne termin – "Salajane käivitamine" (Dark Launch), mille aktiveerimiseks on kasutada mitte vähem spioonide nime kandev funktsioon "liikluspeegeldamine".

Pange tähele, et eelneva lõigu esimeses lauses kasutatakse terminit „laadimine” (deploy), mitte „vabastamine” (release). Te peaksite tõeliselt olema võimelised laadima – ja loomulikult kasutama – oma mikroteenust nii tihti kui soovite. See teenus peab olema võimeline vastu võtma ja töötlema liiklust, andma tulemusi ning logima ja jälgima. Kuid see teenus ei pea tingimata olema tootmisse vabastatud. Laadimine ja tarkvara vabastamine ei ole alati sama asi. Laadimist saate teha alati, kui soovite, kuid vabastamisega peate ootama, kuni olete lõplikult valmis.

Igavuse korraldamine on huvitav

Vaadake järgmist Istio marsruutimisreeglit, mis suunab kõik HTTP-päringud mikroteenusele recommendation v1 (kõik näited on võetud Istio Tutorial GitHub repo), samal ajal peegeldades neid mikroteenusele recommendation v2:

Pange tähele sildist mirror: ekraani allosas – just see määrab liikluse peegeldamise. Jah, nii lihtne!

Selle reegli rakendamise tulemusena jätkab teie tootmissüsteem (v1) tulevate päringute töötlemist, kuid need päringud kajastuvad asünkroonselt v2-s, s.t. sinna saadetakse nende täisduplikaadid. Nii saate testida v2 toimimist reaalsetes tingimustes – tegelike andmete ja liikluse peal – sekkumata tootmissüsteemi tööse. Kas see muudab testimise igavaks? Jah, kindlasti. Aga see toimub põnevalt.

Lisame draamat

Pange tähele, et v2 koodis tuleb arvesse võtta olukordi, kus sissetulevad päringud võivad andmeid muuta. Päringud kajastuvad kergesti ja läbipaistvalt, kuid katse töötlemise viis jääb teie otsustada – ja see on juba veidi ärev.

Kordame olulist punkti

Salajast liikluse kajastamist (Dark Launch/Request Mirroring) saab teostada, mõjutamata koodi.

Mõtle sellele

Aga mis siis, kui peegeldamise koha asemel saadame osa päringutest mitte v1-le, vaid v2-le? Näiteks üks protsent kõigist päringutest või ainult teatud kasutajagrupi päringud. Ja seejärel, jälgides, kuidas v2 töötab, järk-järgult suunata kõik päringud uuele versioonile. Või vastupidi, tuua kõik tagasi v1-le, kui v2-l peaks midagi valesti minema. Tundub, et seda nimetatakse Canary Deployment ('kanareekoneering' - termin tõuseb kaevandamise alalt, ja kui sellel oleks Vene päritolu, sisaldaks see tõenäoliselt viidet kaslastele), ja nüüd vaatame seda lähemalt.

Canary Deployment Istios: lihtsustame käivitamist

Aeglaselt ja ettevaatlikult

Canary Deployment mudeli olemus on äärmiselt lihtne: kui käivitate uue versiooni oma tarkvarast (meie juhul mikroteenusest), siis anname sellele esialgu juurdepääsu väikesele kasutajate rühmale. Kui kõik läheb hästi, suurendate aeglaselt seda gruppi, kuni uus versioon hakkab häirima, või - kui seda ei juhtu - lõpuks suunate selle kõikidele kasutajatele. Uue versiooni hoolikas ja järkjärguline kasutusele võtmine ning kontrollitud kasutajate üleviimine vähendab riske ja maksimeerib tagasisidet.

Loomulikult lihtsustab Istio Canary Deployments, pakkudes mitmeid häid valikuid intelligentseks päringute suunamiseks. Ja jah, kõike seda saab teha, puudutamata teie algkoodi.

Filtreerime brauseri

Üks lihtsamaid suunamiskriteeriume on suunamine brauseri järgi. Oletame, et soovite, et v2-le suunatakse ainult päringud Safari brauseritest. Nii seda tehakse:

Rakendame seda suunamisreeglit ja seejärel curl simuleerime tsüklis reaalseid päringuid mikroteenusele. Nagu ekraanipildilt näha, suunatakse need kõik v1-le:

Kus on v2 liiklus? Kuna meie näites tulid kõik päringud ainult meie enda käsurealt, siis seda lihtsalt ei ole. Kuid vaadake üleval olevaid alumisi ridu: see on reaktsioon sellele, et sooritasime päringu Safari brauserist, mis andis meile järgmist:

Piiramatu võim

Oleme juba kirjutanud, et regulaaravaldised pakuvad väga võimsaid võimalusi päringute marsruutimiseks. Vaadake järgmist näidet (arvestame, et mõistate isegi, mida see teeb):

Nüüd on teil tõenäoliselt juba ettekujutus regulaaravalduste võimetest.

Käituge nutikalt

Nutikas marsruutimine, eelkõige pakettide päiste töötlemine regulaaravalduste abil, võimaldab liiklust suunata just nii, nagu soovite. Ja see lihtsustab uue koodi tööle rakendamist – see on lihtne, ei vaja koodi muutmist ja vajadusel saab kõike kiiresti tagasi põhiringi.

Kas olete huvitatud?

Kas olete innustunud katsetama Istio, Kubernetes ja OpenShift oma arvutis? Meeskond Red Hat Developer Team valmistab ette suurepärast õpetust selle teema kohta ning jagasin kõiki seotud faile üldiseks kasutamiseks. Nii et edasi ja ärge keelake endale mitte midagi.
 

Istio Egress: väljumine suveniiripoe kaudu

Kasutades Istio koos Red Hat OpenShift ja Kubernetes'iga, saab mikroteenuste haldamise oluliselt lihtsamaks. Istio teenusteside on peidetud Kubernetes'e pod'idesse, samas kui teie kood töötab (peamiselt) isoleeritult. Jõudlus, muudatuste lihtsus, jälgimine ja muu selline – kõik see on lihtne tänu sidecar konteinerite kasutamisele. Kuid mida teha, kui teie mikroteenus peab suhtlema teiste teenustega, mis asuvad väljaspool teie OpenShift-Kubernetes süsteemi?

Siia tuleb appi Istio Egress. Lühidalt öeldes võimaldab see juurdepääsu ressurssidele (loe: „teenustele”), mis ei kuulu teie Kubernetes'e pod'ide süsteemi. Kui te ei tee täiendavat seadistust, siis Istio Egress keskkonnas suunatakse liiklus ainult pod'ide klastris ja nende vahel sisemiste IP-tabelite alusel. Selline isoleeritus töötab suurepäraselt, kuni vajate juurdepääsu teenustele väljastpoolt.

Egress võimaldab ületada ülaltoodud IP-tabeleid, kas Egress reeglite põhjal või IP-aadresside vahemiku alusel.

Oletame, et meil on Java-programm, mis teeb GET-päringu aadressile httpbin.org/headers.

(httpbin.org on lihtsalt mugav ressurss väljuvate teenuse-päringute testimiseks.)

Kui sisestada käsureale curl http://httpbin.org/headers, näeme järgmist:

Või võite avada sama aadressi brauseris:

Nagu näeme, tagastab seal asuv teenus lihtsalt saadetud päised.

Impordime otse

Nüüd võtame selle välisteenuse Java-koodi ja käivitame selle endal, kus, meenutame, on Istio. (Saate seda ise teha, järgides meie Istio juhendit.) Koostades vastava konteineri ja käivitades selle OpenShift platvormil, kutsume seda teenust käsuga curl egresshttpbin-istioegress.$(minishift ip).nip.io, pärast mida näeme ekraanil järgmist:

Hmm, mis juhtus? Kõik töötas just hiljuti. Mida tähendab Not Found? Me just loomise jaoks tegime selle curl.

Laiene IP-tabelid kogu internetile.

Selle eest tuleb süüdistada (või tänada) Istio't. Istio on lihtsalt sidecar-konteinerid, mis vastutavad avastamise ja marsruutimise (ning paljude muude asjade eest, millest oleme varem rääkinud). Just seetõttu teavad IP-tabelid ainult sellest, mis asub teie klastrisüsteemi sees. Httpbin.org asub väljaspool ja seetõttu ei ole sellele ligipääsu. Siin tulebki appi Istio Egress – ilma, et oleks vajalikud muudatused teie lähtekoodis.

Allolev Egress-reegel paneb Istio otsima (vajadusel ka kogu maailmast) vajalikku teenust, antud juhul httpbin.org. Nagu näha failist (egress_httpbin.yml), on siin funktsionaalsus üsna lihtne:

Jääb üle vaid see reegel rakendada:

istioctl create -f egress_httpbin.yml -n istioegress

Egress-reegleid saab vaadata käsuga istioctl get egressrules:

Ja lõpuks, käivitame taas käsu curl – ja näeme, et kõik töötab:

Mõtle avatud meelega

Nagu näete, võimaldab Istio korraldada suhtlemist ka välismaailmaga. Teisisõnu, saate luua OpenShifti teenuseid ja hallata neid Kubernetes'i kaudu, hoides kõik pod'ides, mis vajadusel üles või alla skaalal. Samuti saate rahulikult rääkida välistest teenustest, mis on teie keskkonna suhtes. Ja jah, kordame veel kord, et kõike seda saab teha, puudutamata teie koodi.

See oli viimane postitus Istio seeriast. Jääge meiega – ees on palju huvitavat!

Allikas: habr.com