Dark Launch в Istio: գաղտնի ծառայություններ

«Ավելի վտանգավոր է լինել, քան շատ աշխարհ», - ասում էր Օսթին Փաուերսը, միջազգային մասշտաբի загадка: Բայց այն, ինչին գնահատում են սուպերագենտներն ու գաղտնի ծառայությունները, ամբողջովին քաղաքական չէ, որտեղ ձանձրույթը շատ ավելի լավ է վտանգներից։

Իսկ Istio-ն, OpenShift-ի և Kubernetes-ի հետ միասին, միկրոծառայությունների տեղադրումն իրականում ձանձրալի և կանխատեսելի գործընթացի է վերածում. և դա հրաշալի է։ Այս մասին և շատ ավելինWe'll talk in the fourth and final post of the Istio series.

Երբ ձանձրույթը դա ճիշտ է

Մեր դեպքում ձանձրույթը միայն վերջին փուլում է առաջանում, երբ պարզապես պետք է նստել և հետեւել գործընթացին։ Բայց դրա համար նախ պետք է բոլորը նախապատրաստեք, և այստեղ ձեզ շատ հետաքրքիր բան է սպասում։

Նոր տարբերակ ձեր ծրագրաշարի տեղադրման ժամանակ պետք է բոլոր հնարավորությունները նշել ռիսկերը նվազեցնելու համար։ Պարալել կենցաղի աշխատանքը շատ ուժեղ և սանձող փորձարկման միջոց է, և Istio-ն թույլ է տալիս օգտագործել դրա համար «գաղտնի ծառայություն» (թաքնված ձեր միկրոծառայության տարբերակ) առանց պրոդուկտի համակարգի աշխատանքի մեջ միջամտելու։ Սա համար նույնիսկ հատուկ տերմին կա՝ «Dark Launch», որը, իր հերթին, ակտիվացվում է «traffic mirroring» անվամբ շփման գործիքի միջոցով։

Որպեսզի ուշադրություն դարձրեք, նախորդ աբեզում կիրառված «տեղադրումները» (deploy) տերմինը, այլ ոչ թե «ներդրումները» (release): Դուք իսկապես պետք է կարողանալ տեղադրել՝ և, իհարկե, օգտագործել ձեր միկրոծառայությունը այնքան հաճախ, որքան ցանկանաք։ Այս ծառայությունը պետք է իրականում կարողանա ստանալ և մշակել տրաֆիկը, արդյունքներ հանել, և նաև գրանցել լոգեր ու դիտարկվել։ Բայց հենց այդ ծառայությունը անմիջապես թող արտահայտվի պրոդուկտում։ Տեղադրումն ու ծրագրաշարի թողարկումը միշտ նույնը չեն։ Դուք միշտ կարող եք տեղադրել, երբ ցանկանում եք, բայց թողարկումը միայն այն ժամանակ, երբ վերջնականապես պատրաստ եք։

Ձանձրույթ կազմակերպելը հետաքրքիր է

Ձեր ուշադրությունը դեպի հետեւյալ Istio-ի ուղղություն կանոն, որը ճիշտ ուղղում է բոլոր HTTP-հարցումները recommendation v1 միկրոծառայությանը (բոլոր օրինաչափությունները վերցված են Istio Tutorial GitHub repo), միաժամանակ կրկնում է դրանք recommendation v2 միկրոծառայությանը։

Ներքևի նկարում ուշադրություն դարձրեք նշանին mirror: ներդրվող տրաֆիկը սահմանող: Այո, դարձել է այդքան հեշտ։

