„Opasnost je moje srednje ime“, govorio je Ostin Pauers, međunarodni misteriozni čovek. Ali ono što visoko cijene super agenti i obavještajne službe nije nimalo prikladno za kompjuterske usluge, gdje je dosada mnogo bolja od opasnosti.
A Istio, zajedno sa OpenShift i Kubernetes, čini implementaciju mikroservisa zaista dosadnim i predvidljivim – i to je sjajno. O ovome i još mnogo toga govorit ćemo u četvrtom i posljednjem postu u seriji Istio.
Kada je dosada prava
U našem slučaju, dosada se javlja tek u završnoj fazi, kada ostaje samo sjediti i gledati proces. Ali za to morate prvo sve konfigurirati, a ovdje vas čeka puno zanimljivih stvari.
Prilikom postavljanja nove verzije vašeg softvera, vrijedi razmotriti sve opcije za minimiziranje rizika. Paralelno pokretanje je vrlo moćan i dokazan način testiranja, a Istio vam omogućava da koristite “tajnu uslugu” (skrivenu verziju vašeg mikroservisa) da to učinite bez uplitanja u proizvodni sistem. Za to postoji čak i poseban izraz - "Dark Launch", koji se zauzvrat aktivira funkcijom s jednako špijunskim nazivom "traffic mirroring".
Imajte na umu da prva rečenica prethodnog paragrafa koristi izraz „raspoređivanje“ umjesto „osloboditi“. Trebali biste zaista biti u mogućnosti da implementirate – i, naravno, koristite – svoju mikrouslugu onoliko često koliko želite. Ova usluga mora biti u stanju da prima i obrađuje promet, proizvodi rezultate, kao i da piše u dnevnike i nadgleda. Ali u isto vrijeme, sama ova usluga ne mora biti puštena u proizvodnju. Postavljanje i izdavanje softvera nisu uvijek ista stvar. Možete se implementirati kad god želite, ali otpustite tek kada ste spremni.
Organiziranje dosade je zanimljivo
Pogledajte sljedeće Istio pravilo rutiranja, koje usmjerava sve HTTP zahtjeve na preporuku mikroservisa v1 (svi primjeri preuzeti iz ), dok ih istovremeno preslikava na mikroservis preporuke v2:
Obratite pažnju na etiketu mirror: na dnu ekrana - to je ono što postavlja zrcaljenje saobraćaja. Da, tako je jednostavno!
Rezultat ovog pravila će biti da će vaš proizvodni sistem (v1) nastaviti da obrađuje dolazne zahtjeve, ali će sami zahtjevi biti asinhrono preslikani na v2, odnosno njihovi kompletni duplikati će ići tamo. Na ovaj način možete testirati v2 u realnim uslovima - na stvarnim podacima i prometu - bez ometanja na bilo koji način u radu proizvodnog sistema. Čini li ovo organiziranje testiranja dosadnim? Da, definitivno. Ali to je urađeno na zanimljiv način.
Dodajmo dramu
Imajte na umu da je u v2 kodu potrebno predvidjeti situacije u kojima dolazni zahtjevi mogu dovesti do promjene podataka. Sami zahtjevi se ogledaju lako i transparentno, ali izbor metode obrade u testu je na vama – i to je pomalo zabrinjavajuće.
Ponovimo jednu važnu tačku
Tajno pokretanje sa preslikavanjem saobraćaja (Dark Launch/Request Mirroring) može se izvesti bez uticaja na kod na bilo koji način.
Hrana za razmisljanje
Šta ako mjesto gdje se preslikavaju zahtjevi pošalje neke od njih ne na v1, već na v2? Na primjer, jedan posto svih zahtjeva ili samo zahtjeva određene grupe korisnika. A onda, već gledajući kako v2 radi, postepeno prenesite sve zahtjeve na novu verziju. Ili obrnuto, vratite sve na v1 ako nešto krene po zlu s v2. Mislim da se zove Canary Deployment. , a da je ruskog porijekla, vjerovatno bi sadržavao referencu na ), a sada ćemo ovo detaljnije pogledati.
Canary implementacija u Istio: pojednostavljenje puštanja u rad
Pažljivo i postepeno
Suština Canary Deployment modela implementacije je krajnje jednostavna: kada pokrenete novu verziju svog softvera (u našem slučaju, mikroservis), prvo mu dajete pristup maloj grupi korisnika. Ako sve prođe kako treba, polako povećavate ovu grupu dok nova verzija ne počne djelovati, ili - ako ne ide - na kraju migrirate sve korisnike na nju. Promišljenim i postupnim uvođenjem nove verzije i prebacivanjem korisnika na nju na kontroliran način, možete smanjiti rizike i maksimizirati povratne informacije.
Naravno, Istio pojednostavljuje Canary Deployment nudeći nekoliko dobrih opcija za inteligentno usmjeravanje zahtjeva. I da, sve ovo se može učiniti bez dodirivanja vašeg izvornog koda na bilo koji način.
Filtriranje pretraživača
Jedan od najjednostavnijih kriterijuma rutiranja je preusmjeravanje zasnovano na pretraživaču. Recimo da želite da samo zahtjevi iz Safari pretraživača idu na v2. Evo kako se to radi:
Primijenimo ovo pravilo rutiranja i onda upotrijebimo naredbu curl Mi ćemo simulirati stvarne zahtjeve mikroservisima u petlji. Kao što možete vidjeti na snimku ekrana, svi idu na v1:
Gdje je promet na v2? Pošto u našem primjeru svi zahtjevi dolaze samo iz naše vlastite komandne linije, ona jednostavno ne postoji. Ali obratite pažnju na donje linije na ekranu iznad: ovo je reakcija na činjenicu da smo izvršili zahtjev iz Safari pretraživača, koji je zauzvrat proizveo ovo:
Neograničena moć
Već smo pisali da regularni izrazi pružaju veoma moćne mogućnosti za usmjeravanje zahtjeva. Pogledajte sljedeći primjer (mislimo da ćete razumjeti šta radi):
Do sada verovatno imate ideju šta regularni izrazi mogu da urade.
Ponašajte se pametno
Pametno usmjeravanje, posebno obrada zaglavlja paketa korištenjem regularnih izraza, omogućava vam da upravljate prometom onako kako želite. A to uvelike pojednostavljuje implementaciju novog koda - jednostavno je, ne zahtijeva promjenu samog koda, a ako je potrebno, sve se brzo može vratiti kako je bilo.
Zainteresovani?
Da li ste željni eksperimentiranja sa Istio, Kubernetes i OpenShift na svom računaru? Tim pripremio odlično na ovu temu i učinio javno dostupnim sve prateće datoteke. Zato samo napred i ne uskraćujte sebi ništa.
Istio Egress: izlaz kroz suvenirnicu
Koristeći Istio zajedno sa Red Hat OpenShift-om i Kubernetes-om, možete sebi olakšati život s mikrouslugama. Istio servisna mreža je skrivena unutar Kubernetes podova, a vaš kod radi (uglavnom) u izolaciji. Performanse, lakoća promjene, praćenje itd. – sve je to jednostavno za korištenje zahvaljujući upotrebi kontejnera s prikolicom. Ali šta ako vaš mikroservis treba da komunicira sa drugim servisima koji se nalaze izvan vašeg OpenShift-Kubernetes sistema?
Ovdje Istio Egress dolazi u pomoć. Ukratko, jednostavno vam omogućava pristup resursima (čitaj: „uslugama“) koji nisu dio vašeg sistema Kubernetes podova. Ako ne izvršite dodatnu konfiguraciju, tada se u Istio Egress okruženju promet usmjerava samo unutar klastera podova i između takvih klastera na osnovu internih IP tablica. I takvo pupiranje funkcionira odlično sve dok vam nije potreban pristup uslugama izvana.
Egress vam omogućava da zaobiđete gore navedene IP tabele, bilo na osnovu Egress pravila ili na nizu IP adresa.
Recimo da imamo Java program koji šalje GET zahtjev na httpbin.org/headers.
(httpbin.org je samo zgodan resurs za testiranje odlaznih zahtjeva za uslugu.)
Ako unesete na komandnoj liniji curl http://httpbin.org/headers, vidjet ćemo sljedeće:
Ili možete otvoriti istu adresu u pretraživaču:
Kao što vidite, usluga koja se tamo nalazi jednostavno vraća zaglavlja koja su joj proslijeđena.
Uvozno zamjenjujemo direktno
Sada uzmimo Java kod ovog servisa, van našeg sistema, i pokrenimo ga sami, gdje je, podsjetimo, instaliran Istio. (To možete učiniti sami kontaktiranjem .) Nakon što smo napravili odgovarajuću sliku i pokrenuli je na OpenShift platformi, pozvaćemo ovaj servis naredbom curl egresshttpbin-istioegress.$(minishift ip).nip.io, nakon čega ćemo vidjeti ovo na ekranu:
Ups, šta se dogodilo? Sve je radilo. Šta znači Nije pronađeno? Samo smo to uradili za njega curl.
Proširivanje IP tabela na cijeli Internet
Istio treba okriviti (ili zahvaliti) za ovo. Na kraju krajeva, Istio su samo bočni kontejneri koji su odgovorni za otkrivanje i usmjeravanje (i puno drugih stvari o kojima smo ranije govorili). Iz tog razloga, IP tabele znaju samo šta je unutar vašeg klaster sistema. A httpbin.org se nalazi vani i stoga je nedostupan. I tu Istio Egress dolazi u pomoć - bez i najmanje promjene u vašem izvornom kodu.
Egress pravilo u nastavku tjera Istio da traži (ako je potrebno, onda na cijelom Internetu) traženu uslugu, u ovom slučaju, httpbin.org. Kao što možete vidjeti iz ove datoteke (egress_httpbin.yml), ovdje je funkcionalnost prilično jednostavna:
Ostaje samo primijeniti ovo pravilo:
istioctl create -f egress_httpbin.yml -n istioegress
Možete pogledati Egress pravila pomoću naredbe istioctl get egressrules:
I konačno, ponovo pokrećemo naredbu curl – i vidimo da sve radi:
Razmišljamo otvoreno
Kao što vidite, Istio vam omogućava da organizirate interakciju s vanjskim svijetom. Drugim riječima, još uvijek možete kreirati OpenShift usluge i upravljati njima putem Kubernetesa, držeći sve u podovima koji se povećavaju i smanjuju prema potrebi. U isto vrijeme, možete bezbedno pristupiti uslugama izvan vašeg okruženja. I da, još jednom ponavljamo da se sve ovo može uraditi bez dodirivanja vašeg koda na bilo koji način.
Ovo je bio posljednji post u nizu na Istio. Ostanite sa nama - čeka vas puno zanimljivih stvari!
izvor: www.habr.com