"Vaara on toinen nimeni", Austin Powers, kansainvälinen mysteerimies, tapasi sanoa. Mutta se, mitä superagentit ja tiedustelupalvelut pitävät suuressa arvossa, ei sovellu tietokonepalveluihin, joissa ikävystyminen on paljon parempi kuin vaara.
Ja Istio yhdessä OpenShiftin ja Kubernetesin kanssa tekee mikropalvelujen käyttöönotosta todella tylsää ja ennustettavaa – ja se on hienoa. Puhumme tästä ja paljon muusta Istio-sarjan neljännessä ja viimeisessä postauksessa.
Kun tylsyys on oikein
Meidän tapauksessamme kyllästyminen ilmaantuu vasta loppuvaiheessa, jolloin ei jää muuta kuin istua ja katsella prosessia. Mutta tätä varten sinun on ensin määritettävä kaikki, ja paljon mielenkiintoisia asioita odottaa sinua täällä.
Kun otat käyttöön ohjelmiston uuden version, kannattaa harkita kaikkia vaihtoehtoja riskien minimoimiseksi. Rinnakkainen ajaminen on erittäin tehokas ja todistettu tapa testata, ja Istio antaa sinun käyttää "salaista palvelua" (piilotettu versio mikropalvelustasi) ilman häiriöitä tuotantojärjestelmään. Tälle on jopa erityinen termi - "Dark Launch", joka puolestaan aktivoidaan toiminnolla, jolla on yhtä vakoilunimi "liikennepeilaus".
Huomaa, että edellisen kappaleen ensimmäisessä virkkeessä käytetään termiä "käyttöön" eikä "vapauta". Sinun pitäisi todellakin voida ottaa käyttöön – ja tietysti käyttää – mikropalveluasi niin usein kuin haluat. Tämän palvelun tulee pystyä vastaanottamaan ja prosessoimaan liikennettä, tuottamaan tuloksia sekä kirjoittamaan lokeihin ja valvomaan. Mutta samaan aikaan tätä palvelua ei välttämättä tarvitse päästää tuotantoon. Ohjelmiston käyttöönotto ja julkaiseminen eivät aina ole sama asia. Voit ottaa käyttöön milloin haluat, mutta vapauttaa vasta, kun olet valmis.
Tylsyyden järjestäminen on mielenkiintoista
Tutustu seuraavaan Istion-reitityssääntöön, joka reitittää kaikki HTTP-pyynnöt mikropalvelusuositukseen v1 (kaikki esimerkit otettu ), samalla peilaamalla ne suosituksen v2 mikropalveluun:
Kiinnitä huomiota etikettiin mirror: näytön alareunassa - tämä asettaa liikenteen peilaus. Kyllä, se on niin yksinkertaista!
Tämän säännön seurauksena tuotantojärjestelmäsi (v1) jatkaa saapuvien pyyntöjen käsittelyä, mutta itse pyynnöt peilataan asynkronisesti v2:een, eli niiden täydelliset kaksoiskappaleet menevät sinne. Näin voit testata v2:ta todellisissa olosuhteissa - todellisella tiedolla ja liikenteellä - ilman, että se häiritsee tuotantojärjestelmän toimintaa. Tekeekö tämä testien järjestämisestä tylsää? Kyllä ehdottomasti. Mutta se on tehty mielenkiintoisella tavalla.
Lisätään draamaa
Huomaa, että v2-koodissa on tarpeen varautua tilanteisiin, joissa saapuvat pyynnöt voivat johtaa tietojen muutoksiin. Itse pyynnöt peilataan helposti ja läpinäkyvästi, mutta käsittelytavan valinta testissä on sinun – ja tämä on hieman huolestuttavaa.
Toistetaan tärkeä kohta
Salainen käynnistys liikenteen peilauksella (Dark Launch/Request Mirroring) voidaan suorittaa vaikuttamatta koodiin millään tavalla.
Ajatuksen aihetta
Entä jos pyyntöjen peilauspaikka lähettää osan niistä ei v1:lle vaan v2:lle? Esimerkiksi yksi prosentti kaikista pyynnöistä tai vain tietyn käyttäjäryhmän pyynnöt. Ja sitten, kun tarkastellaan jo v2:n toimintaa, siirrä vähitellen kaikki pyynnöt uuteen versioon. Tai päinvastoin, palauta kaikki v1:een, jos jokin menee pieleen v2:ssa. Luulen, että sitä kutsutaan Canary Deploymentiksi. , ja jos se olisi venäläistä alkuperää, se todennäköisesti sisältäisi viittauksen ), ja nyt tarkastelemme tätä tarkemmin.
Canary Deployment Istiossa: käyttöönoton yksinkertaistaminen
Varovasti ja vähitellen
Canary Deployment -käyttöönottomallin olemus on äärimmäisen yksinkertainen: kun käynnistät ohjelmistosi uuden version (meidän tapauksessamme mikropalvelun), annat ensin pääsyn siihen pienelle käyttäjäryhmälle. Jos kaikki menee hyvin, lisäät tätä ryhmää hitaasti, kunnes uusi versio alkaa toimia, tai jos se ei toimi, siirrät lopulta kaikki käyttäjät siihen. Ottamalla uuden version käyttöön harkitusti ja asteittain ja vaihtamalla käyttäjiä siihen hallitusti, voit vähentää riskejä ja maksimoida palautetta.
Tietenkin Istio yksinkertaistaa Canary Deploymentia tarjoamalla useita hyviä vaihtoehtoja älykkääseen pyyntöjen reitittämiseen. Ja kyllä, kaikki tämä voidaan tehdä koskematta lähdekoodiin millään tavalla.
Selaimen suodatus
Yksi yksinkertaisimmista reitityskriteereistä on selainpohjainen uudelleenohjaus. Oletetaan, että haluat vain Safari-selaimien pyyntöjen siirtyvän versioon 2. Näin se tehdään:
Sovelletaan tätä reitityssääntöä ja sitten komentoa curl Simuloimme todellisia pyyntöjä mikropalveluun silmukassa. Kuten kuvakaappauksesta näet, ne kaikki menevät versioon 1:
Missä on liikenne v2:ssa? Koska esimerkissämme kaikki pyynnöt tulivat vain omalta komentoriviltä, sitä ei yksinkertaisesti ole olemassa. Mutta kiinnitä huomiota yllä olevan näytön riviin: tämä on reaktio siihen, että suoritimme pyynnön Safari-selaimelta, joka puolestaan tuotti tämän:
Rajaton teho
Olemme jo kirjoittaneet, että säännölliset lausekkeet tarjoavat erittäin tehokkaita ominaisuuksia reitityspyyntöihin. Katso seuraavaa esimerkkiä (luulemme sinun ymmärtävän, mitä se tekee):
Tähän mennessä sinulla on luultavasti käsitys siitä, mitä säännölliset lausekkeet voivat tehdä.
Toimi älykkäästi
Älykäs reititys, erityisesti pakettien otsikoiden käsittely säännöllisten lausekkeiden avulla, mahdollistaa liikenteen ohjaamisen haluamallasi tavalla. Ja tämä yksinkertaistaa huomattavasti uuden koodin käyttöönottoa - se on yksinkertaista, se ei vaadi itse koodin muuttamista, ja tarvittaessa kaikki voidaan palauttaa nopeasti sellaisena kuin se oli.
Kiinnostunut?
Oletko innokas kokeilemaan Istiota, Kubernetesia ja OpenShiftiä tietokoneellasi? Tiimi valmistanut erinomaisen tästä aiheesta ja asetti kaikki mukana olevat tiedostot julkisesti saataville. Joten mene eteenpäin äläkä kiellä itseltäsi mitään.
Istio Egress: uloskäynti matkamuistomyymälän kautta
Käyttämällä Istioa yhdessä Red Hat OpenShiftin ja Kubernetesin kanssa voit tehdä elämästäsi mikropalveluiden avulla paljon helpompaa. Istion palveluverkko on piilotettu Kubernetes-koteloiden sisään, ja koodisi toimii (useimmiten) erillään. Suorituskyky, vaihdon helppous, jäljitys jne. – kaikki tämä on helppokäyttöinen sivuvaunukonttien ansiosta. Mutta entä jos mikropalvelusi täytyy kommunikoida muiden OpenShift-Kubernetes-järjestelmän ulkopuolella olevien palvelujen kanssa?
Täällä Istio Egress tulee apuun. Lyhyesti sanottuna sen avulla voit yksinkertaisesti käyttää resursseja (lue: "palveluita"), jotka eivät ole osa Kubernetes pod -järjestelmääsi. Jos et suorita lisämäärityksiä, Istio Egress -ympäristössä liikenne reititetään vain pod-klusterin sisällä ja tällaisten klustereiden välillä sisäisten IP-taulukoiden perusteella. Ja tällainen nukke toimii hyvin niin kauan, kun ei tarvitse pääsyä palveluihin ulkopuolelta.
Egressin avulla voit ohittaa yllä olevat IP-taulukot joko Egress-sääntöjen tai IP-osoitteiden alueen perusteella.
Oletetaan, että meillä on Java-ohjelma, joka lähettää GET-pyynnön osoitteeseen httpbin.org/headers.
(httpbin.org on vain kätevä resurssi lähtevien palvelupyyntöjen testaamiseen.)
Jos kirjoitat komentoriville curl http://httpbin.org/headers, näemme seuraavat asiat:
Tai voit avata saman osoitteen selaimessa:
Kuten näet, siellä sijaitseva palvelu yksinkertaisesti palauttaa sille välitetyt otsikot.
Korvaamme tuontitavaraa
Otetaan nyt tämän palvelun Java-koodi, järjestelmämme ulkopuolinen, ja ajetaan se itse, johon muistaakseni Istio on asennettu. (Voit tehdä tämän itse ottamalla yhteyttä .) Kun olet rakentanut sopivan kuvan ja käynnistänyt sen OpenShift-alustalla, kutsumme tätä palvelua komennolla curl egresshttpbin-istioegress.$(minishift ip).nip.io, jonka jälkeen näemme tämän näytöllä:
Hups, mitä tapahtui? Kaikki vain toimi. Mitä ei löydy tarkoittaa? Teimme sen vain hänen puolestaan curl.
IP-taulukoiden laajentaminen koko Internetiin
Istioa pitäisi syyttää (tai kiittää) tästä. Loppujen lopuksi Istio on vain sivuvaunukontteja, jotka vastaavat havaitsemisesta ja reitityksestä (ja monista muista asioista, joista puhuimme aiemmin). Tästä syystä IP-taulukot tietävät vain, mitä klusterijärjestelmässäsi on. Ja httpbin.org sijaitsee ulkopuolella, joten sinne ei pääse. Ja tässä Istio Egress tulee apuun - ilman pienintäkään muutosta lähdekoodiisi.
Alla oleva poistumissääntö pakottaa Istion etsimään (tarvittaessa koko Internetistä) tarvittavaa palvelua, tässä tapauksessa httpbin.org. Kuten tästä tiedostosta (egress_httpbin.yml) näet, toiminnallisuus on melko yksinkertainen:
Jäljelle jää vain tämän säännön soveltaminen:
istioctl create -f egress_httpbin.yml -n istioegress
Voit tarkastella poistumissääntöjä komennolla istioctl get egressrules:
Ja lopuksi suoritamme komennon uudelleen kiemura – ja näemme, että kaikki toimii:
Ajattelemme avoimesti
Kuten näet, Istion avulla voit järjestää vuorovaikutusta ulkomaailman kanssa. Toisin sanoen voit silti luoda OpenShift-palveluita ja hallita niitä Kubernetesin kautta pitäen kaiken koteloissa, jotka skaalautuvat tarpeen mukaan. Samalla voit turvallisesti käyttää ympäristösi ulkopuolisia palveluita. Ja kyllä, toistamme vielä kerran, että kaikki tämä voidaan tehdä koskematta koodiisi millään tavalla.
Tämä oli sarjan viimeinen viesti Istiossa. Pysy kuulolla – edessä on paljon mielenkiintoista!
Lähde: will.com