«Opasnost – moje drugo ime», govorio je Austin Powers, čovjek-zagonetka međunarodnog formata. No, ono što je cijenjeno kod superagenta i tajnih službi, nije primjereno za IT sektore, gdje je dosada mnogo bolja od opasnosti.
Istio zajedno s OpenShift i Kubernetes čini implementaciju mikroservisa zaista dosadnom i predvidljivom – i to je sjajno. O tome i još mnogo čemu razgovarat ćemo u četvrtom i posljednjem postu iz serije o Istio.
Kada je dosada – to je u redu
U našem slučaju dosada nastaje samo u završnoj fazi, kada ostaje samo sjediti i promatrati proces. No, za to je potrebno prethodno sve pravilno postaviti, a ovdje vas čeka mnogo zanimljivog.
Prilikom implementacije nove verzije vašeg softvera trebate razmotriti sve mogućnosti minimiziranja rizika. Rad u paralelnom režimu je vrlo moćna i provjerena metoda testiranja, a Istio omogućava korištenje „tajne službe“ (skrivene od očiju javnosti verzije vašeg mikroservisa) bez ometanja rada produkcijskog sustava. Za to postoji čak i poseban termin – „Tajna implementacija“ (Dark Launch), koja se aktivira funkcijom s još tajanstvenijim imenom „mirror traffic“.
Obratite pozornost da se u prvom rečenici prethodnog paragrafa koristi termin „implementacija“ (deploy), a ne „izdavanje“ (release). Zaista biste trebali moći implementirati – i, naravno, koristiti – svoj mikroservis koliko god želite. Ova usluga trebala bi biti sposobna primati i obrađivati promet, pružati rezultate, a također pisati u logove i biti praćena. No, sama usluga nije nužno odobrena za produkciju. Implementacija i izdavanje softvera nisu uvijek isto. Implementaciju možete izvršiti kad god želite, dok je izdavanje moguće samo kada ste konačno spremni.
Organizacija dosade – to je zanimljivo
Pogledajte sljedeće pravilo usmjeravanja Istio, koje usmjerava sve HTTP zahtjeve na mikroservis recommendation v1 (svi primjeri su preuzeti iz ), istovremeno ih zrcaleći na mikroservis recommendation v2:
Obratite pažnju na oznaku mirror: na dnu ekrana – to je ono što postavlja zrcaljenje prometa. Da, tako jednostavno!
Rezultat ovog pravila će biti taj da će vaš produkcijski sustav (v1) i dalje obrađivati dolazne zahtjeve, ali će se zahtjevi asinhrono preslikavati na v2, što znači da će tamo odlaziti njihovi potpuni duplikati. Tako ćete moći testirati rad v2 u stvarnim uvjetima – na pravim podacima i prometu – bez ikakvog ometanja rada produkcijskog sustava. Čini li to organizaciju testiranja dosadnom? Da, svakako. Ali se to radi na zanimljiv način.
Dodajmo drame
Obratite pažnju da u kodu v2 trebate predvidjeti situacije kada dolazni zahtjevi mogu dovesti do promjene podataka. Samo se zahtjevi lako i neprimjetno preslikavaju, ali izbor načina obrade u testnoj verziji ostaje na vama – a to je već pomalo uzbudljivo.
Ponovimo važnu točku
Tajni launch s preslikavanjem prometa (Dark Launch/Request Mirroring) može se izvesti bez ikakvog dodirivanja koda.
Hrana za razmišljanje
A što ako dio zahtjeva koji preslikavate ne šaljete na v1, nego na v2? Na primjer, jedan postotak svih zahtjeva ili samo zahtjeve određene skupine korisnika. A zatim, gledajući kako v2 radi, postupno prebacujete sve zahtjeve na novu verziju. Ili obrnuto, vraćate sve na v1 ako nešto s v2 ne ide kako treba. Čini se da se to zove Canary Deployment ("kanarinsko implementiranje" – termin , i da je imao rusko podrijetlo, vjerojatno bi sadržavao aluziju na ), i za sada ćemo to razmotriti detaljnije.
Canary Deployment u Istio: pojednostavljujemo uvođenje u rad
Pažljivo i postupno
Suština modela Canary Deployment je iznimno jednostavna: kada pokrećete novu verziju svog softvera (u našem slučaju – mikroservisa), prvo omogućavate pristup maloj skupini korisnika. Ako sve ide dobro, polako povećavate tu skupinu sve dok nova verzija ne počne praviti probleme, ili – ako se to ne dogodi – na kraju prebacite sve korisnike na nju. Razrađujući i postupno uvodeći novu verziju, te kontrolirajući prijelaz korisnika, možete smanjiti rizike i maksimizirati povratne informacije.
Naravno, Istio olakšava Canary Deployment nudeći nekoliko dobrih opcija za inteligentno usmjeravanje zahtjeva. I da, sve se to može učiniti bez dodirivanja vašeg izvornih kod.
Filtriramo preglednik
Jedan od najjednostavnijih kriterija usmjeravanja je preusmjeravanje ovisno o pregledniku. Pretpostavimo da želite da na v2 idu samo zahtjevi iz preglednika Safari. Ovako to možete učiniti:
Primijenimo ovo pravilo usmjeravanja, a zatim ćemo tim curl u petlji simulirati stvarne zahtjeve prema mikroservisu. Kao što možete vidjeti na snimci zaslona, svi oni odlaze na v1:
A gdje je promet na v2? Budući da su u našem primjeru svi zahtjevi dolazili samo iz naše komandne linije, jednostavno ga nema. No obratite pažnju na donje retke na snimci iznad: to je odgovor na naš zahtjev iz preglednika Safari, koji je zauzvrat dao ovo:
Neograničena moć
Već smo pisali da regularni izrazi pružaju vrlo moćne mogućnosti za usmjeravanje zahtjeva. Pogledajte sljedeći primjer (mislimo da ćete i sami shvatiti što radi):
Sada vjerojatno već imate predstavu o tome što su sposobni regularni izrazi.
Djelujte pametno
Pametno usmjeravanje, osobito obrada zaglavlja paketa koristeći regularne izraze, omogućava vam da upravljate prometom onako kako želite. I to znatno pojednostavljuje uvođenje novog koda – jednostavno je, ne zahtijeva promjenu samog koda, i po potrebi se sve može brzo vratiti kako je bilo.
Zainteresirani?
Jeste li se uželili eksperimentirati s Istio, Kubernetesom i OpenShiftom na svom računalu? Tim pripremio je odličan o ovoj temi i objavio sve prateće datoteke za javno korištenje. Pa, naprijed, i ne uskraćujte si ništa.
Istio Egress: izlaz kroz suvenirnicu
Primjenom Istio-a zajedno s Red Hat OpenShiftom i Kubernetesom, možete značajno olakšati svoj život s mikroservisima. Servisna mreža Istio je skrivena unutar Kubernetesovih podova, a vaš kod se izvodi (većinom) izolirano. Performanse, jednostavnost promjena, praćenje i ostalo – sve to se lako koristi zahvaljujući primjeni sidecar kontejnera. No, što učiniti ako vaš mikroservis mora komunicirati s drugim servisima koji su izvan vašeg OpenShift-Kubernetes sustava?
Ovdje nastupa Istio Egress. Ukratko, on jednostavno omogućuje pristup resursima (čitaj: 'uslugama') koji nisu unutar vaših Kubernetes podova. Ako ne izvršite dodatne postavke, u Istio Egress okruženju promet se usmjerava samo unutar klastera podova i između takvih klastera na temelju unutarnjih IP tablica. Ovakvo zatvaranje funkcionira savršeno sve dok vam nije potreban pristup vanjskim uslugama.
Egress omogućuje zaobilaženje gore navedenih IP tablica, ili na temelju Egress pravila, ili za raspon IP adresa.
Pretpostavimo da imamo Java program koji izvodi GET zahtjev na httpbin.org/headers.
(httpbin.org je jednostavno zgodan resurs za testiranje odlaznih zahtjeva usluga.)
Ako upišemo u komandnu liniju curl http://httpbin.org/headers, vidjet ćemo sljedeće:
Ili možemo otvoriti istu adresu u pregledniku:
Kao što vidimo, usluga koja se nalazi tamo jednostavno vraća proslijeđene joj zaglavlja.
Import zamjenjujemo na jednostavan način
Sada uzmimo Java kod ove vanjske usluge u odnosu na naš sustav i pokrenimo ga kod nas, gdje, podsjećamo, imamo Istio. (Možete to učiniti sami, pozivajući se na .) Nakon što izgradimo odgovarajući image i pokrenemo ga na OpenShift platformi, pozvat ćemo ovu uslugu naredbom curl egresshttpbin-istioegress.$(minishift ip).nip.io, nakon čega ćemo na ekranu vidjeti ovo:
Što se dogodilo? Sve je radilo doslovno prije trenutka. Što znači Not Found? Pa, sada smo upravo napravili za njega curl.
Proširujemo IP tablice na cijeli internet
Kriviti (ili zahvaliti) za to treba Istio. Jer Istio su jednostavno sidecar kontejneri, koji se brinu za otkrivanje i usmjeravanje (i još mnogo drugih stvari o kojima smo ranije pričali). Iz tog razloga IP tablice znaju samo o onome što se nalazi unutar vaših klastera. A httpbin.org je smješten vani i stoga nije dostupan. I tu nastupa Istio Egress – bez ikakvih promjena u vašem izvornoj kodu.
U nastavku se nalazi Egress pravilo koje tjera Istio da traži (ako je potrebno, i u cijelom svijetu internetu) potrebnu uslugu, u ovom slučaju, httpbin.org. Kao što se može vidjeti iz ovog dokumenta (egress_httpbin.yml), funkcionalnost ovdje je prilično jednostavna:
Sada je potrebno samo primijeniti ovo pravilo:
istioctl create -f egress_httpbin.yml -n istioegress
Pravila Egress se mogu pregledati naredbom istioctl get egressrules:
I konačno, opet pokrećemo naredbu curl – i vidimo da sve radi:
Razmišljamo otvoreno
Kao što vidite, Istio omogućava organizaciju interakcije i s vanjskim svijetom. Drugim riječima, još uvijek možete stvarati usluge OpenShift i upravljati njima putem Kubernetesa, držeći sve u podovima koji se skaliraju gore-dolje po potrebi. I pritom se možete slobodno obraćati vanjskim uslugama u odnosu na vaše okruženje. I da, još jednom ponavljamo, sve to možete raditi, a da pritom ne dodirujete svoj kod.
Ovo je bio posljednji post iz serije o Istio. Ostanite s nama – pred nama je mnogo zanimljivog!
Izvor: habr.com