Այս կանոնն աշխատելու արդյունքում ձեր արտադրանքի համակարգը (v1) weiterhin կշարունակի նախապատրաստել ընդունվող հարցումները, բայց հարցումները ինքնին ասինխրոն կերպով կեղծանշանակվեն v2-ում, ինչը նշանակում է, որ այնտեղ կկոչվեն դրանց ամբողջական կրկնօրինակները: Այսպիսով, դուք կարող եք փորձարկել v2-ի աշխատանքը իրական պայմաններում՝ իրական տվյալներով և տրաֆիկով՝ առանց干扰ելու արտադրանքի համակարգի աշխատանքը: Ի՞նչ, դա դարձնում է փորձարկման կազմակերպումը ձանձրալի՞: Այո, անշուշտ: Բայց դա արվում է հետաքրքիր կերպ:

Ավելացնենք դրամա

Հիշեք, որ v2-ի կոդում պետք է կանխատեսել այն իրավիճակները, երբ ընդունվող հարցումները կարող են հանգեցնել տվյալների փոփոխության: Հարցումները հեշտությամբ և պարզորեն կեղծանշանակվում են, բայց փորձարկման բաշխման մշակման եղանակի ընտրությունը մնում է ձեր վրա՝ և սա արդեն մի քիչ անհանգստացնող է:

Կրկնենք կարևոր պահը

Գաղտնի մեկնարկը հետադարձության աղմուկով (Dark Launch/Request Mirroring) կարելի է իրականացնել՝ առանց կոդը դիպչելու:

Է սննդի երևակայություն

Եվ ի՞նչ, եթե հարցումների հետադարձության մի մասը ուղարկենք ոչ v1, այլ v2? Օրինակ, բոլոր հարցումների միայն մեկ տոկոսը կամ միայն որոշակի օգտվողների խմբի հարցումները: Եվ հետո, արդեն դիտելով, թե ինչպես է աշխատում v2-ն, աստիճանաբար փոխանցենք բոլոր հարցումները նոր տարբերակին: Ճշմարիտ, եթե v2-ի հետ ինչ-որ բան չի ձևավորվում, ապա պարտադիր վերադարձնենք ամեն ինչ v1-ին: Փոխարինել անվանումում է Canary Deployment («կանարե խուսափում»)՝ հասկացություն, որը պատմում է սահմանափակքների մասին, և եթե նրա ռուսերեն ծագումը լիներ, հավանաբար, կլիներ հղում կատուներին), և հիմա մենք նկատի կունենանք այն ավելի մանրամասն:

Canary Deployment-ում Istio-ն պարզեցնում է ներդրումը

Անհասկանալի և աստիճանաբար

Canary Deployment-ի մոդելի բովանդակությունը խիստ պարզ է. նոր ծրագրային տարբերակին (մեր դեպքում՝ միկրոկառավարիչ) դուք առաջին հերթին մատչելիություն եք տալիս փոքր խմբի օգտվողների: Եթե ամեն ինչ բարեհաջող է, դուք դանդաղ увеличиваете այն խմբի չափը մինչև այն պահը, երբ նոր տարբերակն սկսում է հարմարեցվել, կամ՝ եթե այդպես էլ չի տեղի ունենում՝ վերջնականապես փոխանցում եք այն բոլոր օգտվողներին: Խնամքով և աստիճանաբար ներդնելով նոր տարբերակը և վերահսկելով նրա վրա օգտագործողի տեղափոխումը, կարելի է նվազեցնել ռիսկերը և առավելագույնացնել հակադարձ կապը:

Առաջին հերթին, Istio-ն պարզեցնում է Canary Deployment-ը՝ առաջարկելով մի քանի լավ տարբերակներ խելացի հարցումների զարգացման համար: Եվ այո, ամեն ինչ կարելի է իրականացնել՝ ձեր սկուբոլը խախտելիս:

Ֆիլտրել բրաուզերը

Ընդհանուր կարևոր նախնական տարբերակներից մեկն է՝ ուղղելով բրաուզերի հիման վրա: Ցանկանում եք, որպեսզի v2 միայն Safari բրաուզերներից գա. Вот как это делается:

Կիրառելով այս ռուլը մեզ մոտ և ապա թիմի curl կկրկնորդենք իրական հարցումներ միկրոմարգինում: Ինչպես երևում է էկրանի վրա, բոլորը գնում են v1:

