„Pericolul este al doilea meu nume”, spunea Austin Powers, un om-mister internațional. Dar ceea ce este apreciat de superagenți și servicii secrete nu se potrivește deloc serviciilor informatice, unde plictiseala este de preferat pericolelor.
Și Istio împreună cu OpenShift și Kubernetes transformă desfășurarea microserviciilor într-o activitate într-adevăr plictisitoare și previzibilă – și asta e minunat. Despre acest lucru și multe altele vom discuta în a patra și ultima postare din seria despre Istio.
Când plictiseala este corectă
În cazul nostru, plictiseala apare doar în faza finală, când nu rămâne decât să stai și să observi procesul. Dar pentru asta trebuie totul configurat dinainte, și aici te așteaptă multe lucruri interesante.
Atunci când desfășori o nouă versiune a software-ului tău, ar trebui să iei în considerare toate opțiunile de minimizare a riscurilor. Munca în modul paralel este o metodă foarte puternică și testată de testare, iar Istio îți permite să folosești „serviciul secret” (o versiune a microserviciului tău, ascunsă de ochii curioșilor) fără a afecta funcționarea sistemului de producție. Există chiar un termen special pentru asta – „Lansare secretă” (Dark Launch), care, la rândul său, este activată printr-o funcție cu un nume la fel de spion, „redirijarea traficului”.
Atenție, în prima propoziție a paragrafului anterior se folosește termenul „desfășurare” (deploy), nu „lansare” (release). Trebuie să ai cu adevărat posibilitatea de a desfășura – și, desigur, de a folosi – microserviciul tău de câte ori dorești. Acest serviciu ar trebui să fie capabil să primească și să proceseze trafic, să ofere rezultate, precum și să scrie în loguri și să fie monitorizat. Dar acest serviciu nu trebuie neapărat lansat în producție. Desfășurarea și lansarea software-ului nu sunt întotdeauna același lucru. Desfășurarea o poți face oricând dorești, dar lansarea doar atunci când ești complet pregătit.
Organizarea plictiselii este interesantă
Uită-te la următoarea regulă de rutare Istio, care direcționează toate cererile HTTP către microserviciul recommendation v1 (toate exemplele sunt luate din ), în timp ce le oglindește simultan pe microserviciul recommendation v2:
Atenție la eticheta mirror: de la baza ecranului – aceasta este cea care setează oglindirea traficului. Da, e așa de simplu!
Rezultatul acestui proces va fi că sistemul dumneavoastră de producție (v1) va continua să proceseze cererile primite, dar cererile în sine vor fi, de asemenea, oglindite în mod asincron pe v2, adică acolo vor fi trimise duplicate complete ale acestora. Astfel, veți putea testa funcționarea v2 în condiții reale - pe date și trafic reale - fără a interveni în activitatea sistemului de producție. Face acest lucru testarea mai plictisitoare? Da, cu siguranță. Dar se face într-un mod interesant.
Să adăugăm dramă
Rețineți că în codul v2 trebuie să prevedem situații în care cererile primite pot duce la modificarea datelor. Cererile în sine sunt oglindite ușor și transparent, dar alegerea modului de procesare în testare rămâne în sarcina dumneavoastră - iar acest lucru este deja puțin neliniștitor.
Să reiterăm un punct important
Lansarea secretă cu oglindirea traficului (Dark Launch/Request Mirroring) poate fi realizată fără a afecta codul.
Alimentație pentru gândire
Ce-ar fi dacă, în loc să oglindim cererile, am trimite o parte dintre ele nu pe v1, ci pe v2? De exemplu, un procent din toate cererile sau doar cererile de la un anumit grup de utilizatori. Și apoi, observând cum funcționează v2, să transferăm treptat toate cererile pe noua versiune. Sau, dimpotrivă, să revenim cu toate pe v1, dacă ceva nu merge bine cu v2. Se pare că acest lucru se numește Canary Deployment ("implementare canar" – un termen , și dacă ar avea origine rusă, ar conține probabil o referință la ), și acum vom explora acest aspect mai detaliat.
Canary Deployment în Istio:Simplificăm procesul de implementare
Prudență și gradualitate
Esenta modelului de implementare Canary Deployment este extrem de simplă: atunci când lansați o nouă versiune a software-ului dumneavoastră (în cazul nostru, un microserviciu), mai întâi oferiți acces la aceasta unui mic grup de utilizatori. Dacă totul decurge bine, creșteți încet acest grup până când noua versiune începe să aibă probleme, sau - dacă acest lucru nu se întâmplă - în cele din urmă transferați toți utilizatorii pe ea. Introducând treptat și controlat noua versiune și comutând utilizatorii pe aceasta, puteți reduce riscurile și maximiza feedback-ul.
Desigur, Istio simplifică Canary Deployment, oferind mai multe opțiuni bune pentru rutarea inteligentă a cererilor. Și da, toate acestea se pot face fără a atinge codul sursă.
Filtrăm browserul
Unul dintre cele mai simple criterii de rutare este redirecționarea în funcție de browser. Să presupunem că doriți ca doar cererile din browserul Safari să meargă la v2. Iată cum se face:
Aplicăm această regulă de rutare și apoi vom simula cereri reale către microserviciu folosind comanda curl . Așa cum se poate vedea în captură de ecran, toate cererile merg la v1:
Dar unde este traficul către v2? Deoarece în exemplul nostru toate cererile au venit doar din linia noastră de comandă, acesta pur și simplu nu există. Dar observați liniile inferioare din captura de ecran de mai sus: aceasta este reacția la cererea efectuată din browserul Safari, care a returnat următoarele:
Putere nelimitată
Am mai scris că expresiile regulate oferă posibilități foarte puternice pentru rutarea cererilor. Uitați-vă la următorul exemplu (credem că veți înțelege și singuri ce face):
Acum, probabil că aveți o idee despre ce pot face expresiile regulate.
Acționați inteligent
Rutarea inteligentă, în special prelucrarea antetelor pachetelor folosind expresii regulate, permite gestionarea traficului așa cum doriți. Și aceasta simplifică considerabil introducerea unui nou cod – este simplu, nu necesită modificarea codului în sine și, dacă este necesar, totul poate fi rapid readus la starea inițială.
Interesat?
Doriți să experimentați cu Istio, Kubernetes și OpenShift pe computerul dvs.? Echipa a pregătit un excelent pe această temă și a pus la dispoziție toate fișierele aferente. Așa că înainte, și nu vă refuzați nimic.
Istio Egress: ieșire prin magazinul de suveniruri
Folosind Istio împreună cu Red Hat OpenShift și Kubernetes, îți poți simplifica semnificativ viața cu microserviciile. Rețeaua de servicii Istio este integrată în pod-urile Kubernetes, iar codul tău rulează (în principal) izolat. Performanța, ușurința în modificare, trasabilitatea și altele – toate acestea sunt ușor de utilizat datorită containerelor sidecar. Dar ce se întâmplă dacă microserviciul tău trebuie să comunice cu alte servicii care se află în afara sistemului tău OpenShift-Kubernetes?
Aici intervine Istio Egress. Pe scurt, acesta permite accesul la resurse (citeste: „servicii”) care nu fac parte din pod-urile tale Kubernetes. Fără o configurare suplimentară, în mediul Istio Egress, traficul este rutat doar în interiorul clusterului de pod-uri și între aceste clustere, pe baza tabelelor IP interne. Această izolare funcționează perfect până când ai nevoie de acces la servicii externe.
Egress permite ocolirea tabelelor IP menționate anterior, fie pe baza regulilor Egress, fie pentru un interval de adrese IP.
Să presupunem că avem un program Java care face o cerere GET la httpbin.org/headers.
(httpbin.org este pur și simplu un resursă convenabilă pentru testarea cererilor externe de servicii.)
Dacă introduci în linia de comandă curl http://httpbin.org/headers, vom vedea următoarele:
Sau poți deschide aceeași adresă în browser:
Așa cum vedem, serviciul plasat acolo returnează pur și simplu anteturile transmise.
Importăm direct
Acum să luăm codul Java al acestui serviciu extern față de sistemul nostru și să-l rulăm la noi, unde reamintim, este instalat Istio. (Poți face acest lucru singur, consultând .) După ce am realizat construcția imaginii corespunzătoare și am rulat-o pe platforma OpenShift, vom apela acest serviciu cu comanda curl egresshttpbin-istioegress.$(minishift ip).nip.io, după care vom vedea pe ecran următoarele:
Ups, ce s-a întâmplat? Tocmai a funcționat. Ce înseamnă Not Found? Tocmai am creat pentru el curl.
Extindem tabelele IP la întreaga internet
Culpa (sau recunoștință) pentru aceasta trebuie dată lui Istio. Istio este pur și simplu containere sidecar care se ocupă de descoperirea și rutarea serviciilor (dar și de multe alte lucruri despre care am povestit anterior). Din această cauză, tabelele IP știu doar despre ceea ce se află în interiorul sistemului vostru de clustere. httpbin.org este situat în afara și, prin urmare, nu este accesibil. Aici intervine Istio Egress – fără nicio modificare în codul vostru sursă.
Regula Egress de mai jos îi cere lui Istio să caute (dacă este necesar, chiar în întreaga lume) serviciul necesar, în acest caz, httpbin.org. Așa cum se poate observa din acest fișier (egress_httpbin.yml), funcționalitatea este destul de simplă:
Rămâne doar să aplicăm această regulă:
istioctl create -f egress_httpbin.yml -n istioegress
Regulile Egress pot fi vizualizate cu comanda istioctl get egressrules:
Și, în final, reluăm comanda curl – și vedem că totul funcționează:
Gândim deschis
După cum vedeți, Istio permite organizarea interacțiunii și cu lumea exterioară. Cu alte cuvinte, puteți continua să creați servicii OpenShift și să le gestionați prin Kubernetes, păstrându-le în pod-uri, care se scalază în sus și în jos, după cum este necesar. Și da, repetăm încă o dată, că totul acest lucru se poate face fără a modifica codul vostru.
Acesta a fost ultimul post din seria despre Istio. Rămâneți cu noi – urmează multe lucruri interesante!
Sursa: habr.com
