"Rreziku është emri im i mesëm," thoshte Austin Powers, një njeri ndërkombëtar misterioz. Por ajo që vlerësohet shumë nga super agjentët dhe shërbimet e inteligjencës nuk është aspak e përshtatshme për shërbimet kompjuterike, ku mërzia është shumë më e mirë se rreziku.
Dhe Istio, së bashku me OpenShift dhe Kubernetes, e bën vendosjen e mikroshërbimeve vërtet të mërzitshme dhe të parashikueshme - dhe kjo është e mrekullueshme. Ne do të flasim për këtë dhe shumë më tepër në postimin e katërt dhe të fundit në serinë Istio.
Kur mërzia është e drejtë
Në rastin tonë, mërzia ndodh vetëm në fazën përfundimtare, kur ajo që mbetet është të ulesh dhe të shikosh procesin. Por për këtë ju duhet së pari të konfiguroni gjithçka, dhe shumë gjëra interesante ju presin këtu.
Kur vendosni një version të ri të softuerit tuaj, ia vlen të merren parasysh të gjitha opsionet për minimizimin e rreziqeve. Vrapimi paralel është një mënyrë shumë e fuqishme dhe e provuar për të testuar, dhe Istio ju lejon të përdorni një "shërbim sekret" (një version i fshehur i mikroshërbimit tuaj) për ta bërë këtë pa ndërhyrë në sistemin e prodhimit. Ekziston edhe një term i veçantë për këtë - "Nisja e errët", e cila nga ana tjetër aktivizohet nga një funksion me një emër po aq spiun "pasqyrimi i trafikut".
Ju lutemi vini re se fjalia e parë e paragrafit të mëparshëm përdor termin "vendosje" në vend të "lëshimit". Ju duhet të jeni vërtet në gjendje të vendosni - dhe, natyrisht, të përdorni - mikroshërbimin tuaj sa herë të dëshironi. Ky shërbim duhet të jetë në gjendje të marrë dhe të përpunojë trafikun, të prodhojë rezultate dhe gjithashtu të shkruajë në regjistrat dhe të monitorojë. Por në të njëjtën kohë, vetë ky shërbim nuk duhet të lëshohet në prodhim. Vendosja dhe lëshimi i softuerit nuk janë gjithmonë e njëjta gjë. Mund të vendosesh sa herë të duash, por lëshojeni vetëm kur të jeni gati.
Organizimi i mërzisë është interesant
Hidhini një sy rregullit të mëposhtëm të rrugëtimit Istio, i cili drejton të gjitha kërkesat HTTP në rekomandimin e mikroservisit v1 (të gjithë shembujt e marrë nga ), duke i pasqyruar njëkohësisht ato me rekomandimin v2 microservice:
Kushtojini vëmendje etiketës mirror: në fund të ekranit - është kjo që vendos pasqyrimin e trafikut. Po, është kaq e thjeshtë!
Rezultati i këtij rregulli do të jetë që sistemi juaj i prodhimit (v1) do të vazhdojë të përpunojë kërkesat hyrëse, por vetë kërkesat do të pasqyrohen në mënyrë asinkrone në v2, domethënë, dublikatat e tyre të plota do të shkojnë atje. Në këtë mënyrë, ju mund të testoni v2 në kushte reale - në të dhëna reale dhe trafik - pa ndërhyrë në asnjë mënyrë në funksionimin e sistemit të prodhimit. A e bën kjo të mërzitshme organizimin e testimit? Po, patjetër. Por është bërë në një mënyrë interesante.
Le të shtojmë dramën
Ju lutemi vini re se në kodin v2 është e nevojshme të parashikohen situata kur kërkesat hyrëse mund të çojnë në ndryshime të të dhënave. Vetë kërkesat pasqyrohen lehtësisht dhe transparente, por zgjedhja e metodës së përpunimit në test varet nga ju - dhe kjo është paksa shqetësuese.
Le të përsërisim një pikë të rëndësishme
Nisja sekrete me pasqyrimin e trafikut (Nisja e errët/Kërkimi i pasqyrimit) mund të kryhet pa ndikuar në asnjë mënyrë kodin.
Ushqim për të menduar
Po sikur vendi ku pasqyrohen kërkesat t'i dërgojë disa prej tyre jo te v1, por te v2? Për shembull, një për qind e të gjitha kërkesave ose vetëm kërkesat nga një grup i caktuar përdoruesish. Dhe më pas, duke parë tashmë se si funksionon v2, transferoni gradualisht të gjitha kërkesat në versionin e ri. Ose anasjelltas, ktheni gjithçka në v1 nëse diçka nuk shkon me v2. Unë mendoj se quhet vendosja e Kanarit. , dhe nëse do të ishte me origjinë ruse, ndoshta do të përmbante një referencë për të ), dhe tani do ta shikojmë këtë në më shumë detaje.
Vendosja e Kanarinave në Istio: thjeshtimi i komisionimit
Me kujdes dhe gradualisht
Thelbi i modelit të vendosjes së Canary Deployment është jashtëzakonisht i thjeshtë: kur lëshoni një version të ri të softuerit tuaj (në rastin tonë, një mikroshërbim), së pari i jepni akses në të një grupi të vogël përdoruesish. Nëse gjithçka shkon mirë, ju e rritni ngadalë këtë grup derisa versioni i ri të fillojë të funksionojë, ose - nëse jo - përfundimisht migroni të gjithë përdoruesit tek ai. Duke prezantuar me mend dhe gradualisht një version të ri dhe duke i kaluar përdoruesit tek ai në mënyrë të kontrolluar, ju mund të reduktoni rreziqet dhe të maksimizoni reagimet.
Sigurisht, Istio thjeshton vendosjen e Canary duke ofruar disa opsione të mira për drejtimin inteligjent të kërkesave. Dhe po, e gjithë kjo mund të bëhet pa prekur në asnjë mënyrë kodin tuaj burimor.
Filtrimi i shfletuesit
Një nga kriteret më të thjeshta të rrugëtimit është ridrejtimi i bazuar në shfletues. Le të themi se dëshironi që vetëm kërkesat nga shfletuesit Safari të shkojnë në v2. Ja si bëhet:
Le të zbatojmë këtë rregull të rrugëtimit dhe më pas të përdorim komandën curl Ne do të simulojmë kërkesat reale për mikroshërbimin në një lak. Siç mund ta shihni në pamjen e ekranit, të gjithë shkojnë në v1:
Ku është trafiku në v2? Meqenëse në shembullin tonë të gjitha kërkesat erdhën vetëm nga linja jonë e komandës, ajo thjesht nuk ekziston. Por kushtojini vëmendje vijave të fundit në ekranin e mësipërm: ky është një reagim ndaj faktit që ne ekzekutuam një kërkesë nga shfletuesi Safari, i cili nga ana e tij prodhoi këtë:
Fuqi e pakufizuar
Ne kemi shkruar tashmë se shprehjet e rregullta ofrojnë aftësi shumë të fuqishme për kërkesat e rrugëtimit. Hidhini një sy shembullit të mëposhtëm (mendojmë se do ta kuptoni se çfarë bën):
Deri tani ju ndoshta keni një ide se çfarë mund të bëjnë shprehjet e rregullta.
Vepro i zgjuar
Drejtimi i zgjuar, në veçanti përpunimi i titujve të paketave duke përdorur shprehje të rregullta, ju lejon të drejtoni trafikun ashtu siç dëshironi. Dhe kjo thjeshton shumë zbatimin e kodit të ri - është e thjeshtë, nuk kërkon ndryshimin e vetë kodit, dhe nëse është e nevojshme, gjithçka mund të kthehet shpejt siç ishte.
Të interesuar?
Jeni të etur të eksperimentoni me Istio, Kubernetes dhe OpenShift në kompjuterin tuaj? Ekipi përgatiti një të shkëlqyer për këtë temë dhe i bëri publike të gjitha dosjet shoqëruese. Pra, vazhdoni dhe mos i mohoni asgjë vetes.
Istio Egress: dalje përmes dyqanit të suvenireve
Duke përdorur Istio së bashku me Red Hat OpenShift dhe Kubernetes, ju mund ta bëni jetën tuaj me mikroshërbime shumë më të lehtë. Rrjeta e shërbimit të Istio është e fshehur brenda pods Kubernetes dhe kodi juaj funksionon (kryesisht) i izoluar. Performanca, lehtësia e ndryshimit, gjurmimi, etj. – e gjithë kjo është e lehtë për t'u përdorur falë përdorimit të kontejnerëve të karrigeve anësore. Por, çka nëse mikroshërbimi juaj duhet të komunikojë me shërbime të tjera që ndodhen jashtë sistemit tuaj OpenShift-Kubernetes?
Këtu vjen në ndihmë Istio Egress. Me pak fjalë, thjesht ju lejon të aksesoni burimet (lexo: "shërbimet") që nuk janë pjesë e sistemit tuaj të Kubernetes pods. Nëse nuk kryeni konfigurime shtesë, atëherë në mjedisin Istio Egress trafiku drejtohet vetëm brenda një grupi pods dhe midis grupimeve të tilla bazuar në tabelat e brendshme të IP. Dhe një pupacion i tillë funksionon shkëlqyeshëm për sa kohë që nuk keni nevojë për akses në shërbime nga jashtë.
Egress ju lejon të anashkaloni tabelat e mësipërme IP, ose bazuar në rregullat e Egress ose në një sërë adresash IP.
Le të themi se kemi një program Java që bën një kërkesë GET në httpbin.org/headers.
(httpbin.org është vetëm një burim i përshtatshëm për testimin e kërkesave të shërbimit në dalje.)
Nëse futni në vijën e komandës curl http://httpbin.org/headers, do të shohim sa vijon:
Ose mund të hapni të njëjtën adresë në shfletues:
Siç mund ta shihni, shërbimi i vendosur atje thjesht kthen titujt e kaluar tek ai.
Ne po zëvendësojmë importet kokë më kokë
Tani le të marrim kodin Java të këtij shërbimi, jashtë sistemit tonë, dhe ta ekzekutojmë vetë, ku, kujtojmë, është instaluar Istio. (Këtë mund ta bëni vetë duke kontaktuar .) Pasi të kemi ndërtuar imazhin e duhur dhe ta kemi nisur atë në platformën OpenShift, ne do ta quajmë këtë shërbim me komandën curl egresshttpbin-istioegress.$(minishift ip).nip.io, pas së cilës do ta shohim këtë në ekran:
Oops, çfarë ndodhi? Gjithçka thjesht funksionoi. Çfarë do të thotë Nuk u gjet? Ne thjesht e bëmë atë për të curl.
Zgjerimi i tabelave IP në të gjithë Internetin
Istio duhet fajësuar (ose falënderuar) për këtë. Në fund të fundit, Istio janë vetëm kontejnerë të karrigeve anësore që janë përgjegjës për zbulimin dhe drejtimin (dhe shumë gjëra të tjera për të cilat folëm më herët). Për këtë arsye, tabelat IP dinë vetëm se çfarë është brenda sistemit tuaj të grupimit. Dhe httpbin.org ndodhet jashtë dhe për këtë arsye i paarritshëm. Dhe këtu vjen në shpëtim Istio Egress - pa ndryshimin më të vogël në kodin tuaj burimor.
Rregulli i Egress më poshtë e detyron Istio të kërkojë (nëse është e nevojshme, atëherë në të gjithë Internetin) shërbimin e kërkuar, në këtë rast, httpbin.org. Siç mund ta shihni nga ky skedar (egress_httpbin.yml), funksionaliteti këtu është mjaft i thjeshtë:
Gjithçka që mbetet është të zbatohet ky rregull:
istioctl create -f egress_httpbin.yml -n istioegress
Ju mund të shikoni rregullat e Egress me komandën istioctl get egressrules:
Dhe së fundi, ne ekzekutojmë përsëri komandën përdridhem – dhe ne shohim që gjithçka funksionon:
Ne mendojmë hapur
Siç mund ta shihni, Istio ju lejon të organizoni ndërveprim me botën e jashtme. Me fjalë të tjera, ju ende mund të krijoni shërbime OpenShift dhe t'i menaxhoni ato përmes Kubernetes, duke mbajtur gjithçka në grupe që rriten dhe zvogëlohen sipas nevojës. Dhe në të njëjtën kohë, ju mund të aksesoni në mënyrë të sigurtë shërbimet e jashtme të mjedisit tuaj. Dhe po, ne e përsërisim edhe një herë se e gjithë kjo mund të bëhet pa prekur kodin tuaj në asnjë mënyrë.
Ky ishte postimi i fundit i serialit në Istio. Qëndroni të sintonizuar - ka shumë gjëra interesante përpara!
Burimi: www.habr.com