Եվ ուր է v2-ի հաղորդումը? Քանի որ մեր օրինակով բոլոր հարցումները կատարվել են միայն մեր սեփական հրամանատողի միջով, ապա այն պարզապես չկա: Բայց ուշադրություն դարձրեք վերևի էկրանում նշված ստորին տողերին. սա պատասխանն է նրան, որ մենք հարցում կատարել ենք Safari բրաուզերից, որը, իր հերթին, տվել է հետևյալը:

Անսահման լիազորություն

Մենք արդեն գրել ենք, որ կանոնավոր արտահայտությունները տուողական հնարավորություններ են հաղորդումների երթևեկության համար: Ուշադրություն դարձեք հետևյալ օրինակին (հիմա մտածում ենք, որ դուք ինքներդ հասկանում եք, թե ինչ է դա անում):

Այժմ դուք, հավանաբար, արդեն պատկերացնում եք, թե ինչ կարող են անել կանոնավոր արտահայտությունները:

Գործեք խելքով

Խելացի երթևեկությունը, մասնավորապես փաթեթների վերնագրերի մշակումն օգտագործելով կանոնավոր արտահայտություններ, թույլ է տալիս կառավարել երթևեկությունը այնպես, ինչպես ցանկանում եք: Եվ դա զգալիորեն հեշտացնում է նոր կոդի մտցումը մատնանշելով. դա հեշտ է, չի պահանջում ճիշտ փոփոխություններ ինքնուրույն, և անհրաժեշտության դեպքում ամեն ինչ կարող է արագ վերադառնալ անել ինչպես նախկինում.

Հետաքրքրե՞լ եք:

Ձեզ ոգևորում է փորձել Istio, Kubernetes և OpenShift ձեր համակարգչում? Հանդիպեք Red Hat Developer Team հիանալի ուսումնական գիրք հոդված այս թեմայով և հրապարակել ողջ հարակից նյութերը: այնպես որ առաջ, և ոչ մի բան ձեզ խոչընդոտում չկա:
 

Istio Egress: ելք souvenirs պաշարով

Istio-ն համատեղ օգտագործելով Red Hat OpenShift և Kubernetes, դուք կարող եք զգալիորեն հեշտացնել ձեր կյանքը միկրոպ ծառայություններով: Istio ծառայությունների ցանցը ամփոփված է Kubernetes-ի pod-երի ներսում, և ձեր կոդը կատարվում է (հիմնականում) առանձնացված: Ապրանքի, փոփոխման հեշտություն, ըմբռնում և այլն՝ այս ամենը հեշտորեն օգտագործելի է, հենց շնորհիվ sidecar-կոնտեյների կիրառման: Բայց ինչ անել, եթե ձեր միկրոպ ծառայությունը պետք է խոսի այն այլ ծառայությունների հետ, որոնք գտնվում են ձեր OpenShift-Kubernetes համակարգից դուրս:

Այստեղ օգնության է գալիս Istio Egress: Եթե երկու բառով, այն պարզապես թույլ է տալիս մուտք գործել այն ռեսուրսների (արդի. «ծառայություններ»), որոնք չեն մտնում ձեր Kubernetes-ի pod-երի համակարգում: Եթե լրացուցիչ կազմաձևում չկատարեք, ապա Istio Egress միջավայրում երթևեկությունը երթևեկվում է միայն pod-երի կլաստերի ներսում և նման կլաստերների միջև՝ հիմնվելով ներքին IP-դասակարգերում: Եվ այսպիսի փակումը прекрасно աշխատում է, մինչ դուք չունեք մուտք դեպի արտաքին ծառայություններ:

Egress-ը թույլ է տալիս շրջանցել վերոնշյալ IP-դասակարգերը, թե Egress կանոնների հիման վրա, թե IP-հասանելիության պարամետրերի համար:

