«Վտանգը իմ երկրորդ անունն է», - ասում էր Օսթին Փաուերսը, առեղծվածային միջազգային մարդ: Բայց այն, ինչ բարձր են գնահատում սուպեր գործակալներն ու հետախուզական ծառայությունները, ամենևին էլ հարմար չէ համակարգչային ծառայությունների համար, որտեղ ձանձրույթը շատ ավելի լավ է, քան վտանգը։
Իսկ Istio-ն OpenShift-ի և Kubernetes-ի հետ միասին միկրոծառայությունների տեղակայումը դարձնում է իսկապես ձանձրալի և կանխատեսելի, և դա հիանալի է: Այս և շատ ավելին կխոսենք Իստիո շարքի չորրորդ և վերջին գրառման մեջ:
Երբ ձանձրույթը ճիշտ է
Մեզ մոտ ձանձրույթն առաջանում է միայն վերջնական փուլում, երբ մնում է նստել ու հետևել ընթացքին։ Բայց դրա համար նախ պետք է ամեն ինչ կարգավորել, և այստեղ ձեզ շատ հետաքրքիր բաներ են սպասում:
Ձեր ծրագրաշարի նոր տարբերակը տեղակայելիս արժե հաշվի առնել ռիսկերը նվազագույնի հասցնելու բոլոր տարբերակները: Զուգահեռաբար վազելը փորձարկման շատ հզոր և ապացուցված միջոց է, և Istio-ն թույլ է տալիս օգտագործել «գաղտնի ծառայություն» (ձեր միկրոծառայության թաքնված տարբերակը) դա անելու համար՝ չխանգարելով արտադրական համակարգին: Դրա համար նույնիսկ հատուկ տերմին կա՝ «Dark Launch», որն իր հերթին ակտիվանում է «traffic mirroring» նույնքան լրտեսական անունով ֆունկցիայի միջոցով։
Խնդրում ենք նկատի ունենալ, որ նախորդ պարբերության առաջին նախադասությունը օգտագործում է «տեղակայել» տերմինը, այլ ոչ թե «ազատում»: Դուք իսկապես պետք է կարողանաք տեղակայել և, իհարկե, օգտագործել ձեր միկրոծառայությունը այնքան հաճախ, որքան ցանկանում եք: Այս ծառայությունը պետք է կարողանա ստանալ և մշակել տրաֆիկը, արդյունքներ արտադրել, ինչպես նաև գրել տեղեկամատյաններում և վերահսկել: Բայց միևնույն ժամանակ, այս ծառայությունն ինքնին պարտադիր չէ, որ թողարկվի արտադրության մեջ: Ծրագրային ապահովման տեղակայումն ու թողարկումը միշտ չէ, որ նույնն են: Դուք կարող եք տեղակայվել երբ ցանկանաք, բայց թողարկեք միայն այն ժամանակ, երբ պատրաստ եք:
Հետաքրքիր է ձանձրույթի կազմակերպումը
Նայեք Istio երթուղավորման հետևյալ կանոնին, որը բոլոր HTTP հարցումները ուղղորդում է դեպի միկրոսերվիսային առաջարկ v1 (բոլոր օրինակները վերցված են. ), միաժամանակ դրանք արտացոլելով v2 microservice-ի առաջարկին.
Ուշադրություն դարձրեք պիտակի վրա mirror: էկրանի ներքևի մասում - սա է, որ սահմանում է երթևեկության արտացոլումը: Այո, դա այնքան պարզ է:
Այս կանոնի արդյունքը կլինի այն, որ ձեր արտադրական համակարգը (v1) կշարունակի մշակել մուտքային հարցումները, բայց հարցումներն իրենք ասինխրոն կերպով կարտացոլվեն v2-ին, այսինքն՝ դրանց ամբողջական կրկնօրինակները կգնան այնտեղ: Այսպիսով, դուք կարող եք ստուգել v2-ը իրական պայմաններում՝ իրական տվյալների և տրաֆիկի վրա, առանց որևէ կերպ միջամտելու արտադրական համակարգի աշխատանքին: Սա ձանձրալի՞ է դարձնում թեստավորման կազմակերպումը: Այո, միանշանակ։ Բայց դա արվում է հետաքրքիր ձևով։
Ավելացնենք դրաման
Խնդրում ենք նկատի ունենալ, որ v2 կոդում անհրաժեշտ է նախատեսել իրավիճակներ, երբ մուտքային հարցումները կարող են հանգեցնել տվյալների փոփոխության: Հարցումները ինքնին արտացոլվում են հեշտությամբ և թափանցիկ, բայց թեստի մշակման մեթոդի ընտրությունը կախված է ձեզանից, և դա մի փոքր մտահոգիչ է:
Կրկնենք մի կարևոր կետ
Գաղտնի գործարկումը երթեւեկության արտացոլման միջոցով (Dark Launch/Request Mirroring) կարող է իրականացվել առանց կոդի վրա որեւէ կերպ ազդելու:
Մտածելու սնունդ
Իսկ եթե հարցումների արտացոլման վայրը ուղարկի դրանցից մի քանիսը ոչ թե v1, այլ v2: Օրինակ, բոլոր հարցումների մեկ տոկոսը կամ միայն օգտվողների որոշակի խմբի հարցումները: Եվ հետո, արդեն նայելով, թե ինչպես է աշխատում v2-ը, աստիճանաբար փոխանցեք բոլոր հարցումները նոր տարբերակին։ Կամ հակառակը, ամեն ինչ վերադարձրեք v1-ին, եթե v2-ի հետ ինչ-որ բան սխալ է: Իմ կարծիքով դա կոչվում է Canary Deployment: , իսկ եթե ռուսական ծագում ունենար, հավանաբար հղում կպարունակեր ), և այժմ մենք ավելի մանրամասն կանդրադառնանք դրան:
Canary-ի տեղակայում Իստիոյում. գործարկման պարզեցում
Զգուշորեն և աստիճանաբար
Canary Deployment-ի տեղակայման մոդելի էությունը չափազանց պարզ է. երբ գործարկում եք ձեր ծրագրաշարի նոր տարբերակը (մեր դեպքում՝ միկրոսերվիս), նախ մուտք եք տալիս օգտվողների փոքր խմբին: Եթե ամեն ինչ լավ է ընթանում, դուք կամաց-կամաց ավելացնում եք այս խումբը, մինչև որ նոր տարբերակը սկսի գործել, կամ, եթե այդպես չէ, ի վերջո տեղափոխեք բոլոր օգտվողներին այնտեղ: Մտածված և աստիճանաբար նոր տարբերակ ներկայացնելով և օգտատերերին վերահսկվող եղանակով անցնելով դրան՝ կարող եք նվազեցնել ռիսկերը և առավելագույնի հասցնել հետադարձ կապը:
Իհարկե, Istio-ն պարզեցնում է Canary Deployment-ը` առաջարկելով մի քանի լավ տարբերակներ խելացի հարցումների երթուղավորման համար: Եվ այո, այս ամենը կարելի է անել՝ առանց որևէ կերպ դիպչելու ձեր սկզբնաղբյուրին։
Զտիչի զտում
Ուղղորդման ամենապարզ չափանիշներից մեկը բրաուզերի վրա հիմնված վերահղումն է: Ենթադրենք, դուք ցանկանում եք, որ միայն Safari բրաուզերների հարցումները գնան v2: Ահա թե ինչպես է դա արվում.
Եկեք կիրառենք այս երթուղավորման կանոնը և այնուհետև օգտագործենք հրամանը curl Մենք միկրոսերվիսին իրական խնդրանքները կսիմուլյացնենք օղակով: Ինչպես տեսնում եք սքրինշոթում, նրանք բոլորը գնում են v1:
Որտե՞ղ է երթևեկությունը v2-ում: Քանի որ մեր օրինակում բոլոր հարցումները գալիս էին միայն մեր սեփական հրամանի տողից, այն պարզապես գոյություն չունի: Բայց ուշադրություն դարձրեք վերևի էկրանի ներքևի տողերին. սա արձագանք է այն փաստին, որ մենք կատարեցինք հարցումը Safari բրաուզերից, որն իր հերթին ստացավ հետևյալը.
Անսահմանափակ հզորություն
Մենք արդեն գրել ենք, որ կանոնավոր արտահայտությունները շատ հզոր հնարավորություններ են տալիս երթուղային հարցումների համար: Նայեք հետևյալ օրինակին (կարծում ենք՝ կհասկանաք, թե դա ինչ է անում).
Մինչ այժմ դուք հավանաբար պատկերացում ունեք, թե ինչ կարող են անել կանոնավոր արտահայտությունները:
Գործեք խելացի
Խելացի երթուղավորումը, մասնավորապես փաթեթների վերնագրերի մշակումը, օգտագործելով կանոնավոր արտահայտություններ, թույլ է տալիս կառավարել երթևեկությունը այնպես, ինչպես ցանկանում եք: Եվ սա մեծապես հեշտացնում է նոր կոդի իրականացումը. դա պարզ է, այն չի պահանջում ինքնին փոխել կոդը, և անհրաժեշտության դեպքում ամեն ինչ կարող է արագ վերադարձվել այնպես, ինչպես եղել է:
Հետաքրքրվա՞ծ է:
Ցանկանու՞մ եք փորձարկել Istio-ն, Kubernetes-ը և OpenShift-ը ձեր համակարգչում: Թիմ պատրաստել է գերազանց այս թեմայի շուրջ և հանրությանը հասանելի դարձրեց բոլոր ուղեկցող ֆայլերը: Այսպիսով, առաջ գնացեք և ինքներդ ձեզ ոչինչ մի հերքեք:
Istio Egress. ելք հուշանվերների խանութով
Օգտագործելով Istio-ն Red Hat OpenShift-ի և Kubernetes-ի հետ միասին՝ դուք կարող եք շատ ավելի հեշտացնել ձեր կյանքը միկրոծառայությունների միջոցով: Istio-ի սպասարկման ցանցը թաքնված է Kubernetes pods-ի ներսում, և ձեր կոդը աշխատում է (հիմնականում) առանձին: Արդյունավետություն, փոփոխության հեշտություն, հետագծում և այլն. այս ամենը հեշտ է օգտագործել կողային բեռնարկղերի օգտագործման շնորհիվ: Բայց ի՞նչ անել, եթե ձեր միկրոսերվիսը պետք է հաղորդակցվի այլ ծառայությունների հետ, որոնք տեղակայված են ձեր OpenShift-Kubernetes համակարգից դուրս:
Այստեղ է, որ օգնության է հասնում Istio Egress-ը: Մի խոսքով, այն պարզապես թույլ է տալիս մուտք գործել ռեսուրսներ (կարդացեք՝ «ծառայություններ»), որոնք ձեր Kubernetes pods համակարգի մաս չեն կազմում: Եթե դուք չեք կատարում լրացուցիչ կոնֆիգուրացիա, ապա Istio Egress միջավայրում երթևեկությունը ուղղորդվում է միայն պատիճների կլաստերի մեջ և այդպիսի կլաստերների միջև՝ հիմնված ներքին IP աղյուսակների վրա: Եվ նման ձագը հիանալի է աշխատում այնքան ժամանակ, քանի դեռ ձեզ հարկավոր չէ դրսից օգտվելու ծառայություններ:
Egress-ը թույլ է տալիս շրջանցել վերը նշված IP աղյուսակները՝ հիմնվելով Egress կանոնների կամ IP հասցեների մի շարքի վրա:
Ենթադրենք, մենք ունենք Java ծրագիր, որը GET հարցում է կատարում httpbin.org/headers-ին:
(httpbin.org-ը պարզապես հարմար ռեսուրս է ելքային ծառայության հարցումները ստուգելու համար):
Եթե մուտքագրեք հրամանի տողում curl http://httpbin.org/headers, կտեսնենք հետևյալը.
Կամ կարող եք նույն հասցեն բացել բրաուզերում.
Ինչպես տեսնում եք, այնտեղ տեղակայված ծառայությունը պարզապես վերադարձնում է իրեն փոխանցված վերնագրերը։
Մենք ներմուծումը փոխարինում ենք առջև
Հիմա եկեք վերցնենք այս ծառայության Java ծածկագիրը, որը արտաքին է մեր համակարգից, և գործարկենք այն ինքնուրույն, որտեղ, հիշեցնենք, տեղադրված է Istio-ն: (Դա կարող եք անել ինքներդ՝ կապվելով .) Կառուցելով համապատասխան պատկերը և գործարկելով այն OpenShift հարթակում, մենք այս ծառայությունը կանվանենք հրամանով. curl egresshttpbin-istioegress.$(minishift ip).nip.io, որից հետո էկրանին կտեսնենք սա.
Վայ, ի՞նչ է պատահել։ Ամեն ինչ պարզապես աշխատեց: Ի՞նչ է նշանակում Չգտնվել: Մենք պարզապես դա արեցինք նրա համար curl.
IP աղյուսակների ընդլայնում ամբողջ ինտերնետում
Իստիոյին պետք է մեղադրել (կամ շնորհակալություն հայտնել) դրա համար: Ի վերջո, Istio-ն պարզապես կողային բեռնարկղեր է, որոնք պատասխանատու են հայտնաբերման և երթուղղման համար (և շատ այլ բաների մասին, որոնց մասին մենք ավելի վաղ խոսեցինք): Այս պատճառով IP աղյուսակները գիտեն միայն, թե ինչ կա ձեր կլաստերի համակարգի ներսում: Իսկ httpbin.org-ը գտնվում է դրսում և, հետևաբար, անհասանելի է: Եվ ահա, որտեղ օգնության է հասնում Istio Egress-ը` առանց ձեր սկզբնական կոդի նվազագույն փոփոխության:
Ստորև բերված Egress կանոնը ստիպում է Istio-ին որոնել (անհրաժեշտության դեպքում, ապա ողջ համացանցում) պահանջվող ծառայությունը, այս դեպքում՝ httpbin.org: Ինչպես տեսնում եք այս ֆայլից (egress_httpbin.yml), այստեղ ֆունկցիոնալությունը բավականին պարզ է.
Մնում է միայն կիրառել այս կանոնը.
istioctl create -f egress_httpbin.yml -n istioegress
Դուք կարող եք դիտել Egress կանոնները հրամանով istioctl get egressrules:
Եվ վերջապես, մենք նորից գործարկում ենք հրամանը գալար - և մենք տեսնում ենք, որ ամեն ինչ աշխատում է.
Մենք բաց ենք մտածում
Ինչպես տեսնում եք, Istio-ն թույլ է տալիս կազմակերպել փոխգործակցություն արտաքին աշխարհի հետ: Այլ կերպ ասած, դուք դեռ կարող եք ստեղծել OpenShift ծառայություններ և կառավարել դրանք Kubernetes-ի միջոցով՝ ամեն ինչ պահելով բլոկներում, որոնք անհրաժեշտության դեպքում մեծանում են և նվազում: Եվ միևնույն ժամանակ, դուք կարող եք ապահով կերպով օգտվել ձեր միջավայրից դուրս ծառայություններից: Եվ այո, ևս մեկ անգամ կրկնում ենք, որ այս ամենը կարելի է անել առանց ձեր կոդը որևէ կերպ դիպչելու։
Սա Istio-ում շարքի վերջին գրառումն էր: Հետևե՛ք, առջևում շատ հետաքրքիր բաներ կան:
Source: www.habr.com