Dark Launch Istios: salajased teenused

«Ohtlikkus on minu teine nimi,» ütles Austin Powers, rahvusvaheline mõistatuslik kuju. Kuid see, mis on superagente ja eriteenistusi esindavates ringkondades au sees, ei sobi sugugi arvutite teenistustele, kus igavus on ohtudest tunduvalt parem.

Ja Istio koos OpenShifti ja Kubernetesega muudavad mikroteenuste juurutamise tõeliselt igavaks ja ettearvatavaks – ja see on suurepärane. Sellest ja paljuski muust räägime neljandas ja viimases postituses Istio sarjast.

Kui igavus on õige

Meie puhul tekib igavus ainult lõppfaasis, kui ei jää muud üle, kui lihtsalt istuda ja protsessi jälgida. Kuid selleks tuleb kõik eelnevalt seadistada, ja siin ootab teid palju huvitavat.

Uue tarkvara versiooni juurutamisel tasub kaaluda kõiki riskide vähendamise võimalusi. Töö paralleelselt – see on väga tõhus ja katsetatud testimise meetod, ja Istio võimaldab selleks kasutada "salajast teenistust" (peidetud versiooni teie mikroteenusest, mis ei ole avalikkusele nähtav) ilma tootmissüsteemi töösse sekkumata. Selleks on isegi spetsiaalne mõisted – "Tumedad juurutused" (Dark Launch), mis aktiveeritakse funktsiooni kaudu, millel on mitte vähem spioonide nimekiri „traffici peegeldamine“.

Pöörake tähelepanu, et eelmise lõigu esimeses lauses kasutatakse mõistet „juurutamine“ (deploy), mitte „vabastamine“ (release). Te tõeliselt peate olema suuteline juurutama – ja muidugi kasutama – oma mikroteenust nii sageli, kui soovite. See teenus peab olema suuteline vastu võtma ja töötlema liiklust, andma tulemusi ning kirjutama logidesse ja olema jälgitav. Kuid see teenus ise ei pea tingimata tootmisse minema. Juurutamine ja tarkvara vabastamine ei tähenda alati sama asja. Juurutamist saate teha alati, kui soovite, kuid vabastamine – ainult siis, kui olete lõplikult valmis.

Igavuse korraldamine on huvitav

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

Pöörake tähelepanu sildile mirror: ekraanil allosas – just see määrab liikluse peegeldamise. Jah, see on tõesti nii lihtne!

Selle reegli tulemuseks on see, et teie tootmissüsteem (v1) jätkab laekuvate päringute töötlemist, kuid samas peegeldavad need päringud asümmeetriliselt v2, kus nende täielikud koopiad saadetakse. Nii saate testida v2 tööd reaalsetes tingimustes – päris andmete ja liiklusega – ilma tootmissüsteemi sekkumiseta. Kas muudab see testimise korraldamise igavaks? Jah, kindlasti. Aga see on tehtud huvitavaks.

Lisame draamat

Pange tähele, et v2 koodis tuleb arvestada olukordadega, kus laekuvad päringud võivad andmeid muuta. Päringud peegelduvad lihtsalt ja läbipaistvalt, kuid testimise töötlemise meetodi valik jääb teie otsustada – ja see on juba natuke põnev.

Kordame olulist punkti

Tumedat käivitamist koos liikluse peegeldamisega (Dark Launch/Request Mirroring) saab teha, mõjutamata koodi.

Mõtleme selle üle

Aga mis siis, kui peegeldada osa päringutest mitte v1-le, vaid v2-le? Näiteks üks protsent kõigist päringutest või ainult teatud kasutajagruppi päringud. Ja siis, vaadates, kuidas v2 töötab, hakata järk-järgult kõik päringud uuele versioonile üle viima. Või vastupidi, tuua kõik tagasi v1-le, kui v2-l peaks midagi valesti minema. Tundub, et seda nimetatakse kanaride juurutamiseks (Canary Deployment) – termin, mis pärineb kaevandamisest, ja kui sellel oleks vene päritolu, sisaldaks see tõenäoliselt viidet kasplace), ja nüüd vaatame seda lähemalt.

Kanaride juurutamine Istios: lihtsustame juurutamise protsessi

Aeglaselt ja ettevaatlikult

Kanaride juurutamise mudeli põhiolemus on äärmiselt lihtne: uusi tarkvaraversioone (meie puhul - mikroteenust) käivitades anname kõigepealt juurdepääsu sellele väikesele kasutajagrupile. Kui kõik läheb hästi, suurendate aeglaselt seda gruppi kuni selleni, et uus versioon hakkab takerduma, või - kui seda ei juhtu - lõpuks viite iga kasutaja üle sellele. Uue versiooni hoolikas ja järkjärguline juurutamine ning kasutajate sellele üleminekute kontrollimine aitab riskide vähendamiseks ja tagasiside maksimeerimiseks.

Muidugi lihtsustab Istio Canary Deployment'i, pakkudes mitmeid häid valikuid intelligentseks päringute suunamiseks. Ja jah, kõik see on võimalik teha, puudutamata teie algkoodi.

Filtreerime brauserit

Üks lihtsamaid suunamise kriteeriume on suunamine brauseri alusel. Oletame, et soovite, et v2-le suunduksid ainult päringud Safari brauseritest. Nii see käib:

Kohaldame seda suunamisreeglit ja seejärel komandiga curl simuleerime tsüklis reaalseid päringuid mikroteenusele. Nagu screenshot'ilt näha, suunduvad kõik need v1-le:

Aga kus on liiklus v2-le? Kuna meie näites läksid kõik päringud ainult meie käsurealt, siis seda lihtsalt pole. Kuid pöörake tähelepanu ülemistele ridadele ülaltoodud pildil: see on reaktsioon sellele, et sooritasime päringu Safari brauserist, mis andis vastuseks järgmist:

Piiramatu võim

Oleme juba kirjutanud, et regulaarsed väljendid pakuvad väga võimsaid võimalusi päringute suunamiseks. Vaadake järgmist näidet (arvatavasti mõistate ka ise, mida see teeb):

Nüüd on teil tõenäoliselt juba ettekujutus, milleks regulaarsed väljendid suutelised on.

Käitu targalt

Nutikas suunamine, sealhulgas pealkirjade pakettide töötlemine regulaarsete väljenditega, võimaldab liiklust juhtida nii, nagu soovite. Ja see lihtsustab oluliselt uue koodi kasutusele võtmist – see on lihtne, see ei nõua koodi enda muutmist ja vajadusel saab kõik kiiresti tagasi võtta, nagu oli.

Huvitav?

Kas tunnete soovi katsetada Istio, Kubernetes'i ja OpenShift'i oma arvutis? Meeskond Red Hat Developer Team on valmistanud suurepärase õpikule selle teemaga ja avaldanud kõik sellega seotud failid. Nii et edasi, ja ärge tehke endale mingeid piiranguid.
 

Istio Egress: väljapääs suveniiripoest

Kasutades Istio koos Red Hat OpenShift'i ja Kubernetes'iga, saate märkimisväärselt lihtsustada oma elu mikroteenustega. Istio teenuse võrk on peidetud Kubernetes'e pod'idesse, ja teie kood töötab (enamasti) eraldi. Suurus, lihtsus, jälgimine ja muu – kõike seda on lihtne kasutada just sidecar konteinerite rakendamise tõttu. Aga mis juhtub, kui teie mikroteenus peab suhtlema teiste teenustega, mis asuvad teie OpenShift-Kubernetes süsteemist väljas?

Siin aitab meid Istio Egress. Lühidalt öeldes võimaldab see ligipääsu ressurssidele (loe: "teenused"), mis ei kuulu teie Kubernetes'i pod'idesse. Kui täiendavat seadistust ei tehta, siis Istio Egress'i keskkonnas suunatakse liiklus ainult pod'ide klastrite vahel ja nende vahel vastavalt sisestatud IP-tabelitele. See "kastist välja lükkamine" töötab suurepäraselt, kuni vajate ligipääsu välistele teenustele.

Egress võimaldab mööduda eelnevalt mainitud IP-tabelitest kas Egress reeglite põhjal või IP-aadresside vahemike jaoks.

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

(httpbin.org on lihtsalt mugav ressurss väljaminevate teenuspäringute testimiseks.)

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

Või võite avada sama aadressi brauseris:

Nagu näeme, tagastab sealne teenus lihtsalt edastatud päised.

Importimine otse

Nüüd võtame selle teenuse Java koodi, mis on meie süsteemi suhtes väline, ja käivitame selle meie arvutis, kus, meenutame, on Istio. (Saate seda ise teha, minnes meie Istio juhendisse.) Kõivates vastava konteineri ja käivitades selle OpenShift platvormil, kutsub me selle teenuse käsuga curl egresshttpbin-istioegress.$(minishift ip).nip.io, pärast mida näeme ekraanil järgmist:

Oi, mis juhtus? See töötas just. Mis tähendab Not Found? Me just tegime sellele curl.

Laiendame IP-tabeleid kogu internetile

Selle eest võib tänada (või süüdistada) Istio't. Eks ole, Istio on lihtsalt sidecar-konteinerid, mis vastutavad avastamise ja suunamise (ja palju muu eest, millest oleme varasemalt rääkinud). Seetõttu teavad IP-tabelid vaid sellest, mis asub teie klastrite süsteemis. Ent httpbin.org asub väljas ja on seetõttu kättesaamatu. Ja siin tulebki appi Istio Egress – ilma ühegi muudatuseta teie lähtekoodis.

Allpool toodud Egress-reegel sunnib Istio't otsima (vajadusel ka kogu maailmas) vajalikku teenust, antud juhul httpbin.org. Nagu näha sellest failist (egress_httpbin.yml), on funktsionaalsus siin üsna lihtne:

Jääb 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 uuesti käsu curl – ja näeme, et kõik töötab:

Mõtle avatud

Nagu näete, võimaldab Istio korraldada suhtlemist ka välismaailmaga. Teisisõnu, võite endiselt luua OpenShift'i teenuseid ja hallata neid Kubernetes'i kaudu, hoides kõik pod'ides, mis skaleeruvad üles-alla vastavalt vajadusele. Ja samas võite rahulikult pöörduda väliste teenuste poole, mis ei kuulu teie keskkonda. Ja jah, veel kord kordame, et kõike seda saab teha, puudutamata teie koodi.

See oli viimane postitus seerias Istio. Püsige meiega – ees on veel palju huvitavat!

Allikas: habr.com