"Oht on mu keskmine nimi," ütles Austin Powers, rahvusvaheline müsteeriumimees. Kuid see, mida superagentid ja luureteenistused kõrgelt peavad, ei sobi sugugi arvutiteenusteks, kus igavus on palju parem kui oht.
Ja Istio koos OpenShifti ja Kubernetesega muudab mikroteenuste juurutamise tõeliselt igavaks ja etteaimatavaks – ja see on suurepärane. Sellest ja paljust muust räägime Istio sarja neljandas ja viimases postituses.
Kui igavus on õige
Meie puhul tekib tüdimus alles lõppfaasis, kui jääb üle vaid istuda ja protsessi jälgida. Kuid selleks peate kõigepealt kõik konfigureerima ja siin ootab teid palju huvitavat.
Tarkvara uue versiooni juurutamisel tasub kaaluda kõiki võimalusi riskide minimeerimiseks. Paralleelselt töötamine on väga võimas ja end tõestanud viis testimiseks ning Istio võimaldab sul kasutada selleks “salateenust” (oma mikroteenuse peidetud versiooni) ilma tootmissüsteemi segamata. Selle jaoks on isegi spetsiaalne termin - “Dark Launch”, mille omakorda aktiveerib funktsioon, millel on sama spiooninimetus “traffic mirroring”.
Pange tähele, et eelmise lõigu esimeses lauses kasutatakse terminit „juurutamine”, mitte „vabastamine”. Peaksite tõesti saama oma mikroteenust juurutada ja muidugi kasutada nii sageli kui soovite. See teenus peab suutma vastu võtta ja töödelda liiklust, toota tulemusi ning kirjutada logidesse ja jälgida. Kuid samal ajal ei pea seda teenust ise tingimata tootmisse andma. Tarkvara juurutamine ja vabastamine ei ole alati sama asi. Saate juurutada millal soovite, kuid vabastada alles siis, kui olete selleks valmis.
Igavuse organiseerimine on huvitav
Vaadake järgmist Istio marsruutimise reeglit, mis suunab kõik HTTP päringud mikroteenuse soovitusele v1 (kõik näited on võetud ), peegeldades neid samaaegselt soovituse v2 mikroteenusega:
Pöörake tähelepanu märgistusele mirror: ekraani allservas – see määrab liikluse peegeldamise. Jah, see on nii lihtne!
Selle reegli tulemuseks on see, et teie tootmissüsteem (v1) jätkab sissetulevate päringute töötlemist, kuid päringud ise peegeldatakse asünkroonselt versioonile v2, st nende täielikud duplikaadid suunatakse sinna. Nii saate testida versiooni v2 reaalsetes tingimustes – reaalsete andmete ja liikluse peal – ilma tootmissüsteemi tööd kuidagi segamata. Kas see muudab testimise korraldamise igavaks? Jah, kindlasti. Kuid see on tehtud huvitaval viisil.
Lisame draama
Pange tähele, et v2 koodis on vaja ette näha olukorrad, kus sissetulevad päringud võivad põhjustada andmete muutumist. Päringud ise peegelduvad lihtsalt ja läbipaistvalt, kuid töötlusmeetodi valik testis on teie enda otsustada – ja see on pisut murettekitav.
Kordame ühte olulist punkti
Salajast käivitamist liikluse peegeldamisega (Dark Launch/Request Mirroring) saab teostada ilma koodi kuidagi mõjutamata.
Mõtteaine
Mis siis, kui koht, kus päringuid peegeldatakse, saadab osa neist mitte versioonile v1, vaid versioonile v2? Näiteks üks protsent kõigist päringutest või ainult teatud kasutajarühma päringud. Ja siis, vaadates juba v2 toimimist, viige kõik taotlused järk-järgult üle uude versiooni. Või vastupidi, tagastage kõik versioonile v1, kui v2-ga läheb midagi valesti. Ma arvan, et seda nimetatakse Canary Deploymentiks. , ja kui see oleks vene päritolu, sisaldaks see tõenäoliselt viidet ) ja nüüd vaatame seda üksikasjalikumalt.
Kanaari juurutamine Istios: kasutuselevõtu lihtsustamine
Ettevaatlikult ja järk-järgult
Canary Deploymenti juurutusmudeli olemus on äärmiselt lihtne: kui käivitate oma tarkvara uue versiooni (meie puhul mikroteenuse), annate sellele esmalt juurdepääsu väikesele kasutajate rühmale. Kui kõik läheb hästi, suurendate seda rühma aeglaselt, kuni uus versioon hakkab tööle, või kui ei lähe, viige lõpuks kõik kasutajad sinna üle. Uut versiooni läbimõeldult ja järk-järgult tutvustades ning kasutajaid sellele kontrollitult vahetades saate riske vähendada ja tagasisidet maksimeerida.
Loomulikult lihtsustab Istio Canary juurutamist, pakkudes mitmeid häid võimalusi intelligentseks päringu marsruutimiseks. Ja jah, kõike seda saab teha ilma lähtekoodi kuidagi puudutamata.
Brauseri filtreerimine
Üks lihtsamaid marsruutimise kriteeriume on brauseripõhine ümbersuunamine. Oletame, et soovite, et versioonile 2 läheksid ainult Safari brauserite päringud. Seda tehakse järgmiselt.
Rakendame seda marsruutimisreeglit ja seejärel kasutame käsku curl Simuleerime reaalseid taotlusi mikroteenusele tsüklina. Nagu näete ekraanipildil, lähevad need kõik versioonile 1:
Kus on liiklus v2-s? Kuna meie näites tulid kõik päringud ainult meie enda käsurealt, siis seda lihtsalt ei eksisteeri. Kuid pöörake tähelepanu ülaloleva ekraani alumistele ridadele: see on reaktsioon tõsiasjale, et täitsime Safari brauseri päringu, mis omakorda andis selle:
Piiramatu võimsus
Oleme juba kirjutanud, et regulaaravaldised pakuvad väga võimsaid võimalusi taotluste marsruutimiseks. Vaadake järgmist näidet (arvame, et saate aru, mida see teeb):
Nüüdseks on teil tõenäoliselt aimu, mida regulaaravaldised võivad teha.
Käitu targalt
Nutikas marsruutimine, eelkõige regulaaravaldiste abil pakettide päiste töötlemine, võimaldab teil liiklust soovitud viisil juhtida. Ja see lihtsustab oluliselt uue koodi rakendamist - see on lihtne, see ei nõua koodi enda muutmist ja vajadusel saab kõik kiiresti tagasi saata.
Kas olete huvitatud?
Kas soovite oma arvutis katsetada Istio, Kubernetese ja OpenShiftiga? Meeskond valmistas suurepärase sellel teemal ja muutis kõik kaasnevad failid avalikult kättesaadavaks. Nii et mine edasi ja ära keela endale midagi.
Istio Egress: väljuge suveniiripoe kaudu
Kasutades Istiot koos Red Hat OpenShifti ja Kubernetesega, saate oma elu mikroteenustega oluliselt lihtsamaks teha. Istio teenindusvõrk on peidetud Kubernetese kaustadesse ja teie kood töötab (enamasti) isoleeritult. Jõudlus, vahetamise lihtsus, jälgimine jne – kõike seda on lihtne kasutada tänu külgkorvi konteinerite kasutamisele. Aga mis siis, kui teie mikroteenus peab suhtlema teiste teenustega, mis asuvad väljaspool teie OpenShift-Kubernetes süsteemi?
Siin tuleb appi Istio Egress. Lühidalt öeldes võimaldab see lihtsalt juurdepääsu ressurssidele (loe: "teenustele"), mis ei kuulu teie Kubernetese kaunade süsteemi. Kui te lisakonfiguratsiooni ei tee, siis Istio Egressi keskkonnas suunatakse liiklus sisemiste IP-tabelite alusel ainult podide klastri sees ja selliste klastrite vahel. Ja selline nukk töötab suurepäraselt seni, kuni te ei vaja juurdepääsu väljastpoolt tulevatele teenustele.
Väljapääs võimaldab teil ülaltoodud IP-tabelitest mööda minna, kas väljumisreeglite 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 teenusepäringute testimiseks.)
Kui sisestate käsureale curl http://httpbin.org/headers, näeme järgmist:
Või saate sama aadressi avada brauseris:
Nagu näete, tagastab seal asuv teenus lihtsalt talle edastatud päised.
Asendame otsest importi
Võtame nüüd selle teenuse Java-koodi, mis on meie süsteemiväline, ja käivitame selle iseseisvalt, kuhu, meenutagem, on installitud Istio. (Saate seda ise teha, võttes ühendust .) Olles koostanud sobiva pildi ja käivitanud selle OpenShifti platvormil, kutsume seda teenust käsuga curl egresshttpbin-istioegress.$(minishift ip).nip.io, pärast mida näeme ekraanil järgmist:
Oih, mis juhtus? Kõik lihtsalt töötas. Mida tähendab ei leitud? Me tegime seda lihtsalt tema jaoks curl.
IP-tabelite laiendamine kogu Internetile
Istiot tuleks selles süüdistada (või tänada). Lõppude lõpuks on Istio lihtsalt külgkorvi konteinerid, mis vastutavad tuvastamise ja marsruudi (ja paljude muude asjade eest, millest me varem rääkisime) eest. Sel põhjusel teavad IP-tabelid ainult seda, mis on teie klastrisüsteemi sees. Ja httpbin.org asub väljaspool ja seetõttu ligipääsmatu. Ja siin tuleb appi Istio Egress – ilma lähtekoodi vähimagi muudatuseta.
Allolev väljapääsureegel sunnib Istiot otsima (vajadusel siis kogu Internetist) vajalikku teenust, antud juhul httpbin.org. Nagu sellest failist (egress_httpbin.yml) näha, on siinne funktsioon üsna lihtne:
Jääb vaid järgida seda reeglit:
istioctl create -f egress_httpbin.yml -n istioegress
Väljapääsureegleid saab vaadata käsuga istioctl get egressrules:
Ja lõpuks käivitame käsu uuesti Curl – ja me näeme, et kõik töötab:
Me mõtleme avalikult
Nagu näete, võimaldab Istio teil korraldada suhtlemist välismaailmaga. Teisisõnu saate endiselt luua OpenShifti teenuseid ja neid Kubernetese kaudu hallata, hoides kõike kaustades, mis vastavalt vajadusele suurendavad ja vähendavad. Ja samal ajal pääsete turvaliselt juurde oma keskkonnavälistele teenustele. Ja jah, kordame veel kord, et kõike seda saab teha ilma oma koodi kuidagi puudutamata.
See oli Istio sarja viimane postitus. Püsige lainel – ees ootab palju huvitavat!
Allikas: www.habr.com