Dark Launch Istio: noslēpumainās aģentūras

„Briesmas ir mans otrais vārds,” teica Ostins Pauers, starptautiskā mēroga noslēpumains cilvēks. Bet tas, kas ir cienīts superslēpnieku un aģentūru vidū, vien nemaz nav piemērots datoru aģentūrām, jo te garlaicība ir daudz labāka par bīstamību.

Un Istio kopā ar OpenShift un Kubernetes pārvērš mikroservisu izvietošanu par patiesi garlaicīgu un paredzamu procesu – un tas ir lieliski. Par to un vēl daudz ko citu runāsim ceturtajā un pēdējā ierakstā sērijā par Istio.

Kad garlaicība ir pareizi

Mūsu gadījumā garlaicība rodas tikai pēdējā fāzē, kad paliek tikai sēdēt un novērot procesu. Bet tam ir jābūt iepriekš visam sakārtotam, un šeit jūs sagaida daudz interesanta.

Izvietojot jaunu jūsu programmatūras versiju, jāpārdomā visi iespējamie riski. Darbs paralēlajā režīmā ir ļoti spēcīgs un pārbaudīts testēšanas veids, un Istio ļauj izmantot „noslēpumaino aģentūru” (slēptā mikroservisa versija), netraucējot produkcijas sistēmas darbību. Tam pat ir īpašs termins – „Tumšais starts” (Dark Launch), kas savukārt tiek aktivizēts ar funkciju, kurai ir ne mazāk slepens nosaukums – „trafika atspoguļošana”.

Ņemiet vērā, ka iepriekšējā teikumā tiek izmantots termins „izvietošana” (deploy), nevis „laidiens” (release). Jums patiešām jāspēj izvietot – un protams, izmantot – savu mikroservisu tik bieži, cik vēlaties. Šim servisam jābūt spējīgam pieņemt un apstrādāt trafiku, sniegt rezultātus un arī rakstīt žurnālos un tikt uzraudzītam. Bet pats serviss nemaz nav obligāti jālaiž produkcijā. Izvietošana un programmatūras laidiens nav vienmēr viena un tā pati lieta. Izvietošanu varat veikt kad vien vēlaties, bet laišanu – tikai tad, kad esat gatavi.

Garlaicības organizēšana ir interesanti

Iepazīstieties ar nākamo Istio maršrutēšanas noteikumu, kas novirza visus HTTP pieprasījumus uz mikroservisu recommendation v1 (visi piemēri ņemti no Istio Tutorial GitHub repo), vienlaikus atspoguļojot tos uz mikroservisu recommendation v2:

Lūdzu, pievērsiet uzmanību marķējumam mirror: apakšā ekrāna – tieši tā nosaka trafika spoguļošanu. Jā, tik vienkārši!

Šī noteikuma rezultāts būs tas, ka jūsu ražošanas sistēma (v1) turpinās apstrādāt ienākošās pieprasījumus, bet paši pieprasījumi tiks asinkroni spoguļoti uz v2, proti, uz turieni dosies to pilnie dublikāti. Tādējādi jūs varēsiet pārbaudīt v2 darba kārtību reālos apstākļos – uz īstiem datiem un trafiku, – nemainot ražošanas sistēmas darbību. Vai tas padara testēšanas organizāciju garlaicīgu? Jā, noteikti. Bet to var izdarīt interesanti.

Pievienosim drāmu

Ņemiet vērā, ka v2 kodā jāparedz situācijas, kad ienākošie pieprasījumi var izraisīt datu izmaiņas. Paši pieprasījumi spoguļojas viegli un caurspīdīgi, bet veids, kā apstrādāt testēšanā, joprojām ir jūsu ziņā – un tas jau ir nedaudz aizraujoši.

Atgādināsim svarīgo brīdi

Noslēpumaina palaišana ar trafika spoguļošanu (Dark Launch/Request Mirroring) var tikt veikta, neskarot kodu.

Pārtika pārdomām

