«Rreziku – emri im i dytë», thoshte Austin Powers, një njeri mister në një shkallë ndërkombëtare. Por ajo që është e vlerësuar nga superagjentët dhe shërbimet e fshehta, nuk është aspak e përshtatshme për shërbimet kompjuterike, ku monotonia është shumë më e mirë se rreziku.
Dhe Istio së bashku me OpenShift dhe Kubernetes e kthejnë vendosjen e mikroshërbimeve në një proces të vërtetë të mërzitshëm dhe të parashikueshëm – dhe kjo është e shkëlqyer. Rreth kësaj dhe shumë gjërave të tjera do të diskutojmë në postimin e katërt dhe të fundit të serisë mbi Istio.
Kur monotonia është e saktë
Në rastin tonë, monotoninë e krijon vetëm faza përfundimtare, kur mbetet vetëm të ulemi dhe të vëzhgojmë procesin. Por për këtë duhet të konfiguroni gjithçka paraprakisht, dhe këtu ju pret shumë interesante.
Kur merrni parasysh versionin e ri të softuerit tuaj, është e rëndësishme të shqyrtoni të gjitha opsionet për të minimizuar rreziqet. Puna në modalitetin paralel është një mënyrë shumë efektive dhe e provuar për testim, dhe Istio lejon që të angazhohet një "shërbim sekret" (një version i fshehur i shërbimit tuaj mikro) pa ndërhyrë në sistemin e prodhimit. Për këtë ka një term të veçantë – "Nisja e fshehtë" (Dark Launch), e cila aktivizohet nga një funksion me emrin e ndërlikuar "mirrorimi i trafikut".
Kujdesi, se termi "shpërndarje" (deploy) përdoret në fjali e parë të paragrafit të mëparshëm dhe jo "lëshim" (release). Ju duhet të jeni në gjendje të shpërndani dhe, sigurisht, të përdorni mikroshërbimin tuaj sa herë që dëshironi. Ky shërbim duhet të jetë në gjendje të pranojë dhe të procesojë trafik, të japë rezultate, si dhe të shkruajë në protokoll dhe të monitorohet. Por ky shërbim nuk është domosdoshmërish në prodhim. Shpërndarja dhe lëshimi i softuerit nuk janë gjithmonë të njëjtat gjëra. Ju mund të bëni shpërndarjen çdoherë që dëshironi, ndërsa lëshimi vetëm kur jeni plotësisht të gatshëm.
Organizimi i mërzisë është interesant
Shikoni rregullin e mëposhtëm të trajektoreve Istio, i cili drejton të gjitha kërkesat HTTP në mikroshërbimin recommendation v1 (të gjitha shembujt janë marrë nga ), duke i pasqyruar njëkohësisht ato në mikroshërbimin recommendation v2:
Kujdesi për etiketën mirror: poshtë skenës – kjo është ajo që përcakton pasqyrimin e trafikut. Po, është kaq e thjeshtë!
Rezultati i këtij rregulli do të jetë se sistemi juaj i prodhimit (v1) do të vazhdojë të trajtojë kërkesat e pranuara, por ato kërkesa do të pasqyrohen në mënyrë asinkrone në v2, dmth kopjet e plota do t'i dërgohen atje. Kështu, ju do të keni mundësi të testoni funksionimin e v2 në kushte reale – me të dhëna dhe trafik të vërtetë – pa ndikuar në funksionimin e sistemit të prodhimit. A e kthen kjo organizimin e testimit në një monotoninë? Po, padyshim. Por bëhet në një mënyrë interesante.
Shtojmë dramë
Kujdes, në kodin v2 duhet të parashikoni situatat kur kërkesat e pranuara mund të çojnë në ndryshime të të dhënave. Kërkesat vetë pasqyrohen lehtësisht dhe transparencë, por zgjedhja e mënyrës së trajtimit në provë mbetet nën përgjegjësinë tuaj – dhe kjo është paksa emocionuese.
Le të përsërisim një pikë të rëndësishme
Lançimi i fshehtë me pasqyrimin e trafikut (Dark Launch/Request Mirroring) mund të realizohet pa prekur kodin.
Ushqim për mendim
Çfarë nëse vendi për të reflektuar kërkesat të dërgojë një pjesë të tyre jo në v1, por në v2? Për shembull, një përqindje nga të gjitha kërkesat ose vetëm kërkesat nga një grup i caktuar përdoruesish. Dhe pastaj, duke parë si funksionon v2, gradualisht të kalojë në versionin e ri të gjitha kërkesat. Ose përndryshe kthejë gjithçka në v1, nëse diçka shkon keq me v2. Dukesh se kjo quhet Canary Deployment ("kanarejçja e zhvillimit" - një term , dhe sikur të kishte origjinë ruse, do të përmbante ndoshta një referencë për ), dhe tani ne do ta shqyrtojmë këtë më në detaje.
Canary Deployment në Istio: lehtësojmë vendosjen
Me kujdes dhe gradualisht
The essence of the Canary Deployment model is very simple: when launching a new version of your software (in our case, a microservice), you first give access to a small group of users. If everything goes well, you gradually increase this group until the new version starts to falter, or—if that doesn't happen—you ultimately switch all users to it. By thoughtfully and gradually integrating the new version and carefully transitioning users to it, risks can be minimized and feedback maximized.
Of course, Istio simplifies Canary Deployment by offering several good options for intelligent request routing. And yes, all of this can be done without touching your source code.
Filter by browser
One of the simplest routing criteria is redirection based on the browser. Let's say you want only requests from Safari browsers to go to v2. Here’s how it’s done:
We will apply this routing rule and then simulate real requests to the microservice in a loop. As seen in the screenshot, all of them are going to v1: curl будем в цикле имитировать реальные запросы к микросервису. Как видно на скриншоте, все они уходят на v1:
Por ku është trafik për v2? Duke qenë se në shembullin tonë të gjitha kërkesat erdhën vetëm nga linja jonë e komandës, thjesht nuk ka trafik. Por vini re rreshtat e poshtëm në ekranin më sipër: kjo është reagimi ndaj kërkesës që bëmë nga shfletuesi Safari, i cili në të njëjtën kohë bëri këtë:
Fuqi të pakufizuar
Kemi shkruar tashmë se shprehjet rregulluese ofrojnë mundësi shumë të fuqishme për routimin e kërkesave. Shikoni shembullin në vijim (mendojmë se edhe ju e kuptoni se çfarë bën):
Tani, ndoshta tashmë imagjinoni se çfarë janë të afta shprehjet rregulluese.
Veproni me zgjuarsi
Routimi inteligjent, veçanërisht përpunimi i titujve të paketave duke përdorur shprehje rregulluese, ju lejon të menaxhoni trafikun sipas dëshirës tuaj. Dhe kjo e thjeshton shumë vënien në funksion të kodit të ri – është e thjeshtë, nuk kërkon ndryshimin e kodit, dhe, nëse është e nevojshme, gjithçka mund të kthehet shpejt siç ishte.
Interesoheni?
A jeni të gatshëm të eksperimentohet me Istio, Kubernetes dhe OpenShift në kompjuterin tuaj? Ekipi ka përgatitur një për këtë temë dhe publikoi në dispozitë të gjithëve të gjitha skedarët që e shoqërojnë. Kështu që shko përpara dhe mos u ndal.
Istio Egress: dalja përmes dyqanit të suvenirëve
Duke aplikuar Istio së bashku me Red Hat OpenShift dhe Kubernetes, mund ta lehtësoni ndjeshëm jetën tuaj me mikrosherbimet. Rrjeti i shërbimeve Istio është fshehur brenda pod’ave të Kubernetes, dhe kodi juaj ekzekutohet (në thelb) në mënyrë të izoluar. Performanca, lehtësia e ndryshimit, gjurmimi dhe kështu me radhë – të gjitha këto janë të lehta për t'u përdorur pikërisht për shkak të përdorimit të kontejnerëve sidecar. Por çfarë të bëni nëse mikrosherbimi juaj duhet të komunikoj me shërbime të tjera që ndodhen jashtë sistemit tuaj OpenShift-Kubernetes?
Këtu vjen në ndihmë Istio Egress. Nëse e përmbledhim, ai thjesht lejon qasjen në burime (lexo: "shërbime"), të cilat nuk përfshihen në sistemin tuaj të pod’ave Kubernetes. Nëse nuk bëni konfigurim të dukshëm, atëherë në mjedisin Istio Egress trafiku ruterizohet vetëm brenda klasterit të pod’ave dhe midis klasterëve të tillë bazuar në tabelat e brendshme IP. Dhe ky kufizim punon shumë mirë derisa të keni nevojë për qasje në shërbime nga jasht.
Egress lejon të kalojë tabelat IP të përmendura më sipër, si në bazë të rregullave Egress, ashtu dhe për një gamë IP-adresh.
Supozoni se kemi një program Java që bën një kërkesë GET ndaj httpbin.org/headers.
(httpbin.org është një burim i përshtatshëm për testimin e kërkesave të shërbimeve të daljes.)
Nëse shkruani në komandën e linjës curl http://httpbin.org/headers, do të shohim këtë:
Ose mund ta hapim këtë adresë edhe në shfletues:
Siç shohim, shërbimi atje thjesht kthen titujt e dërguar atij.
Zëvendësojmë direkt
Tani, le të marrim kodin Java të këtij shërbimi të jashtëm në raport me sistemin tonë dhe ta ekzekutojmë në vendin tonë, ku, kujtojmë, është Istio. (Mund ta bëni këtë vetë, duke u referuar te .) Pasi të ndërtosh imazhin përkatës dhe ta ekzekutosh atë në platformën OpenShift, do ta thërrasim këtë shërbim me komandën curl egresshttpbin-istioegress.$(minishift ip).nip.io, pas së cilës do të shohim në ekran këtë:
Çfarë ndodhi? Ajo sapo funksionoi. Çfarë do të thotë Not Found? Ne sapo e krijuam për të curl.
Zgjerimi i tabelave IP për të gjithë internetin
Për këtë, duhet të falenderoni (apo fajësoni) Istio. Sepse Istio është thjesht kontejnerë sidecar që janë përgjegjës për zbulimin dhe rrugën (dhe për shumë gjëra të tjera, për të cilat kemi folur më parë). Për këtë arsye, tabelat IP dinë vetëm për atë që ndodhet brenda sistemit tuaj të grupeve. Ndërsa httpbin.org ndodhet jashtë dhe, si rrjedhojë, është i paaksesueshëm. Dhe këtu ndihmon Istio Egress – pa bërë asnjë ndryshim në kodin tuaj burimor.
Rregulli Egress i dhënë më poshtë e bën Istio të kërkojë (nëse është e nevojshme, edhe në gjithë internetin global) shërbimin e nevojshëm, në këtë rast, httpbin.org. Siç shihet nga ky skedar (egress_httpbin.yml), funksionaliteti këtu është mjaft i thjeshtë:
Tani mbetet vetëm të aplikoni këtë rregull:
istioctl create -f egress_httpbin.yml -n istioegress
Mund të shikoni rregullat Egress me komandën istioctl get egressrules:
Dhe për një herë tjetër, e ekzekutojmë komandën curl – dhe shohim se gjithçka funksionon:
Mendoni hapur
Siç e shihni, Istio mundëson organizimin e ndërveprimit edhe me botën e jashtme. Me fjalë të tjera, ju mund të krijoni shërbime OpenShift dhe t'i menaxhoni ato përmes Kubernetes, duke mbajtur gjithçka në pod'e që shkallëzohen lart e poshtë sipas nevojës. Dhe gjithashtu, ju mund të keni qasje në shërbimet e jashtme në lidhje me mjedisin tuaj. Dhe po, le të përsërisim, se e gjithë kjo mund të bëhet pa prekur kodin tuaj.
Ky ishte postimi i fundit në serinë për Istio. Qëndroni me ne – ka shumë interesante përpara!
Burimi: habr.com
