"Gevaar is my middelnaam," het Austin Powers, 'n internasionale man van misterie, altyd gesê. Maar wat deur superagente en intelligensiedienste hoog geag word, is glad nie geskik vir rekenaardienste nie, waar verveling veel beter as gevaar is.
En Istio, saam met OpenShift en Kubernetes, maak die implementering van mikrodienste werklik vervelig en voorspelbaar - en dit is wonderlik. Ons sal hieroor en nog baie meer praat in die vierde en laaste plasing in die Istio-reeks.
Wanneer verveling reg is
In ons geval kom verveling eers in die finale fase voor, wanneer al wat oorbly is om te sit en kyk na die proses. Maar hiervoor moet u eers alles konfigureer, en hier wag baie interessante dinge op u.
Wanneer u 'n nuwe weergawe van u sagteware ontplooi, is dit die moeite werd om alle opsies te oorweeg om risiko's te verminder. Om parallel te hardloop is 'n baie kragtige en bewese manier om te toets, en Istio laat jou toe om 'n "geheime diens" ('n versteekte weergawe van jou mikrodiens) te gebruik om dit te doen sonder om met die produksiestelsel in te meng. Daar is selfs 'n spesiale term hiervoor - "Dark Launch", wat op sy beurt geaktiveer word deur 'n funksie met 'n ewe spioenasienaam "traffic mirroring".
Neem asseblief kennis dat die eerste sin van die vorige paragraaf die term "ontplooi" eerder as "vrylaat" gebruik. Jy behoort regtig jou mikrodiens te kan ontplooi - en natuurlik gebruik - so dikwels as wat jy wil. Hierdie diens moet in staat wees om verkeer te ontvang en te verwerk, resultate te lewer, en ook na logs te skryf en te monitor. Maar terselfdertyd hoef hierdie diens self nie noodwendig in produksie vrygestel te word nie. Die implementering en vrystelling van sagteware is nie altyd dieselfde ding nie. Jy kan ontplooi wanneer jy wil, maar los net wanneer jy gereed is.
Om verveling te organiseer is interessant
Kyk na die volgende Istio-roeteerreël, wat alle HTTP-versoeke na die mikrodiens-aanbeveling v1 stuur (alle voorbeelde geneem uit ), terwyl dit terselfdertyd weerspieël word na die aanbeveling v2 mikrodiens:
Gee aandag aan die etiket mirror: aan die onderkant van die skerm - dit is dit wat verkeersspieëling stel. Ja, dit is so eenvoudig!
Die resultaat van hierdie reël sal wees dat jou produksiestelsel (v1) sal voortgaan om inkomende versoeke te verwerk, maar die versoeke self sal asynchronies na v2 weerspieël word, dit wil sê, hul volledige duplikate sal daarheen gaan. Op hierdie manier kan jy v2 in werklike toestande toets - op werklike data en verkeer - sonder om op enige manier in te meng met die werking van die produksiestelsel. Maak dit die organisering van toetse vervelig? Ja beslis. Maar dit word op 'n interessante manier gedoen.
Kom ons voeg drama by
Neem asseblief kennis dat dit in die v2-kode nodig is om voorsiening te maak vir situasies waar inkomende versoeke tot dataveranderings kan lei. Die versoeke self word maklik en deursigtig weerspieël, maar die keuse van verwerkingsmetode in die toets is aan jou – en dit is 'n bietjie kommerwekkend.
Kom ons herhaal 'n belangrike punt
Geheime bekendstelling met verkeersspieëling (Dark Launch/Request Mirroring) kan uitgevoer word sonder om die kode op enige manier te beïnvloed.
Iets om aan te herkou
Wat as die plek waar versoeke weerspieël word, sommige van hulle nie na v1 stuur nie, maar na v2? Byvoorbeeld, een persent van alle versoeke of slegs versoeke van 'n sekere groep gebruikers. En dan, al kyk na hoe v2 werk, dra alle versoeke geleidelik oor na die nuwe weergawe. Of andersom, keer alles terug na v1 as iets verkeerd loop met v2. Ek dink dit word Canary Deployment genoem. , en as dit van Russiese oorsprong was, sou dit waarskynlik 'n verwysing na ), en nou sal ons in meer detail hierna kyk.
Kanarie-ontplooiing in Istio: vereenvoudiging van ingebruikneming
Versigtig en geleidelik
Die kern van die Canary Deployment-ontplooiingsmodel is uiters eenvoudig: wanneer jy 'n nuwe weergawe van jou sagteware (in ons geval, 'n mikrodiens) bekendstel, gee jy eers toegang daartoe aan 'n klein groepie gebruikers. As alles goed gaan, verhoog jy hierdie groep stadig totdat die nuwe weergawe begin werk, of - indien nie - uiteindelik alle gebruikers daarheen migreer. Deur bedagsaam en geleidelik 'n nuwe weergawe bekend te stel en gebruikers op 'n beheerde wyse daarna oor te skakel, kan jy risiko's verminder en terugvoer maksimeer.
Natuurlik vereenvoudig Istio Kanarie-ontplooiing deur verskeie goeie opsies vir intelligente versoekroetering aan te bied. En ja, dit alles kan gedoen word sonder om jou bronkode op enige manier aan te raak.
Filtreer die blaaier
Een van die eenvoudigste roetekriteria is blaaiergebaseerde herleiding. Kom ons sê jy wil net versoeke van Safari-blaaiers hê om na v2 te gaan. Hier is hoe dit gedoen word:
Kom ons pas hierdie roetereël toe en gebruik dan die opdrag curl Ons sal werklike versoeke aan die mikrodiens in 'n lus simuleer. Soos u in die skermkiekie kan sien, gaan hulle almal na v1:
Waar is die verkeer op v2? Aangesien in ons voorbeeld alle versoeke slegs van ons eie opdragreël gekom het, bestaan dit eenvoudig nie. Maar let op die onderste reëls in die skerm hierbo: dit is 'n reaksie op die feit dat ons 'n versoek van die Safari-blaaier uitgevoer het, wat op sy beurt dit opgelewer het:
Onbeperkte krag
Ons het reeds geskryf dat gereelde uitdrukkings baie kragtige vermoëns bied vir roeteversoeke. Kyk na die volgende voorbeeld (ons dink jy sal verstaan wat dit doen):
Teen hierdie tyd het jy waarskynlik 'n idee van wat gereelde uitdrukkings kan doen.
Tree slim op
Slim roetering, veral die verwerking van pakkieopskrifte deur gebruik te maak van gereelde uitdrukkings, laat jou toe om verkeer te stuur soos jy wil. En dit vergemaklik die implementering van nuwe kode aansienlik - dit is eenvoudig, dit hoef nie die kode self te verander nie, en indien nodig, kan alles vinnig teruggestuur word soos dit was.
Stel u belang?
Is jy gretig om met Istio, Kubernetes en OpenShift op jou rekenaar te eksperimenteer? Span 'n uitstekende voorberei oor hierdie onderwerp en het al die meegaande lêers publiek beskikbaar gestel. So gaan voort en moenie jouself iets ontsê nie.
Istio Egress: uitgang deur die aandenkingswinkel
Deur Istio saam met Red Hat OpenShift en Kubernetes te gebruik, kan jy jou lewe met mikrodienste baie makliker maak. Istio se diensnetwerk is in Kubernetes-peule versteek, en jou kode loop (meestal) in isolasie. Werkverrigting, gemak van verandering, opsporing, ens. – dit alles is maklik om te gebruik danksy die gebruik van syspanhouers. Maar wat as jou mikrodiens moet kommunikeer met ander dienste wat buite jou OpenShift-Kubernetes-stelsel geleë is?
Dit is waar Istio Egress tot die redding kom. In 'n neutedop, dit laat jou bloot toegang tot hulpbronne (lees: "dienste") wat nie deel van jou stelsel van Kubernetes-peule is nie. As u nie addisionele konfigurasie uitvoer nie, word verkeer in die Istio Egress-omgewing slegs binne 'n groep peule en tussen sulke groepe gelei, gebaseer op interne IP-tabelle. En so verpopping werk uitstekend solank jy nie toegang tot dienste van buite nodig het nie.
Egress laat jou toe om die bogenoemde IP-tabelle te omseil, óf gebaseer op Egress-reëls óf op 'n reeks IP-adresse.
Kom ons sê ons het 'n Java-program wat 'n GET-versoek na httpbin.org/headers rig.
(httpbin.org is net 'n gerieflike hulpbron om uitgaande diensversoeke te toets.)
As jy op die opdragreël invoer curl http://httpbin.org/headers, sal ons die volgende sien:
Of jy kan dieselfde adres in die blaaier oopmaak:
Soos u kan sien, gee die diens wat daar geleë is eenvoudig die opskrifte wat daarheen gestuur is, terug.
Ons vervang invoere reguit
Kom ons neem nou die Java-kode van hierdie diens, buite ons stelsel, en laat dit op ons eie hardloop, waar, onthou, Istio geïnstalleer is. (Jy kan dit self doen deur te kontak .) Nadat ons die toepaslike prent gebou het en dit op die OpenShift-platform geloods het, sal ons hierdie diens bel met die opdrag curl egresshttpbin-istioegress.$(minishift ip).nip.io, waarna ons dit op die skerm sal sien:
Oeps, wat het gebeur? Alles het net gewerk. Wat beteken Nie gevind nie? Ons het dit net vir hom gedoen curl.
Uitbreiding van IP-tabelle na die hele internet
Istio moet hiervoor blameer (of bedank word). Istio is immers net syspanhouers wat verantwoordelik is vir opsporing en roetering (en baie ander dinge waaroor ons vroeër gepraat het). Om hierdie rede weet IP-tabelle net wat binne jou groepstelsel is. En httpbin.org is buite geleë en daarom ontoeganklik. En dit is waar Istio Egress tot die redding kom – sonder die geringste verandering aan jou bronkode.
Die Egress-reël hieronder dwing Istio om te soek (indien nodig, dan deur die hele internet) vir die vereiste diens, in hierdie geval, httpbin.org. Soos u uit hierdie lêer (egress_httpbin.yml) kan sien, is die funksionaliteit hier redelik eenvoudig:
Al wat oorbly is om hierdie reël toe te pas:
istioctl create -f egress_httpbin.yml -n istioegress
U kan Egress-reëls met die opdrag bekyk istioctl get egressrules:
En uiteindelik voer ons die opdrag weer uit krul – en ons sien dat alles werk:
Ons dink openlik
Soos u kan sien, laat Istio u toe om interaksie met die buitewêreld te organiseer. Met ander woorde, jy kan steeds OpenShift-dienste skep en dit deur Kubernetes bestuur, en alles in peule hou wat op en af skaal soos nodig. En terselfdertyd kan jy veilig toegang tot dienste buite jou omgewing verkry. En ja, ons herhaal weer dat dit alles gedoen kan word sonder om jou kode op enige manier aan te raak.
Dit was die laaste plasing in die reeks op Istio. Bly ingeskakel - daar is baie interessante dinge wat voorlê!
Bron: will.com