“Opasnost je moje srednje ime”, znao je reći Austin Powers, međunarodni tajanstveni čovjek. Ali ono što super agenti i obavještajne službe visoko cijene nije nimalo prikladno za računalne usluge, gdje je dosada puno bolja od opasnosti.
A Istio, zajedno s OpenShiftom i Kubernetesom, čini implementaciju mikroservisa uistinu dosadnom i predvidljivom – i to je sjajno. O ovome i još puno više pričat ćemo u četvrtom i posljednjem postu u serijalu Istio.
Kad je dosada prava
U našem slučaju dosada se javlja tek u završnoj fazi, kada preostaje samo sjediti i promatrati proces. Ali za ovo prvo morate sve konfigurirati, a ovdje vas čeka puno zanimljivih stvari.
Prilikom postavljanja nove verzije softvera, vrijedi razmotriti sve opcije za smanjenje rizika. Paralelno pokretanje vrlo je moćan i provjeren način testiranja, a Istio vam omogućuje korištenje "tajne službe" (skrivene verzije vašeg mikroservisa) da to učinite bez uplitanja u proizvodni sustav. Postoji čak i poseban izraz za to - "Dark Launch", koji se pak aktivira funkcijom podjednako špijunskog naziva "traffic mirroring".
Imajte na umu da se u prvoj rečenici prethodnog odlomka koristi izraz "postaviti", a ne "otpustiti". Trebali biste doista moći implementirati — i, naravno, koristiti — svoju mikrouslugu onoliko često koliko želite. Ova usluga mora biti sposobna primati i obrađivati promet, stvarati rezultate, pisati u zapisnike i nadzirati. Ali u isto vrijeme, sama ova usluga ne mora nužno biti puštena u proizvodnju. Implementacija i puštanje softvera nisu uvijek ista stvar. Možete implementirati kad god želite, ali pustiti tek kada budete spremni.
Organiziranje dosade je zanimljivo
Pogledajte sljedeće Istio pravilo usmjeravanja, koje usmjerava sve HTTP zahtjeve na preporuku mikroservisa v1 (svi primjeri preuzeti iz ), dok ih istovremeno zrcali na mikroservis preporuke v2:
Obratite pozornost na etiketu mirror: na dnu ekrana - to je ono što postavlja zrcaljenje prometa. Da, tako je jednostavno!
Rezultat ovog pravila bit će da će vaš produkcijski sustav (v1) nastaviti obrađivati dolazne zahtjeve, ali će sami zahtjevi biti asinkrono preslikani u v2, odnosno tamo će ići njihovi potpuni duplikati. Na taj način možete testirati v2 u stvarnim uvjetima - na stvarnim podacima i prometu - bez da se na bilo koji način miješate u rad proizvodnog sustava. Čini li ovo organiziranje testiranja dosadnim? Da definitivno. Ali to je napravljeno na zanimljiv način.
Dodajmo dramu
Imajte na umu da je u kodu v2 potrebno predvidjeti situacije u kojima dolazni zahtjevi mogu dovesti do promjene podataka. Sami zahtjevi se lako i transparentno preslikavaju, ali izbor načina obrade u testu je na vama – i to je pomalo zabrinjavajuće.
Ponovimo važnu točku
Tajno pokretanje sa zrcaljenjem prometa (Dark Launch/Request Mirroring) može se izvesti bez utjecaja na kod na bilo koji način.
Hrana za razmišljanje
Što ako mjesto gdje se zahtjevi zrcale ne šalje neke od njih u v1, već u v2? Na primjer, jedan posto svih zahtjeva ili samo zahtjeva određene skupine korisnika. A onda, već gledajući kako v2 radi, postupno prenesite sve zahtjeve na novu verziju. Ili obrnuto, vratite sve na v1 ako nešto pođe po zlu s v2. Mislim da se zove Canary Deployment. , a da je ruskog porijekla, vjerojatno bi sadržavao referencu na ), a sada ćemo to pogledati detaljnije.
Canary implementacija u Istio: pojednostavljeno puštanje u pogon
Pažljivo i postupno
Suština modela implementacije Canary Deploymenta je krajnje jednostavna: kada pokrenete novu verziju svog softvera (u našem slučaju mikroservisa), prvo date pristup maloj grupi korisnika. Ako sve bude u redu, polako povećavate ovu grupu dok nova verzija ne počne djelovati, ili - ako ne počne - eventualno migrirati sve korisnike u nju. Promišljenim i postupnim uvođenjem nove verzije i kontroliranim prebacivanjem korisnika na nju možete smanjiti rizike i povećati povratne informacije.
Naravno, Istio pojednostavljuje Canary Deployment nudeći nekoliko dobrih opcija za inteligentno usmjeravanje zahtjeva. I da, sve se to može učiniti bez diranja vašeg izvornog koda na bilo koji način.
Filtriranje preglednika
Jedan od najjednostavnijih kriterija usmjeravanja je preusmjeravanje temeljeno na pregledniku. Recimo da želite da samo zahtjevi iz Safari preglednika idu na v2. Evo kako se to radi:
Primijenimo ovo pravilo usmjeravanja i zatim upotrijebimo naredbu curl Simulirati ćemo stvarne zahtjeve prema mikroservisu u petlji. Kao što možete vidjeti na snimci zaslona, svi idu na v1:
Gdje je promet na v2? Budući da su u našem primjeru svi zahtjevi dolazili samo iz vlastite naredbene linije, ona jednostavno ne postoji. Ali obratite pozornost na donje retke na gornjem ekranu: ovo je reakcija na činjenicu da smo izvršili zahtjev iz preglednika Safari, koji je proizveo ovo:
Neograničena moć
Već smo napisali da regularni izrazi pružaju vrlo moćne mogućnosti za usmjeravanje zahtjeva. Pogledajte sljedeći primjer (mislimo da ćete razumjeti što radi):
Do sada vjerojatno imate ideju o tome što regularni izrazi mogu učiniti.
Ponašaj se pametno
Pametno usmjeravanje, posebno obrada zaglavlja paketa pomoću regularnih izraza, omogućuje vam usmjeravanje prometa onako kako želite. A to uvelike pojednostavljuje implementaciju novog koda - jednostavno je, ne zahtijeva promjenu samog koda, a ako je potrebno, sve se može brzo vratiti kako je bilo.
Zainteresiran?
Jeste li željni eksperimentiranja s Istiom, Kubernetesom i OpenShiftom na svom računalu? Tim pripremio odličan na ovu temu i sve popratne datoteke učinili javno dostupnima. Zato samo naprijed i ne uskraćujte si ništa.
Istio izlaz: izlaz kroz suvenirnicu
Koristeći Istio zajedno s Red Hat OpenShift i Kubernetes, možete učiniti svoj život s mikroservisima mnogo lakšim. Istiov servisni mesh skriven je unutar Kubernetes podova, a vaš kod radi (uglavnom) izolirano. Performanse, jednostavnost izmjene, praćenje, itd. – sve je to jednostavno za korištenje zahvaljujući korištenju bočnih kontejnera. Ali što ako vaš mikroservis treba komunicirati s drugim servisima koji se nalaze izvan vašeg OpenShift-Kubernetes sustava?
Tu Istio Egress dolazi u pomoć. Ukratko, jednostavno vam omogućuje pristup resursima (čitaj: “uslugama”) koji nisu dio vašeg sustava Kubernetes podova. Ako ne izvršite dodatnu konfiguraciju, tada se u okruženju Istio Egress promet usmjerava samo unutar klastera podova i između takvih klastera na temelju internih IP tablica. I takvo pupiranje radi odlično sve dok vam nije potreban pristup uslugama izvana.
Egress vam omogućuje zaobilaženje gornjih IP tablica, bilo na temelju Egress pravila ili niza IP adresa.
Recimo da imamo Java program koji šalje GET zahtjev na httpbin.org/headers.
(httpbin.org je samo prikladan izvor za testiranje odlaznih zahtjeva za uslugom.)
Ako unesete u naredbeni redak curl http://httpbin.org/headers, vidjet ćemo sljedeće:
Ili možete otvoriti istu adresu u pregledniku:
Kao što vidite, tamo smještena usluga jednostavno vraća zaglavlja koja su joj proslijeđena.
Mi direktno nadomještamo uvoz
Sada uzmimo Java kod ove usluge, izvan našeg sustava, i pokrenimo je sami, gdje je, podsjetimo, instaliran Istio. (To možete učiniti sami kontaktiranjem .) Nakon što smo izgradili odgovarajuću sliku i pokrenuli je na platformi OpenShift, ovu uslugu ćemo pozvati naredbom curl egresshttpbin-istioegress.$(minishift ip).nip.io, nakon čega ćemo vidjeti ovo na ekranu:
Ups, što se dogodilo? Sve je jednostavno radilo. Što znači Nije pronađeno? Upravo smo to učinili za njega curl.
Proširenje IP tablica na cijeli Internet
Za to treba kriviti (ili zahvaliti) Istio. Naposljetku, Istio su samo bočni kontejneri koji su odgovorni za detekciju i usmjeravanje (i puno drugih stvari o kojima smo ranije govorili). Iz tog razloga IP tablice znaju samo ono što je unutar vašeg sustava klastera. A httpbin.org se nalazi vani i stoga je nedostupan. I tu Istio Egress dolazi u pomoć - bez ikakvih promjena u vašem izvornom kodu.
Pravilo Egress u nastavku prisiljava Istio da traži (ako je potrebno, onda po cijelom Internetu) traženu uslugu, u ovom slučaju httpbin.org. Kao što možete vidjeti iz ove datoteke (egress_httpbin.yml), funkcionalnost je ovdje vrlo jednostavna:
Sve što preostaje je primijeniti ovo pravilo:
istioctl create -f egress_httpbin.yml -n istioegress
Pomoću naredbe možete vidjeti Egress pravila istioctl get egressrules:
I na kraju, ponovno pokrećemo naredbu sklupčati – i vidimo da sve radi:
Razmišljamo otvoreno
Kao što vidite, Istio vam omogućuje organiziranje interakcije s vanjskim svijetom. Drugim riječima, i dalje možete stvarati OpenShift usluge i njima upravljati putem Kubernetesa, držeći sve u podovima koji se povećavaju i smanjuju prema potrebi. U isto vrijeme, možete sigurno pristupiti uslugama izvan vašeg okruženja. I da, ponavljamo još jednom da se sve to može učiniti bez diranja vašeg koda na bilo koji način.
Ovo je bio zadnji post u serijalu na Istio. Pratite nas - čeka nas mnogo zanimljivih stvari!
Izvor: www.habr.com