Malhela Lanĉo en Istio: Sekretaj Servoj

"Danĝero estas mia meza nomo," kutimis diri Austin Powers, internacia viro de mistero. Sed tio, kio estas alte estimata de superagentoj kaj spionservoj, tute ne taŭgas por komputilaj servoj, kie enuo estas multe pli bona ol danĝero.

Kaj Istio, kune kun OpenShift kaj Kubernetes, faras la disfaldigon de mikroservoj vere enuiga kaj antaŭvidebla - kaj tio estas bonega. Pri tio kaj multe pli ni parolos en la kvara kaj lasta afiŝo de la serio Istio.

Kiam enuo pravas

En nia kazo, enuo okazas nur en la fina fazo, kiam restas nur sidi kaj rigardi la procezon. Sed por tio vi devas unue agordi ĉion, kaj multaj interesaj aferoj atendas vin ĉi tie.

Kiam vi disvastigas novan version de via programaro, indas konsideri ĉiujn eblojn por minimumigi riskojn. Kuri paralele estas tre potenca kaj pruvita maniero por testi, kaj Istio permesas al vi uzi "sekretan servon" (kaŝita versio de via mikroservo) por fari tion sen malhelpi la produktadsistemon. Estas eĉ speciala termino por ĉi tio - "Malhela Lanĉo", kiu siavice estas aktivigita per funkcio kun same spiona nomo "trafikspegulado".

Bonvolu noti, ke la unua frazo de la antaŭa paragrafo uzas la esprimon "deploji" prefere ol "liberigi". Vi devus vere povi disfaldi—kaj, kompreneble, uzi—vian mikroservon tiel ofte kiel vi volas. Ĉi tiu servo devas povi ricevi kaj prilabori trafikon, produkti rezultojn, kaj ankaŭ skribi al protokoloj kaj monitori. Sed samtempe, ĉi tiu servo mem ne nepre devas esti liberigita en produktadon. Deploji kaj liberigi programaron ne ĉiam estas la sama afero. Vi povas deploji kiam ajn vi volas, sed liberigi nur kiam vi estas preta.

Organizi enuon estas interese

Rigardu la sekvan regulon de vojigo de Istio, kiu direktas ĉiujn HTTP-petojn al la rekomendo de mikroservo v1 (ĉiuj ekzemploj prenitaj de Istio Tutorial GitHub repo), samtempe spegulante ilin al la rekomenda v2 mikroservo:

Atentu la etikedon mirror: ĉe la fundo de la ekrano - estas ĉi tio kiu fiksas trafikan spegulon. Jes, ĝi estas tiel simpla!

La rezulto de ĉi tiu regulo estos, ke via produktadsistemo (v1) daŭre prilaboros envenantajn petojn, sed la petoj mem estos nesinkrone spegulitaj al v2, tio estas, iliaj kompletaj duplikatoj iros tien. Tiel, vi povas testi v2 en realaj kondiĉoj - pri realaj datumoj kaj trafiko - sen ĝeni iel ajn la funkciadon de la produktadsistemo. Ĉu ĉi tio enuigas organizan testadon? Jes, nepre. Sed ĝi estas farita en interesa maniero.

Ni aldonu dramon

Bonvolu noti, ke en la v2-kodo necesas zorgi pri situacioj, kie envenantaj petoj povas kaŭzi datumajn ŝanĝojn. La petoj mem speguliĝas facile kaj travideble, sed la elekto de prilabora metodo en la testo dependas de vi - kaj ĉi tio estas iom maltrankviliga.

Ni ripetu gravan punkton

Sekreta lanĉo kun trafikspegulado (Malhela Lanĉo/Peto Spegulado) povas esti farita sen tuŝi la kodon iel ajn.

Manĝaĵo por pensi