Ենթադրենք, որ մեզ մոտ կա Java ծրագիր, որը կատարում է GET հարցում httpbin.org/headers:

(httpbin.org-ը պարզապես հարմար պաշար է դուրս եկող ծառայության հարցումների փորձարկման համար.)

Եթե հրամանատողի ստեղնաշարի մասում գրել curl http://httpbin.org/headers, մենք կտեսնենք հետևյալը:

Կամ սա էլ կարելի է բացել այն նույն հասցեում բրաուզերում:

Ինչպես տեսնում ենք, այնտեղ գտնվում է ծառայությունը, որը պարզապես վերադարձնում է միտքված վերնագրերը.

Импортозамещаем в лоб

Ներկայում կին սպասենք Java կոդը, որը արտաքին ծառայություն է մեր համակարգի նկատմամբ, և սկսենք այն մեզ մոտ, որտեղ գտնվում է Istio։ (Դուք կարող եք անել դա ինքնուրույն՝ դիմելով մեր Istio ուղեցույցին.) Գառնում է համապատասխան պատկեր, և սկսում ենք այն OpenShift հարթակում, մենք կկանչենք այս ծառայությունը հրամանով curl egresshttpbin-istioegress.$(minishift ip).nip.io, ապա կտեսնենք էկրանի վրա սա.

Օհ, ինչ պատահեց: Բոլորովին նոր չէին: Ի՞նչ է նշանակում Not Found? Մենք իսկապես հիմա դրա համար curl.

Վերահսկում ենք IP աղյուսակները ամբողջ ինտերնետում

Արգելեք (կամ շնորհակալություն) դրա համար Istio-ին։ Ըստ այդմ, Istio-ն պարզապես sidecar- կոնտեյներներ են, որոնք պատասխանատու են հայտնաբերման և ուղղորդման (և շատ այլ բանի, որի մասին խոսել ենք առաջ) համար։ Այս պատճառով IP աղյուսակները միայն գիտեն այն, ինչը գտնվում է ձեր կլաստերի համակարգում։ Իսկ httpbin.org-ը գտնվում է դրսում և հետևաբար հասցեագրելու չէ։ Այստեղ օգնության է գալիս Istio Egress – առանց որևէ փոփոխություն ձեր հիմնական կոդում։

Ներքևում ներկայացված Egress կանոնը ստիպում է Istio-ին որոնել (եթե հարկ լինի, ամբողջ համաշխարհային ինտերնետում) անհրաժեշտ ծառայությունը, այս դեպքում՝ httpbin.org։ Ինչպես երևում է այս ֆայլում (egress_httpbin.yml), ֆունկցիան այստեղ բացարձակ պարզ է.

Մնում է միայն կիրառել այս կանոնը:

istioctl create -f egress_httpbin.yml -n istioegress

Egress կանոնները դիտելու համար հարմարեցված է հրամանով istioctl get egressrules:

Ու վերջապես, նորից սկսնում ենք հրամանը curl – և տեսնում ենք, որ ամեն ինչ աշխատում է.

Մտող բաց գաղափարներ

Ինչպես եք տեսնում, Istio-ն թույլ է տալիս կազմակերպել փոխազդեցություն արտաքին աշխարհի հետ։ Այլ կերպ ասած, դուք կարող եք շարունակել ստեղծել OpenShift ծառայություններ և կառավարել դրանք Kubernetes-ի միջոցով, պահելով բոլորն անցքի մեջ, որոնք կարող եք լայնացնել կամ կրճատել, ըստ անհրաժեշտության։ Եվ այս ընթացքում դուք խաղաղ կարող եք դիմել արտաքին համակարգով ծառայություններին։ Եվ այո, կրկնաբառենք, որ սա կարելի է անել՝ առանց ձեր կոդին որևէ կերպ վերադառնալու։

Սա վերջին հրապարակումն է Istio մասին։ Մնացեք մեզ հետ՝ առաջ还有 հետաքրքիր է!

Ընտանիք: habr.com