“Perygl yw fy enw canol,” roedd Austin Powers, dyn dirgelwch rhyngwladol, yn ei ddweud. Ond nid yw'r hyn sy'n cael ei barchu'n fawr gan uwch asiantau a gwasanaethau cudd-wybodaeth yn addas o gwbl ar gyfer gwasanaethau cyfrifiadurol, lle mae diflastod yn llawer gwell na pherygl.
Ac mae Istio, ynghyd ag OpenShift a Kubernetes, yn gwneud defnyddio microwasanaethau yn wirioneddol ddiflas a rhagweladwy - ac mae hynny'n wych. Byddwn yn siarad am hyn a llawer mwy yn y pedwerydd post a'r olaf yn y gyfres Istio.
Pan fo diflastod yn iawn
Yn ein hachos ni, dim ond yn y cam olaf y mae diflastod yn digwydd, pan mai'r cyfan sy'n weddill yw eistedd a gwylio'r broses. Ond ar gyfer hyn mae angen i chi ffurfweddu popeth yn gyntaf, ac mae llawer o bethau diddorol yn aros amdanoch chi yma.
Wrth ddefnyddio fersiwn newydd o'ch meddalwedd, mae'n werth ystyried yr holl opsiynau ar gyfer lleihau risgiau. Mae rhedeg ochr yn ochr yn ffordd bwerus a phrofedig iawn o brofi, ac mae Istio yn caniatáu ichi ddefnyddio “gwasanaeth cyfrinachol” (fersiwn cudd o'ch microwasanaeth) i wneud hyn heb ymyrryd â'r system gynhyrchu. Mae hyd yn oed term arbennig ar gyfer hyn - “Lansio Tywyll”, sydd yn ei dro yn cael ei actifadu gan swyddogaeth ag enw yr un mor ysbïwr “drychau traffig”.
Sylwch fod brawddeg gyntaf y paragraff blaenorol yn defnyddio'r term “deploy” yn hytrach na “rhyddhau”. Dylech wir allu defnyddio—ac, wrth gwrs, defnyddio—eich meicrowasanaeth mor aml ag y dymunwch. Rhaid i'r gwasanaeth hwn allu derbyn a phrosesu traffig, cynhyrchu canlyniadau, a hefyd ysgrifennu at logiau a monitro. Ond ar yr un pryd, nid oes rhaid rhyddhau'r gwasanaeth hwn ei hun i gynhyrchu. Nid yw defnyddio a rhyddhau meddalwedd yr un peth bob amser. Gallwch chi ddefnyddio pryd bynnag y dymunwch, ond dim ond pan fyddwch chi'n barod y gallwch chi ei ryddhau.
Mae trefnu diflastod yn ddiddorol
Cymerwch gip ar y rheol llwybro Istio ganlynol, sy'n cyfeirio pob cais HTTP i'r argymhelliad microwasanaeth v1 (pob enghraifft wedi'i chymryd o ), gan eu hadlewyrchu ar yr un pryd i argymhelliad v2 microservice:
Rhowch sylw i'r label mirror: ar waelod y sgrin - dyma sy'n gosod drychau traffig. Ydy, mae mor syml â hynny!
Canlyniad y rheol hon fydd y bydd eich system gynhyrchu (v1) yn parhau i brosesu ceisiadau sy'n dod i mewn, ond bydd y ceisiadau eu hunain yn cael eu hadlewyrchu'n anghydamserol i v2, hynny yw, bydd eu copïau dyblyg cyflawn yn mynd yno. Fel hyn, gallwch chi brofi v2 mewn amodau real - ar ddata a thraffig go iawn - heb ymyrryd mewn unrhyw ffordd â gweithrediad y system gynhyrchu. Ydy hyn yn gwneud trefnu profion yn ddiflas? Ie, yn bendant. Ond mae'n cael ei wneud mewn ffordd ddiddorol.
Gadewch i ni ychwanegu drama
Sylwch fod angen darparu ar gyfer sefyllfaoedd lle gall ceisiadau sy'n dod i mewn arwain at newidiadau data yn y cod v2. Mae'r ceisiadau eu hunain yn cael eu hadlewyrchu'n hawdd ac yn dryloyw, ond chi sy'n dewis y dull prosesu yn y prawf - ac mae hyn ychydig yn peri pryder.
Gadewch i ni ailadrodd pwynt pwysig
Gellir cynnal lansiad cyfrinachol gydag adlewyrchu traffig (Lansio Tywyll / Drych Cais) heb effeithio ar y cod mewn unrhyw ffordd.
Bwyd i feddwl
Beth os yw'r lle y caiff ceisiadau eu hadlewyrchu yn anfon rhai ohonynt nid i v1, ond i v2? Er enghraifft, un y cant o'r holl geisiadau neu geisiadau yn unig gan grŵp penodol o ddefnyddwyr. Ac yna, eisoes yn edrych ar sut mae v2 yn gweithio, trosglwyddwch bob cais yn raddol i'r fersiwn newydd. Neu i'r gwrthwyneb, dychwelwch bopeth i v1 os aiff rhywbeth o'i le ar v2. Rwy'n meddwl ei fod yn cael ei alw'n Canary Deployment. , a phe bai o darddiad Rwsiaidd, mae'n debyg y byddai'n cynnwys cyfeiriad at ), ac yn awr edrychwn ar hyn yn fanylach.
Defnydd Canari yn Istio: symleiddio comisiynu
Yn ofalus ac yn raddol
Mae hanfod model lleoli Canary Deploy yn hynod o syml: pan fyddwch chi'n lansio fersiwn newydd o'ch meddalwedd (yn ein hachos ni, microwasanaeth), rydych chi'n rhoi mynediad iddo i grŵp bach o ddefnyddwyr yn gyntaf. Os aiff popeth yn iawn, byddwch yn cynyddu'r grŵp hwn yn araf nes bod y fersiwn newydd yn dechrau gweithredu, neu - os nad yw - yn mudo pob defnyddiwr iddo yn y pen draw. Trwy gyflwyno fersiwn newydd yn feddylgar ac yn raddol a newid defnyddwyr iddo mewn modd rheoledig, gallwch leihau risgiau a sicrhau'r adborth mwyaf posibl.
Wrth gwrs, mae Istio yn symleiddio'r defnydd o Dedwydd trwy gynnig sawl opsiwn da ar gyfer llwybro ceisiadau deallus. Ac ie, gellir gwneud hyn i gyd heb gyffwrdd â'ch cod ffynhonnell mewn unrhyw ffordd.
Hidlo'r porwr
Un o'r meini prawf llwybro symlaf yw ailgyfeirio ar sail porwr. Gadewch i ni ddweud mai dim ond ceisiadau gan borwyr Safari yr hoffech chi fynd i v2. Dyma sut mae'n cael ei wneud:
Gadewch i ni gymhwyso'r rheol llwybro hon ac yna defnyddio'r gorchymyn curl Byddwn yn efelychu ceisiadau go iawn i'r meicrowasanaeth mewn dolen. Fel y gwelwch yn y sgrin, maen nhw i gyd yn mynd i v1:
Ble mae'r traffig ar v2? Gan mai dim ond o'n llinell orchymyn ein hunain y daeth pob cais yn ein hesiampl, nid yw'n bodoli. Ond rhowch sylw i'r llinellau gwaelod yn y sgrin uchod: mae hwn yn ymateb i'r ffaith ein bod wedi gweithredu cais gan borwr Safari, a gynhyrchodd hwn yn ei dro:
Pŵer diderfyn
Rydym eisoes wedi ysgrifennu bod mynegiadau rheolaidd yn darparu galluoedd pwerus iawn ar gyfer ceisiadau llwybro. Cymerwch olwg ar yr enghraifft ganlynol (rydym yn meddwl y byddwch yn deall beth mae'n ei wneud):
Erbyn hyn mae'n debyg bod gennych chi syniad beth all ymadroddion rheolaidd ei wneud.
Gweithredu'n Glyfar
Mae llwybro clyfar, yn enwedig prosesu penawdau pecynnau gan ddefnyddio mynegiadau rheolaidd, yn caniatáu ichi lywio traffig y ffordd rydych chi ei eisiau. Ac mae hyn yn symleiddio gweithrediad cod newydd yn fawr - mae'n syml, nid oes angen newid y cod ei hun, ac os oes angen, gellir dychwelyd popeth yn gyflym fel yr oedd.
Diddordeb?
Ydych chi'n awyddus i arbrofi gydag Istio, Kubernetes ac OpenShift ar eich cyfrifiadur? Tîm paratoi rhagorol ar y pwnc hwn a sicrhau bod yr holl ffeiliau cysylltiedig ar gael i'r cyhoedd. Felly ewch ymlaen a pheidiwch â gwadu unrhyw beth i chi'ch hun.
Istio Egress: allanfa drwy'r siop gofroddion
Trwy ddefnyddio Istio ynghyd â Red Hat OpenShift a Kubernetes, gallwch wneud eich bywyd gyda microwasanaethau yn llawer haws. Mae rhwyll gwasanaeth Istio wedi'i chuddio y tu mewn i godiau Kubernetes, ac mae'ch cod yn rhedeg (yn bennaf) ar ei ben ei hun. Perfformiad, rhwyddineb newid, olrhain, ac ati - mae hyn i gyd yn hawdd i'w ddefnyddio diolch i ddefnyddio cynwysyddion ceir ochr. Ond beth os oes angen i'ch microwasanaeth gyfathrebu â gwasanaethau eraill sydd wedi'u lleoli y tu allan i'ch system OpenShift-Kubernetes?
Dyma lle mae Istio Egress yn dod i'r adwy. Yn gryno, yn syml, mae'n caniatáu ichi gyrchu adnoddau (darllenwch: “gwasanaethau”) nad ydynt yn rhan o'ch system o godennau Kubernetes. Os na fyddwch chi'n perfformio cyfluniad ychwanegol, yna yn amgylchedd Istio Egress mae traffig yn cael ei gyfeirio o fewn clwstwr o godennau yn unig a rhwng clystyrau o'r fath yn seiliedig ar dablau IP mewnol. Ac mae pupation o'r fath yn gweithio'n wych cyn belled nad oes angen mynediad at wasanaethau o'r tu allan.
Mae Egress yn caniatáu ichi osgoi'r tablau IP uchod, naill ai'n seiliedig ar reolau Egress neu ar ystod o gyfeiriadau IP.
Gadewch i ni ddweud bod gennym raglen Java sy'n gwneud cais GET i httpbin.org/headers.
(Dim ond adnodd cyfleus yw httpbin.org ar gyfer profi ceisiadau gwasanaeth sy’n mynd allan.)
Os rhowch ar y llinell orchymyn curl http://httpbin.org/headers, byddwn yn gweld y canlynol:
Neu gallwch agor yr un cyfeiriad yn y porwr:
Fel y gallwch weld, mae'r gwasanaeth a leolir yno yn syml yn dychwelyd y penawdau a basiwyd iddo.
Mewnforio amnewid yn uniongyrchol
Nawr, gadewch i ni gymryd cod Java y gwasanaeth hwn, y tu allan i'n system, a'i redeg ar ein pennau ein hunain, lle, galw i gof, mae Istio wedi'i osod. (Gallwch wneud hyn eich hun drwy gysylltu â .) Ar ôl adeiladu'r ddelwedd briodol a'i lansio ar y llwyfan OpenShift, byddwn yn galw'r gwasanaeth hwn gyda'r gorchymyn curl egresshttpbin-istioegress.$(minishift ip).nip.io, ac ar ôl hynny byddwn yn gweld hyn ar y sgrin:
Wps, beth ddigwyddodd? Gweithiodd popeth yn unig. Beth mae Not Found yn ei olygu? Rydyn ni newydd wneud hynny iddo curl.
Ymestyn tablau IP i'r Rhyngrwyd cyfan
Dylid beio (neu ddiolch) Istio am hyn. Wedi'r cyfan, dim ond cynwysyddion ceir ochr yw Istio sy'n gyfrifol am ganfod a llwybro (a llawer o bethau eraill y buom yn siarad amdanynt yn gynharach). Am y rheswm hwn, dim ond beth sydd y tu mewn i'ch system glwstwr y mae tablau IP yn ei wybod. Ac mae httpbin.org wedi'i leoli y tu allan ac felly'n anhygyrch. A dyma lle mae Istio Egress yn dod i'r adwy - heb y newid lleiaf i'ch cod ffynhonnell.
Mae'r rheol Egress isod yn gorfodi Istio i chwilio (os oes angen, yna trwy'r Rhyngrwyd gyfan) am y gwasanaeth gofynnol, yn yr achos hwn, httpbin.org. Fel y gallwch weld o'r ffeil hon (egress_httpbin.yml), mae'r swyddogaeth yma yn eithaf syml:
Y cyfan sydd ar ôl yw cymhwyso'r rheol hon:
istioctl create -f egress_httpbin.yml -n istioegress
Gallwch weld rheolau Egress gyda'r gorchymyn istioctl get egressrules:
Ac yn olaf, rydym yn rhedeg y gorchymyn eto cyrlio - a gwelwn fod popeth yn gweithio:
Rydyn ni'n meddwl yn agored
Fel y gwelwch, mae Istio yn caniatáu ichi drefnu rhyngweithio â'r byd y tu allan. Mewn geiriau eraill, gallwch chi barhau i greu gwasanaethau OpenShift a'u rheoli trwy Kubernetes, gan gadw popeth mewn codennau sy'n cynyddu ac i lawr yn ôl yr angen. Ac ar yr un pryd, gallwch gael mynediad diogel at wasanaethau y tu allan i'ch amgylchedd. Ac ie, rydym yn ailadrodd unwaith eto y gellir gwneud hyn i gyd heb gyffwrdd â'ch cod mewn unrhyw ffordd.
Dyma oedd post olaf y gyfres ar Istio. Cadwch diwnio - mae llawer o bethau diddorol o'ch blaen!
Ffynhonnell: hab.com