Kio se la loko kie petoj estas spegulitaj sendas kelkajn el ili ne al v1, sed al v2? Ekzemple, unu procento de ĉiuj petoj aŭ nur petoj de certa grupo de uzantoj. Kaj poste, jam rigardante kiel funkcias v2, iom post iom translokigu ĉiujn petojn al la nova versio. Aŭ inverse, redonu ĉion al v1 se io misfunkcias kun v2. Mi pensas, ke ĝi nomiĝas Kanaria Deplojo. reiras al minado, kaj se ĝi estus de rusa origino, ĝi verŝajne enhavus referencon al katoj), kaj nun ni rigardos ĉi tion pli detale.

Kanaria Deplojo en Istio: simpligado de komisiado

Zorge kaj iom post iom

La esenco de la disfalda modelo de Canary Deployment estas ege simpla: kiam vi lanĉas novan version de via programaro (en nia kazo, mikroservo), vi unue donas aliron al ĝi al malgranda grupo de uzantoj. Se ĉio iras bone, vi malrapide pliigas ĉi tiun grupon ĝis la nova versio ekfunkcias, aŭ - se ĝi ne okazas - eventuale migras ĉiujn uzantojn al ĝi. Pripense kaj iom post iom enkondukante novan version kaj ŝanĝante uzantojn al ĝi en kontrolita maniero, vi povas redukti riskojn kaj maksimumigi reagojn.

Kompreneble, Istio simpligas Kanarian Deplojon proponante plurajn bonajn eblojn por inteligenta peto-vojigo. Kaj jes, ĉio ĉi povas esti farita sen tuŝi vian fontkodon iel ajn.

Filtri la retumilon

Unu el la plej simplaj vojkriterioj estas alidirekto bazita en retumilo. Ni diru, ke vi volas, ke nur petoj de Safaraj retumiloj iri al v2. Jen kiel ĝi estas farita:

Ni apliku ĉi tiun vojregulon kaj poste uzu la komandon curl Ni simulos realajn petojn al la mikroservo en buklo. Kiel vi povas vidi en la ekrankopio, ili ĉiuj iras al v1:

Kie estas la trafiko sur v2? Ĉar en nia ekzemplo ĉiuj petoj venis nur de nia propra komandlinio, ĝi simple ne ekzistas. Sed atentu la malsuprajn liniojn en la supra ekrano: ĉi tio estas reago al la fakto, ke ni plenumis peton de la retumilo Safari, kiu siavice produktis ĉi tion:

Senlima potenco

Ni jam skribis, ke regulaj esprimoj provizas tre potencajn kapablojn por direkti petojn. Rigardu la sekvan ekzemplon (ni pensas, ke vi komprenos, kion ĝi faras):

Nun vi verŝajne havas ideon pri tio, kion regulaj esprimoj povas fari.

Agu Smart

Inteligenta vojigo, precipe prilaborado de pakaĵkapoj per regulaj esprimoj, permesas vin stiri trafikon kiel vi volas. Kaj ĉi tio multe simpligas la efektivigon de nova kodo - ĝi estas simpla, ĝi ne postulas ŝanĝi la kodon mem, kaj se necese, ĉio povas esti rapide resendita kiel ĝi estis.

Interesita?

Ĉu vi deziras eksperimenti kun Istio, Kubernetes kaj OpenShift en via komputilo? Teamo Red Hat Developer Team preparis bonegan lernolibro pri ĉi tiu temo kaj disponigis ĉiujn akompanajn dosierojn. Do antaŭeniru kaj nenion rifuzu al vi.
 

Istio Eliro: eliro tra la suvenirbutiko

Uzante Istio kune kun Red Hat OpenShift kaj Kubernetes, vi povas multe plifaciligi vian vivon per mikroservoj. La servomaŝo de Istio estas kaŝita ene de Kubernetes-podoj, kaj via kodo funkcias (plejparte) izole. Efikeco, facileco de ŝanĝo, spurado, ktp. - ĉio ĉi estas facile uzebla danke al la uzo de flankaj ujoj. Sed kio se via mikroservo bezonas komuniki kun aliaj servoj, kiuj troviĝas ekster via OpenShift-Kubernetes-sistemo?