Ko darīt, ja daļu no pieprasījumiem sūtīt ne uz v1, bet uz v2? Piemēram, viens procents no visiem pieprasījumiem vai tikai pieprasījumi no noteiktas lietotāju grupas. Un pēc tam, skatoties, kā v2 darbojas, pakāpeniski pārvietot visus pieprasījumus uz jauno versiju. Vai tieši pretēji – atgriezt visu atpakaļ uz v1, ja ar v2 kaut kas noiet greizi. Izskatās, ka to sauc par Canary Deployment (‘kanārija izvietošana’ – termins cēlies no kalnrūpniecības, un, ja tam būtu krievu izcelsme, tas, iespējams, saturētu atsauci uz kaķiem), un tagad mēs to apskatīsim sīkāk.

Canary Deployment Istio: atvieglojam ieviešanu

Uzticami un pakāpeniski

Canary Deployment modeļa būtība ir ārkārtīgi vienkārša: palaidot jaunu sava programmatūras versiju (mūsu gadījumā – mikroservisu), pirmkārt, jūs dodat piekļuvi nelielai lietotāju grupai. Ja viss notiek normāli, jūs lēnām palielinat šo grupu, līdz jaunā versija sāk atpalikt, vai – ja tas nenotiek – galu galā pārvietojat uz to visus lietotājus. Pārdomāti un pakāpeniski ieviešot jauno versiju un kontrolējot pāreju uz to, var samazināt riskus un maksimizēt atsauksmes.

Protams, Istio atvieglo Canary Deployment, piedāvājot vairākas labas iespējas inteliģentai pieprasījumu maršrutēšanai. Jā, visu šo var izdarīt, nemainot jūsu avota kodu.

Filtrējam pārlūkprogrammu

Viens no vienkāršākajiem maršrutēšanas kritērijiem ir novirzīšana atkarībā no pārlūkprogrammas. Pieņemsim, ka vēlaties, lai uz v2 tiktu sūtīti tikai pieprasījumi no Safari pārlūkprogrammas. Šeit ir, kā to izdarīt:

Pielietosim šo maršrutēšanas noteikumu un pēc tam ar komandu curl mēs ciklā imitēsim reālus pieprasījumus mikropakalpojumam. Kā redzams ekrānuzņēmumā, visi tie iziet uz v1:

Bet kur ir satiksme uz v2? Tā kā mūsu piemērā visi pieprasījumi nāca tikai no mūsu komandrindas, tad tās vienkārši nav. Bet pievērsiet uzmanību apakšējām rindām iepriekšējā ekrānšāviņā: tas ir atbildes reakcija uz to, ka mēs izpildījām pieprasījumu no Safari pārlūkprogrammas, kas, savukārt, izsniedza šo:

Neierobežota vara

Mēs jau rakstījām, ka regulārie izteikumi sniedz ļoti spēcīgas iespējas pieprasījumu maršrutēšanai. Apskatiet nākamo piemēru (domājam, ka paši sapratīsiet, ko tas dara):

Tagad, iespējams, jūs jau varat iedomāties, uz ko spēj regulārie izteikumi.

Rīkojieties gudri

Viedā maršrutēšana, jo īpaši pakotņu virsrakstu apstrāde, izmantojot regulāros izteikumus, ļauj kontrolēt satiksmi tā, kā jūs vēlaties. Un tas ievērojami atvieglo jauna koda ieviešanu - tas ir viegli, neprasa paša koda izmaiņas, un, ja nepieciešams, visu var ātri atgriezt agrākajā stāvoklī.

Interesē?

Vai esat gatavi eksperimentēt ar Istio, Kubernetes un OpenShift savā datorā? Komanda Red Hat Developer Team ir sagatavojusi lielisku rokasgrāmatu par šo tēmu un ir publicējusi visus atbilstošos failus kopīgā piekļuvē. Tāpēc uz priekšu, un neatteikties no nekā.
 

Istio Egress: izeja caur suvenīru veikalu

Izmantojot Istio kopā ar Red Hat OpenShift un Kubernetes, ir iespējams ievērojami atvieglot darbu ar mikropakalpojumiem. Istio pakalpojumu tīkls ir paslēpts Kubernetes pod'os, bet jūsu kods (galvenokārt) darbojas izolēti. Veiktspēja, vienkārša mainīšana, izsekošana un citas funkcijas ir viegli izmantojamas, pateicoties sidecar konteineriem. Bet ko darīt, ja jūsu mikropakalpojums ir jānosūta pie citiem pakalpojumiem, kas atrodas ārpus jūsu OpenShift-Kubernetes sistēmas?

