"Danger is myn middelnamme," sei Austin Powers, in ynternasjonale man fan mystearje. Mar wat troch superaginten en ynljochtingstsjinsten heech oanslein wurdt, is hielendal net geskikt foar kompjûtertsjinsten, dêr't ferfeling folle better is as gefaar.
En Istio, tegearre mei OpenShift en Kubernetes, makket it ynsetten fan mikrotsjinsten wirklik saai en foarsisber - en dat is geweldich. Wy sille prate oer dit en folle mear yn 'e fjirde en lêste post yn' e Istio-searje.
As ferfeling rjocht is
Yn ús gefal komt ferfeling allinich yn 'e lêste faze, as alles wat bliuwt is om te sitten en it proses te sjen. Mar hjirfoar moatte jo earst alles konfigurearje, en hjir wachtsje in protte nijsgjirrige dingen op jo.
By it ynsetten fan in nije ferzje fan jo software, is it wurdich om alle opsjes te beskôgjen foar it minimalisearjen fan risiko's. Parallel rinne is in heul krêftige en bewiisde manier om te testen, en Istio lit jo in "geheime tsjinst" (in ferburgen ferzje fan jo mikrotsjinst) brûke om dit te dwaan sûnder it produksjesysteem te bemuoien. D'r is sels in spesjale term foar dit - "Dark Launch", dy't op syn beurt wurdt aktivearre troch in funksje mei in like spionnamme "traffic mirroring".
Tink derom dat de earste sin fan 'e foarige paragraaf de term "ynset" brûkt ynstee fan "frijlitte". Jo moatte jo mikrotsjinst wirklik kinne ynsette - en, fansels, brûke - sa faak as jo wolle. Dizze tsjinst moat ferkear kinne ûntfange en ferwurkje, resultaten produsearje, en ek skriuwe nei logs en monitor. Mar tagelyk moat dizze tsjinst sels net yn produksje wurde frijlitten. It ynsetten en frijjaan fan software is net altyd itselde. Jo kinne ynsette as jo wolle, mar loslitte allinich as jo klear binne.
It organisearjen fan ferfeling is nijsgjirrich
Sjoch ris nei de folgjende Istio-routingregel, dy't alle HTTP-oanfragen trochstjoert nei de oanbefelling fan mikrotsjinsten v1 (alle foarbylden nommen út ), wylst se tagelyk spegelje nei de oanbefelling v2 microservice:
Jou omtinken oan it label mirror: oan 'e ûnderkant fan it skerm - it is dit dat ferkearsspegeljen ynstelt. Ja, sa ienfâldich is it!
It resultaat fan dizze regel sil wêze dat jo produksjesysteem (v1) trochgiet mei it ferwurkjen fan ynkommende oanfragen, mar de oanfragen sels sille asynchronysk spegele wurde nei v2, dat is, har folsleine duplikaten sille dêr gean. Op dizze manier kinne jo v2 yn echte omstannichheden testen - op echte gegevens en ferkear - sûnder op ien of oare manier te bemuoien mei de wurking fan it produksjesysteem. Makket dit organisearjen fan testen saai? Ja, fansels. Mar it is dien op in nijsgjirrige manier.
Litte wy drama tafoegje
Tink derom dat yn 'e v2-koade it needsaaklik is om te soargjen foar situaasjes wêr't ynkommende oanfragen kinne liede ta gegevenswizigingen. De oanfragen sels wurde maklik en transparant spegele, mar de kar fan ferwurkingsmetoade yn 'e test is oan jo - en dit is in bytsje soargen.
Litte wy in wichtich punt werhelje
Geheime lansearring mei ferkearsspegeljen (Dark Launch / Request Mirroring) kin wurde útfierd sûnder de koade op ien of oare manier te beynfloedzjen.
Om oer nei te tinken
Wat as it plak dêr't fersiken spegele wurde guon fan har net nei v1, mar nei v2 stjoert? Bygelyks, ien persint fan alle oanfragen of allinich oanfragen fan in bepaalde groep brûkers. En dan, al te sjen nei hoe't v2 wurket, stadichoan alle oanfragen oer nei de nije ferzje. Of oarsom, werom alles werom nei v1 as der wat mis giet mei v2. Ik tink dat it hjit Canary Deployment. , en as it fan Russyske komôf wie, soe it wierskynlik in ferwizing nei hawwe ), en no sille wy dit yn mear detail besjen.
Kanaryske ynset yn Istio: ferienfâldigjen fan yntsjinjen
Foarsichtich en stadichoan
De essinsje fan it ynsetmodel fan Canary Deployment is ekstreem ienfâldich: as jo in nije ferzje fan jo software starte (yn ús gefal, in mikrotsjinst), jouwe jo der earst tagong ta oan in lytse groep brûkers. As alles goed giet, ferheegje jo dizze groep stadichoan oant de nije ferzje begjint te hanneljen, of - as it net docht - úteinlik alle brûkers nei it migrearje. Troch yntinsyf en stadichoan in nije ferzje yn te fieren en brûkers dêrop kontrolearre te wikseljen, kinne jo risiko's ferminderje en feedback maksimalisearje.
Fansels, Istio simplifies Canary Deployment troch in oanbod ferskate goede opsjes foar yntelliginte fersyk routing. En ja, dit alles kin dien wurde sûnder jo boarnekoade op ien of oare manier oan te reitsjen.
It filterjen fan de browser
Ien fan 'e ienfâldichste routingkritearia is browser-basearre omlieding. Litte wy sizze dat jo allinich fersiken fan Safari-browsers wolle om nei v2. Hjir is hoe't it dien wurdt:
Litte wy dizze routingregel tapasse en dan it kommando brûke curl Wy sille wirklike oanfragen nei de mikrotsjinst simulearje yn in lus. Lykas jo kinne sjen yn 'e skermôfbylding, geane se allegear nei v1:
Wêr is it ferkear op v2? Om't yn ús foarbyld alle oanfragen allinich fan ús eigen kommandorigel kamen, bestiet it gewoan net. Mar betelje omtinken oan de ûnderste rigels yn it skerm hjirboppe: dit is in reaksje op it feit dat wy in fersyk útfierd hawwe fan 'e Safari-blêder, dy't dit op syn beurt produsearre:
Unbeheinde krêft
Wy hawwe al skreaun dat reguliere útdrukkingen heul krêftige mooglikheden leverje foar routing oanfragen. Besjoch it folgjende foarbyld (wy tinke dat jo sille begripe wat it docht):
No hawwe jo wierskynlik in idee fan wat reguliere útdrukkingen kinne dwaan.
Slim hannelje
Smart routing, yn it bysûnder it ferwurkjen fan pakketkoppen mei reguliere útdrukkingen, kinne jo ferkear stjoere sa't jo wolle. En dit simplifies de ymplemintaasje fan nije koade gâns - it is ienfâldich, it is net nedich om de koade sels te feroarjen, en as it nedich is, kin alles fluch weromjûn wurde lykas it wie.
Ynteressearre?
Binne jo entûsjast om te eksperimintearjen mei Istio, Kubernetes en OpenShift op jo kompjûter? Ploech taret in poerbêst oer dit ûnderwerp en makke alle byhearrende bestannen iepenbier beskikber. Dus gean foarút en ûntken dysels neat.
Istio Egress: útgong troch de souvenirwinkel
Troch Istio tegearre mei Red Hat OpenShift en Kubernetes te brûken, kinne jo jo libben mei mikrotsjinsten folle makliker meitsje. Istio's tsjinstmesh is ferburgen yn Kubernetes-pods, en jo koade rint (meast) yn isolemint. Prestaasje, gemak fan feroaring, tracing, ensfh - dit alles is maklik te brûken troch it brûken fan sidecar-konteners. Mar wat as jo mikroservice moat kommunisearje mei oare tsjinsten dy't bûten jo OpenShift-Kubernetes-systeem lizze?
Dit is wêr't Istio Egress komt te rêden. Yn in notedop lit it jo gewoan tagong krije ta boarnen (lês: "tsjinsten") dy't gjin diel útmeitsje fan jo systeem fan Kubernetes-pods. As jo gjin ekstra konfiguraasje útfiere, dan wurdt ferkear yn 'e Istio Egress-omjouwing allinich binnen in kluster fan pods en tusken sokke klusters op basis fan ynterne IP-tabellen trochstjoerd. En sa'n pupaasje wurket geweldich salang't jo gjin tagong hawwe ta tsjinsten fan bûten.
Egress lit jo de boppesteande IP-tabellen omgean, itsij basearre op Egress-regels as op in berik fan IP-adressen.
Litte wy sizze dat wy in Java-programma hawwe dat in GET-fersyk makket oan httpbin.org/headers.
(httpbin.org is gewoan in handige boarne foar it testen fan útgeande tsjinstoanfragen.)
As jo ynfiere op de kommandorigel curl http://httpbin.org/headers, sille wy it folgjende sjen:
Of jo kinne itselde adres iepenje yn 'e browser:
Sa't jo sjen kinne, jout de tsjinst dy't dêr leit gewoan de kopteksten dy't deroan binne trochjûn.
Wy ferfange ymporten frontaal
Litte wy no de Java-koade fan dizze tsjinst nimme, bûten ús systeem, en it op ús eigen útfiere, wêr't, tink derom, Istio is ynstalleare. (Jo kinne dit sels dwaan troch kontakt op te nimmen .) Nei't wy de passende ôfbylding boud hawwe en it op it OpenShift-platfoarm lansearre hawwe, sille wy dizze tsjinst neame mei it kommando curl egresshttpbin-istioegress.$(minishift ip).nip.io, wêrnei't wy dit sille sjen op it skerm:
Oeps, wat is der bard? Alles wurke gewoan. Wat betsjut Net fûn? Wy diene it gewoan foar him curl.
IP-tabellen útwreidzje nei it heule ynternet
Istio moat dêrfoar de skuld (of betanke wurde). Istio is ommers gewoan sidecar-konteners dy't ferantwurdlik binne foar deteksje en rûte (en in protte oare dingen wêr't wy earder oer praat hawwe). Om dizze reden witte IP-tabellen allinich wat yn jo klustersysteem is. En httpbin.org leit bûten en dêrom net tagonklik. En dit is wêr't Istio Egress ta de rêding komt - sûnder de minste feroaring oan jo boarnekoade.
De Egress-regel hjirûnder twingt Istio om te sykjen (as nedich, dan troch it hiele ynternet) nei de fereaske tsjinst, yn dit gefal, httpbin.org. Sa't jo sjen kinne fan dit bestân (egress_httpbin.yml), is de funksjonaliteit hjir frij ienfâldich:
Alles wat oerbliuwt is dizze regel tapasse:
istioctl create -f egress_httpbin.yml -n istioegress
Jo kinne Egress-regels besjen mei it kommando istioctl get egressrules:
En as lêste rinne wy it kommando wer út curl - en wy sjogge dat alles wurket:
Wy tinke iepen
Sa't jo sjen kinne, lit Istio jo ynteraksje organisearje mei de bûtenwrâld. Mei oare wurden, jo kinne noch OpenShift-tsjinsten oanmeitsje en har beheare fia Kubernetes, en bewarje alles yn pods dy't op- en delskaalje as nedich. En tagelyk kinne jo feilich tagong krije ta tsjinsten bûten jo omjouwing. En ja, wy werhelje nochris dat dit alles kin wurde dien sûnder jo koade op ien of oare manier oan te reitsjen.
Dit wie de lêste post yn 'e searje op Istio. Bliuw op 'e hichte - d'r binne in protte nijsgjirrige dingen foarút!
Boarne: www.habr.com