„Pericol este al doilea nume al meu”, obișnuia să spună Austin Powers, un om internațional al misterului. Dar ceea ce este ținut cu mare cinste de către super-agenți și serviciile de informații nu este deloc potrivit pentru serviciile informatice, unde plictiseala este mult mai bună decât pericolul.
Iar Istio, împreună cu OpenShift și Kubernetes, face ca implementarea microserviciilor să fie cu adevărat plictisitoare și previzibilă - și asta este grozav. Vom vorbi despre asta și multe altele în a patra și ultima postare din seria Istio.
Când plictiseala este corectă
În cazul nostru, plictiseala apare doar în faza finală, când tot ce rămâne este să stai și să urmărești procesul. Dar pentru aceasta trebuie să configurați totul mai întâi și o mulțime de lucruri interesante vă așteaptă aici.
Când implementați o nouă versiune a software-ului dvs., merită să luați în considerare toate opțiunile pentru a minimiza riscurile. Rularea în paralel este o modalitate foarte puternică și dovedită de a testa, iar Istio vă permite să utilizați un „serviciu secret” (o versiune ascunsă a microserviciului) pentru a face acest lucru fără a interfera cu sistemul de producție. Există chiar și un termen special pentru acest lucru - „Dark Launch”, care, la rândul său, este activat de o funcție cu un nume la fel de spion „oglindire trafic”.
Vă rugăm să rețineți că prima propoziție a paragrafului anterior folosește termenul „desfășurare” mai degrabă decât „eliberare”. Ar trebui să puteți implementa și, bineînțeles, să utilizați microserviciul dvs. ori de câte ori doriți. Acest serviciu trebuie să fie capabil să primească și să proceseze trafic, să producă rezultate și, de asemenea, să scrie în jurnale și să monitorizeze. Dar, în același timp, acest serviciu în sine nu trebuie neapărat să fie lansat în producție. Implementarea și lansarea de software nu sunt întotdeauna același lucru. Puteți implementa oricând doriți, dar eliberați numai când sunteți gata.
Organizarea plictiselii este interesantă
Aruncă o privire la următoarea regulă de rutare Istio, care direcționează toate solicitările HTTP către recomandarea de microservicii v1 (toate exemplele luate de la ), în timp ce le reflectă simultan în microserviciul de recomandare v2:
Acordați atenție etichetei mirror: în partea de jos a ecranului - aceasta este cea care setează oglindirea traficului. Da, atât de simplu!
Rezultatul acestei reguli va fi că sistemul dvs. de producție (v1) va continua să proceseze cererile primite, dar cererile în sine vor fi reflectate asincron la v2, adică duplicatele lor complete vor merge acolo. Astfel, puteți testa v2 în condiții reale - pe date și trafic real - fără a interfera în vreun fel cu funcționarea sistemului de producție. Acest lucru face plictisitor organizarea testării? Da cu siguranta. Dar se face într-un mod interesant.
Să adăugăm dramă
Vă rugăm să rețineți că în codul v2 este necesar să se prevadă situații în care solicitările primite pot duce la modificări de date. Solicitările în sine sunt reflectate ușor și transparent, dar alegerea metodei de procesare în test depinde de dvs. - și acest lucru este puțin îngrijorător.
Să repetăm un punct important
Lansarea secretă cu oglindire trafic (Dark Launch/Request Mirroring) poate fi efectuată fără a afecta codul în vreun fel.
Hrana pentru minte
Ce se întâmplă dacă locul în care sunt oglindite solicitările le trimite pe unele nu la v1, ci la v2? De exemplu, un procent din toate solicitările sau numai cererile de la un anumit grup de utilizatori. Și apoi, uitându-vă deja la modul în care funcționează v2, transferați treptat toate solicitările în noua versiune. Sau invers, întoarceți totul la v1 dacă ceva nu merge bine cu v2. Cred că se numește Canary Deployment. , iar dacă ar fi de origine rusă, ar conține probabil o referire la ), iar acum ne vom uita la asta mai detaliat.
Canary Deployment în Istio: simplificarea punerii în funcțiune
Cu grijă și treptat
Esența modelului de implementare Canary Deployment este extrem de simplă: atunci când lansați o nouă versiune a software-ului dvs. (în cazul nostru, un microserviciu), acordați mai întâi acces la acesta unui grup mic de utilizatori. Dacă totul merge bine, creșteți încet acest grup până când noua versiune începe să acționeze sau - dacă nu merge - în cele din urmă migrați toți utilizatorii la el. Prin introducerea atentă și treptat a unei noi versiuni și trecerea utilizatorilor către aceasta într-un mod controlat, puteți reduce riscurile și puteți maximiza feedback-ul.
Desigur, Istio simplifică implementarea Canary, oferind câteva opțiuni bune pentru rutarea inteligentă a cererilor. Și da, toate acestea se pot face fără a atinge codul sursă în vreun fel.
Filtrarea browserului
Unul dintre cele mai simple criterii de rutare este redirecționarea bazată pe browser. Să presupunem că doriți ca numai solicitările din browserele Safari să treacă la v2. Iată cum se face:
Să aplicăm această regulă de rutare și apoi să folosim comanda curl Vom simula cereri reale către microserviciu într-o buclă. După cum puteți vedea în captură de ecran, toate merg la v1:
Unde este traficul pe v2? Deoarece în exemplul nostru toate cererile au venit doar din propria noastră linie de comandă, pur și simplu nu există. Dar fiți atenți la liniile de jos din ecranul de mai sus: aceasta este o reacție la faptul că am executat o solicitare din browserul Safari, care, la rândul său, a produs acest lucru:
Putere nelimitată
Am scris deja că expresiile regulate oferă capabilități foarte puternice pentru rutarea cererilor. Aruncă o privire la următorul exemplu (credem că vei înțelege ce face):
Până acum probabil că aveți o idee despre ce pot face expresiile regulate.
Acționează inteligent
Rutarea inteligentă, în special procesarea antetelor de pachete folosind expresii regulate, vă permite să direcționați traficul așa cum doriți. Și acest lucru simplifică foarte mult implementarea noului cod - este simplu, nu necesită schimbarea codului în sine și, dacă este necesar, totul poate fi returnat rapid așa cum era.
Interesat?
Ești dornic să experimentezi cu Istio, Kubernetes și OpenShift pe computer? Echipă pregătit un excelent pe acest subiect și a făcut publice toate fișierele însoțitoare. Așa că mergeți mai departe și nu vă negați nimic.
Istio Egress: ieșire prin magazinul de suveniruri
Folosind Istio împreună cu Red Hat OpenShift și Kubernetes, vă puteți face viața mult mai ușoară cu microservicii. Mesh-ul de servicii Istio este ascuns în interiorul podurilor Kubernetes, iar codul dvs. rulează (în mare parte) izolat. Performanță, ușurință în schimbare, urmărire etc. – toate acestea sunt ușor de utilizat datorită folosirii 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 este locul în care Istio Egress vine în ajutor. Pe scurt, pur și simplu vă permite să accesați resurse (a se citi: „servicii”) care nu fac parte din sistemul dumneavoastră de poduri Kubernetes. Dacă nu efectuați o configurare suplimentară, atunci în mediul Istio Egress traficul este direcționat numai într-un cluster de pod-uri și între astfel de clustere pe baza tabelelor IP interne. Și o astfel de pupație funcționează excelent atâta timp cât nu aveți nevoie de acces la servicii din exterior.
Ieșire vă permite să ocoliți tabelele IP de mai sus, fie pe baza regulilor de ieșire, fie pe o serie de adrese IP.
Să presupunem că avem un program Java care face o cerere GET către httpbin.org/headers.
(httpbin.org este doar o resursă convenabilă pentru testarea solicitărilor de servicii trimise.)
Dacă intri pe linia de comandă curl http://httpbin.org/headers, vom vedea următoarele:
Sau puteți deschide aceeași adresă în browser:
După cum puteți vedea, serviciul situat acolo returnează pur și simplu anteturile transmise acestuia.
Înlocuim importurile direct
Acum să luăm codul Java al acestui serviciu, extern sistemului nostru și să-l rulăm pe cont propriu, unde, reamintim, este instalat Istio. (Puteți face acest lucru singur contactând .) După ce am construit imaginea corespunzătoare și am lansat-o pe platforma OpenShift, vom apela acest serviciu cu comanda curl egresshttpbin-istioegress.$(minishift ip).nip.io, după care vom vedea asta pe ecran:
Hopa, ce sa întâmplat? Totul a funcționat. Ce înseamnă Not Found? Tocmai am făcut-o pentru el curl.
Extinderea tabelelor IP la întregul Internet
Istio ar trebui învinuit (sau mulțumit) pentru asta. La urma urmei, Istio sunt doar containere sidecar care sunt responsabile pentru detectarea și rutarea (și o mulțime de alte lucruri despre care am vorbit mai devreme). Din acest motiv, tabelele IP știu doar ce este în interiorul sistemului dvs. de cluster. Și httpbin.org este situat în exterior și, prin urmare, inaccesibil. Și aici este locul în care Istio Egress vine în ajutor - fără nici cea mai mică modificare a codului sursă.
Regula de ieșire de mai jos obligă Istio să caute (dacă este necesar, apoi pe întregul Internet) serviciul necesar, în acest caz, httpbin.org. După cum puteți vedea din acest fișier (egress_httpbin.yml), funcționalitatea aici este destul de simplă:
Tot ce rămâne este să aplici această regulă:
istioctl create -f egress_httpbin.yml -n istioegress
Puteți vizualiza regulile de ieșire cu comanda istioctl get egressrules:
Și, în sfârșit, rulăm din nou comanda răsuci – și vedem că totul funcționează:
Gândim deschis
După cum puteți vedea, Istio vă permite să organizați interacțiunea cu lumea exterioară. Cu alte cuvinte, puteți în continuare să creați servicii OpenShift și să le gestionați prin Kubernetes, păstrând totul în pod-uri care se scalează în sus și în jos, după cum este necesar. Și, în același timp, puteți accesa în siguranță servicii externe mediului dumneavoastră. Și da, repetăm încă o dată că toate acestea se pot face fără a atinge codul în vreun fel.
Acesta a fost ultimul post din serie despre Istio. Rămâneți pe fază - urmează o mulțime de lucruri interesante!
Sursa: www.habr.com