Šeit palīdz Istio Egress. Ja īsi, tas vienkārši ļauj piekļūt resursiem (domā: "pakalpojumiem"), kuri neietilpst jūsu Kubernetes pod'os. Ja nav veikta papildu konfigurācija, tad Istio Egress vidē satiksme tiek maršrutēta tikai iekšēji starp pod'iem un starp šādiem klasteriem, izmantojot iekšējās IP tabulas. Šāda izolācija ideāli darbojas, līdz jums ir nepieciešama piekļuve ārējiem pakalpojumiem.

Egress ļauj apiet iepriekšminētās IP tabulas, vai nu balstoties uz Egress noteikumiem, vai arī IP adresu diapazonam.

Pieņemsim, ka mums ir Java programma, kas veic GET pieprasījumu uz httpbin.org/headers.

(httpbin.org ir vienkārši ērts resurss, lai testētu izejošos pakalpojumu pieprasījumus.)

Ja komandu rindā ievadām curl http://httpbin.org/headers, mēs redzēsim sekojošo:

Vai arī varam atvērt šo pašu adresi pārlūkā:

Kā redzam, šis pakalpojums vienkārši atgriež nodotos galvenes.

Aizvietojam tieši

Tagad paņemsim Java kodu no šī ārējā pakalpojuma attiecībā uz mūsu sistēmu un palaidīsim to pie sevis, kur, atgādinām, ir ieslēgts Istio. (Jūs varat to izdarīt pats, pievienojoties mūsu Istio apmācībai.) Veicot atbilstoša attēla izveidi un palaidot to uz OpenShift platformas, mēs izsauksim šo pakalpojumu ar komandu curl egresshttpbin-istioegress.$(minishift ip).nip.io, pēc kura ekrānā redzēsim šādus rezultātus:

Oho, kas noticis? Viss taču tikko strādāja. Ko nozīmē Not Found? Mēs taču tikko izveidojām to curl.

Paplašinām IP tabulas visam internetam

Jānorāda (vai arī jāpateicas) par to Istio. Galu galā, Istio ir vienkārši sidecar konteineri, kas atbild par atklāšanu un maršrutēšanu (un daudz ko citu, par ko mēs jau iepriekš runājām). Tāpēc IP tabulas zina tikai to, kas atrodas jūsu klasteru sistēmā. Un httpbin.org atrodas ārpusē un līdz ar to nav pieejams. Šeit palīgā nāk Istio Egress – bez visām izmaiņām jūsu avota kodā.

Zemāk sniegtā Egress noteikums liek Istio meklēt (ja nepieciešams, tad visā pasaules tīmeklī) nepieciešamo servisu, šajā gadījumā httpbin.org. Kā redzams no šī faila (egress_httpbin.yml), funkcionalitāte šeit ir diezgan vienkārša:

Palicis tikai piemērot šo noteikumu:

istioctl create -f egress_httpbin.yml -n istioegress

Pārskatīt Egress noteikumus var ar komandu istioctl get egressrules:

Un beidzot, atkārtoti palaidīsim komandu curl – un redzam, ka viss darbojas:

Domāsim atklāti

Kā redzat, Istio ļauj organizēt mijiedarbību arī ar ārējo pasauli. Citiem vārdiem sakot, jūs varat turpināt veidot OpenShift servisus un pārvaldīt tos caur Kubernetes, saglabājot visu pod’os, kuri paplašinās uz augšu un uz leju pēc vajadzības. Un tajā pašā laikā jūs mierīgi varat piekļūt ārējiem servisiem attiecībā pret jūsu vidi. Un jā, vēlreiz atkārtojam, ka visu to var darīt, nemainot jūsu kodu.

Šis bija pēdējais ieraksts sērijā par Istio. Palieciet ar mums – priekšā daudz interesanta!

Avots: habr.com