Jen kie Istio Egress venas al la savo. Resume, ĝi simple permesas vin aliri rimedojn (legu: "servoj"), kiuj ne estas parto de via sistemo de Kubernetes-podoj. Se vi ne faras aldonan agordon, tiam en la medio Istio Egress trafiko estas direktita nur ene de areto de podoj kaj inter tiaj aretoj bazitaj sur internaj IP-tabeloj. Kaj tia krizalidiĝo funkcias bonege, kondiĉe ke vi ne bezonas aliron al servoj de ekstere.

Eliro permesas al vi preteriri la suprajn IP-tabelojn, ĉu surbaze de Egress-reguloj aŭ sur gamo da IP-adresoj.

Ni diru, ke ni havas Java-programon, kiu faras GET-peton al httpbin.org/headers.

(httpbin.org estas nur oportuna rimedo por testi eksiĝintajn servajn petojn.)

Se vi eniras sur la komandlinio curl http://httpbin.org/headers, ni vidos la jenon:

Aŭ vi povas malfermi la saman adreson en la retumilo:

Kiel vi povas vidi, la servo situanta tie simple resendas la kapojn pasigitajn al ĝi.

Ni anstataŭas importaĵojn rekte

Nun ni prenu la Java-kodon de ĉi tiu servo, eksteran al nia sistemo, kaj rulu ĝin memstare, kie, memoru, Istio estas instalita. (Vi povas fari tion mem kontaktante nia Istio-lernilo.) Konstruinte la taŭgan bildon kaj lanĉinte ĝin sur la platformo OpenShift, ni nomos ĉi tiun servon per la komando curl egresshttpbin-istioegress.$(minishift ip).nip.io, post kio ni vidos ĉi tion sur la ekrano:

Ho, kio okazis? Ĉio nur funkciis. Kion signifas Ne Trovita? Ni nur faris ĝin por li curl.

Etendante IP-tablojn al la tuta Interreto

Istio devus esti kulpigita (aŭ dankita) pro tio. Post ĉio, Istio estas nur flankaj ujoj, kiuj respondecas pri detekto kaj vojigo (kaj multaj aliaj aferoj, pri kiuj ni parolis antaŭe). Tial, IP-tabeloj nur scias kio estas ene de via clustersistemo. Kaj httpbin.org troviĝas ekstere kaj tial neatingebla. Kaj ĉi tie estas kie Istio Egress venas al la savo - sen la plej eta ŝanĝo al via fontkodo.

La malsupra regulo de Eliro devigas Istio serĉi (se necese, tiam tra la tuta Interreto) la postulatan servon, ĉi-kaze, httpbin.org. Kiel vi povas vidi el ĉi tiu dosiero (egress_httpbin.yml), la funkcio ĉi tie estas sufiĉe simpla:

Restas nur apliki ĉi tiun regulon:

istioctl create -f egress_httpbin.yml -n istioegress

Vi povas vidi Egress-regulojn per la komando istioctl get egressrules:

Kaj finfine, ni rulas la komandon denove buklo – kaj ni vidas, ke ĉio funkcias:

Ni pensas malkaŝe

Kiel vi povas vidi, Istio permesas organizi interagadon kun la ekstera mondo. Alivorte, vi ankoraŭ povas krei OpenShift-servojn kaj administri ilin per Kubernetes, konservante ĉion en podoj, kiuj skalas supren kaj malsupren laŭbezone. Kaj samtempe, vi povas sekure aliri servojn eksterajn al via medio. Kaj jes, ni ripetas denove, ke ĉio ĉi povas esti farita sen tuŝi vian kodon iel ajn.

Ĉi tiu estis la lasta afiŝo en la serio pri Istio. Restu agordita - estas multaj interesaj aferoj antaŭen!

fonto: www.habr.com