«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 Do t'jemi në një cikël do të imitojmë kërkesat reale ndaj mikroshërbimit. Siç shihet në screenshot, të gjitha ato shkojnë tek 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
