„Hætta er millinafnið mitt,“ sagði Austin Powers, alþjóðlegur leyndardómsmaður. En það sem er í hávegum höfð af ofurumboðsmönnum og leyniþjónustum hentar alls ekki fyrir tölvuþjónustu þar sem leiðindi eru miklu betri en hættan.
Og Istio, ásamt OpenShift og Kubernetes, gerir uppsetningu örþjónustu sannarlega leiðinlega og fyrirsjáanlega - og það er frábært. Við ræðum þetta og margt fleira í fjórðu og síðustu færslunni í Istio seríunni.
Þegar leiðindi eiga rétt á sér
Í okkar tilviki koma leiðindi aðeins fram á lokastigi, þegar allt sem er eftir er að sitja og fylgjast með ferlinu. En fyrir þetta þarftu að stilla allt fyrst og margt áhugavert bíður þín hér.
Þegar þú setur upp nýja útgáfu af hugbúnaðinum þínum er það þess virði að íhuga alla möguleika til að lágmarka áhættu. Að keyra samhliða er mjög öflug og sannað leið til að prófa og Istio gerir þér kleift að nota „leyniþjónustu“ (falin útgáfa af örþjónustunni þinni) til að gera þetta án þess að trufla framleiðslukerfið. Það er meira að segja sérstakt hugtak fyrir þetta - „Dark Launch“, sem aftur er virkjað með aðgerð með jafn njósnarheiti „umferðarspeglun“.
Vinsamlegast athugaðu að fyrsta setning fyrri málsgreinar notar hugtakið „dreifa“ frekar en „sleppa“. Þú ættir í raun að geta notað – og auðvitað notað – örþjónustuna þína eins oft og þú vilt. Þessi þjónusta verður að geta tekið á móti og unnið úr umferð, framleitt niðurstöður og einnig skrifað í logs og fylgst með. En á sama tíma þarf ekki endilega að gefa þessa þjónustu sjálf út í framleiðslu. Að dreifa og gefa út hugbúnað er ekki alltaf það sama. Þú getur dreift hvenær sem þú vilt, en slepptu því aðeins þegar þú ert tilbúinn.
Að skipuleggja leiðindi er áhugavert
Skoðaðu eftirfarandi Istio leiðarreglu, sem beinir öllum HTTP beiðnum til örþjónusturáðleggingarinnar v1 (öll dæmi tekin frá ), en spegla þær samtímis við meðmæli v2 örþjónustu:
Gefðu gaum að merkimiðanum mirror: neðst á skjánum - það er þetta sem stillir umferðarspeglun. Já, svo einfalt er það!
Niðurstaðan af þessari reglu verður sú að framleiðslukerfið þitt (v1) mun halda áfram að vinna úr beiðnum sem berast, en beiðnirnar sjálfar verða ósamstilltar speglaðar í v2, það er að fullkomnar afrit þeirra fara þangað. Þannig geturðu prófað v2 við raunverulegar aðstæður - á raunverulegum gögnum og umferð - án þess að trufla á nokkurn hátt rekstur framleiðslukerfisins. Gerir þetta leiðinlegt að skipuleggja próf? Já örugglega. En það er gert á áhugaverðan hátt.
Bætum við drama
Vinsamlegast athugið að í v2 kóðanum er nauðsynlegt að gera ráð fyrir aðstæðum þar sem komandi beiðnir geta leitt til gagnabreytinga. Beiðnirnar sjálfar endurspeglast á auðveldan og gagnsæjan hátt, en val á vinnsluaðferð í prófinu er undir þér komið - og þetta er svolítið áhyggjuefni.
Við skulum endurtaka mikilvægt atriði
Leynileg ræsing með umferðarspeglun (Dark Launch/Request Mirroring) er hægt að framkvæma án þess að hafa áhrif á kóðann á nokkurn hátt.
Umhugsunarefni
Hvað ef staðurinn þar sem beiðnir eru speglaðar sendir sumar þeirra ekki í v1, heldur til v2? Til dæmis eitt prósent af öllum beiðnum eða aðeins beiðnum frá ákveðnum hópi notenda. Og þegar þú ert að skoða hvernig v2 virkar, færðu smám saman allar beiðnir yfir í nýju útgáfuna. Eða öfugt, skilaðu öllu í v1 ef eitthvað fer úrskeiðis með v2. Ég held að það sé kallað Canary Deployment. , og ef það væri af rússneskum uppruna myndi það líklega innihalda tilvísun í ), og nú munum við skoða þetta nánar.
Canary Deployment í Istio: einfalda gangsetningu
Varlega og smám saman
Kjarninn í dreifingarlíkaninu Canary Deployment er afar einfalt: þegar þú setur nýja útgáfu af hugbúnaðinum þínum (í okkar tilfelli, örþjónustu), gefurðu fyrst litlum hópi notenda aðgang að honum. Ef allt gengur vel, stækkar þú þennan hóp hægt og rólega þar til nýja útgáfan byrjar að virka, eða - ef hún gerir það ekki - flytur að lokum alla notendur yfir í hana. Með því að kynna nýja útgáfu vandlega og smám saman og skipta yfir notendur yfir í hana á stýrðan hátt geturðu dregið úr áhættu og hámarkað endurgjöf.
Auðvitað, Istio einfaldar Canary Deployment með því að bjóða upp á nokkra góða valkosti fyrir skynsamlega beiðnaleiðingu. Og já, allt þetta er hægt að gera án þess að snerta frumkóðann þinn á nokkurn hátt.
Sía á vafranum
Ein einfaldasta leiðarviðmiðunin er tilvísun sem byggir á vafra. Segjum að þú viljir aðeins beiðnir frá Safari vöfrum um að fara í v2. Svona er það gert:
Við skulum beita þessari leiðarreglu og nota síðan skipunina curl Við munum líkja eftir raunverulegum beiðnum til örþjónustunnar í lykkju. Eins og þú sérð á skjámyndinni fara þeir allir í v1:
Hvar er umferðin á v2? Þar sem í dæminu okkar komu allar beiðnir aðeins frá okkar eigin skipanalínu, þá er það einfaldlega ekki til. En gaum að neðstu línunum á skjánum hér að ofan: þetta er viðbrögð við því að við framkvæmdum beiðni frá Safari vafranum, sem aftur framleiddi þetta:
Ótakmarkað afl
Við höfum þegar skrifað að regluleg tjáning veitir mjög öfluga möguleika til að beina beiðnum. Skoðaðu eftirfarandi dæmi (við teljum að þú skiljir hvað það gerir):
Núna hefur þú líklega hugmynd um hvað regluleg tjáning getur gert.
Gerðu Smart
Snjöll leið, sérstaklega vinnsla pakkahausa með því að nota regluleg segð, gerir þér kleift að stýra umferð eins og þú vilt. Og þetta einfaldar mjög innleiðingu nýs kóða - það er einfalt, það þarf ekki að breyta kóðanum sjálfum og ef nauðsyn krefur er hægt að skila öllu fljótt eins og það var.
Hefur þú áhuga?
Ertu fús til að gera tilraunir með Istio, Kubernetes og OpenShift á tölvunni þinni? Lið undirbúið frábært um þetta efni og gerði allar meðfylgjandi skrár aðgengilegar almenningi. Svo farðu á undan og neitaðu þér ekki um neitt.
Istio Egress: Farið út í gegnum minjagripabúðina
Með því að nota Istio ásamt Red Hat OpenShift og Kubernetes geturðu gert líf þitt með örþjónustu mun auðveldara. Þjónustunet Istio er falið inni í Kubernetes belgjum og kóðinn þinn keyrir (aðallega) í einangrun. Afköst, auðvelt að breyta, rekja o.s.frv. – allt er þetta auðvelt í notkun þökk sé notkun hliðarvagnaíláta. En hvað ef örþjónustan þín þarf að eiga samskipti við aðra þjónustu sem er staðsett utan OpenShift-Kubernetes kerfisins þíns?
Þetta er þar sem Istio Egress kemur til bjargar. Í hnotskurn, það gerir þér einfaldlega kleift að fá aðgang að auðlindum (lesið: „þjónustu“) sem eru ekki hluti af Kubernetes belgkerfinu þínu. Ef þú framkvæmir ekki viðbótarstillingar, þá er umferð í Istio Egress umhverfinu aðeins flutt innan þyrpingar af belgjum og á milli slíkra klasa byggt á innri IP töflum. Og slík púpa virkar frábærlega svo lengi sem þú þarft ekki aðgang að þjónustu að utan.
Egress gerir þér kleift að komast framhjá ofangreindum IP töflum, annað hvort byggðar á Egress reglum eða á ýmsum IP tölum.
Segjum að við höfum Java forrit sem gerir GET beiðni til httpbin.org/headers.
(httpbin.org er bara þægilegt úrræði til að prófa sendar þjónustubeiðnir.)
Ef þú slærð inn á skipanalínuna curl http://httpbin.org/headers, við munum sjá eftirfarandi:
Eða þú getur opnað sama heimilisfang í vafranum:
Eins og þú sérð skilar þjónustan sem er þar einfaldlega hausunum sem sendar eru til hennar.
Við erum að skipta út innflutningi
Nú skulum við taka Java kóða þessarar þjónustu, utan kerfisins okkar, og keyra hann á eigin spýtur, þar sem, manstu, Istio er uppsett. (Þú getur gert þetta sjálfur með því að hafa samband .) Eftir að hafa smíðað viðeigandi mynd og opnað hana á OpenShift pallinum, munum við kalla þessa þjónustu með skipuninni curl egresshttpbin-istioegress.$(minishift ip).nip.io, eftir það munum við sjá þetta á skjánum:
Úps, hvað gerðist? Allt bara virkaði. Hvað þýðir ekki að finna? Við gerðum það bara fyrir hann curl.
Útvíkka IP töflur á allt internetið
Það ætti að kenna (eða þakka) Istio fyrir þetta. Þegar öllu er á botninn hvolft eru Istio bara hliðarvagnagámar sem bera ábyrgð á uppgötvun og leiðsögn (og margt annað sem við ræddum um áðan). Af þessum sökum vita IP töflur aðeins hvað er inni í klasakerfinu þínu. Og httpbin.org er staðsett fyrir utan og því óaðgengilegt. Og þetta er þar sem Istio Egress kemur til bjargar - án minnstu breytinga á frumkóðanum þínum.
Egress reglan hér að neðan neyðir Istio til að leita (ef nauðsyn krefur, þá um allt internetið) að nauðsynlegri þjónustu, í þessu tilviki, httpbin.org. Eins og þú sérð af þessari skrá (egress_httpbin.yml), er virknin hér frekar einföld:
Það eina sem er eftir er að beita þessari reglu:
istioctl create -f egress_httpbin.yml -n istioegress
Þú getur skoðað Egress reglur með skipuninni istioctl get egressrules:
Og að lokum keyrum við skipunina aftur Curl – og við sjáum að allt virkar:
Við hugsum opinskátt
Eins og þú sérð gerir Istio þér kleift að skipuleggja samskipti við umheiminn. Með öðrum orðum, þú getur samt búið til OpenShift þjónustu og stjórnað þeim í gegnum Kubernetes, geymt allt í belg sem skala upp og niður eftir þörfum. Og á sama tíma geturðu örugglega fengið aðgang að þjónustu utan umhverfisins þíns. Og já, við endurtökum enn og aftur að allt þetta er hægt að gera án þess að snerta kóðann þinn á nokkurn hátt.
Þetta var síðasta færslan í seríunni á Istio. Fylgstu með - það er margt áhugavert framundan!
Heimild: www.habr.com