Նշում. թարգմ.Kubernetes համայնքում GitOps կոչվող միտումը ակնհայտ ժողովրդականություն է ձեռք բերում, ինչպես մենք անձամբ տեսել ենք, KubeCon Europe 2019. Այս տերմինը համեմատաբար վերջերս էր Weaveworks-ի ղեկավար Ալեքսիս Ռիչարդսոնի կողմից և նշանակում է մշակողներին ծանոթ գործիքների օգտագործում (հիմնականում Git, այստեղից էլ անվանումը) գործառնական խնդիրների լուծման համար: Մասնավորապես, մենք խոսում ենք Kubernetes-ի աշխատանքի մասին՝ Git-ում դրա կոնֆիգուրացիաները պահելու և կլաստերի մեջ փոփոխությունները ավտոմատ կերպով գլորելու միջոցով: Matthias Jg-ն այս հոդվածում խոսում է այս ներդրման երկու մոտեցումների մասին:
Անցյալ տարի (իրականում, պաշտոնապես դա տեղի է ունեցել 2017 թվականի օգոստոսին - մոտավորապես թարգմ.) Կուբերնետեսում հավելվածների տեղակայման նոր մոտեցում կա: Այն կոչվում է GitOps, և այն հիմնված է այն հիմնական գաղափարի վրա, որ տեղակայման տարբերակները հետևվում են Git պահեստի անվտանգ միջավայրում:
Այս մոտեցման հիմնական առավելությունները հետևյալն են.:
- Տեղակայման տարբերակների ձևավորում և փոփոխությունների պատմություն. Ամբողջ կլաստերի վիճակը պահվում է Git պահոցում, և տեղակայումները թարմացվում են միայն կոմիտացիաների միջոցով։ Բացի այդ, բոլոր փոփոխություններին կարելի է հետևել՝ օգտագործելով commit պատմությունը:
- Հետադարձումներ՝ օգտագործելով ծանոթ Git հրամանները. Պարզ
git resetթույլ է տալիս վերակայել տեղակայումների փոփոխությունները. անցյալ վիճակները միշտ հասանելի են: - Պատրաստի մուտքի վերահսկում. Որպես կանոն, Git համակարգը պարունակում է շատ զգայուն տվյալներ, ուստի ընկերությունների մեծ մասը հատուկ ուշադրություն է դարձնում դրանց պաշտպանությանը: Համապատասխանաբար, այս պաշտպանությունը վերաբերում է նաև տեղակայման գործողություններին:
- Տեղակայման քաղաքականություն. Git համակարգերի մեծ մասը բնիկորեն աջակցում է ճյուղ առ մասնաճյուղ քաղաքականություն, օրինակ, միայն pull-ի հարցումները կարող են թարմացնել հիմնականը, և փոփոխությունները պետք է վերանայվեն և ընդունվեն թիմի մեկ այլ անդամի կողմից: Ինչպես մուտքի վերահսկման դեպքում, նույն քաղաքականությունը կիրառվում է տեղակայման թարմացումների դեպքում:
Ինչպես տեսնում եք, GitOps մեթոդը շատ առավելություններ ունի: Անցած տարվա ընթացքում երկու մոտեցում առանձնահատուկ ժողովրդականություն է ձեռք բերել. Մեկը հիմնված է մղման վրա, մյուսը՝ ձգման վրա: Նախքան դրանց նայելը, եկեք նախ նայենք, թե ինչ տեսք ունեն Kubernetes-ի տիպիկ տեղակայումները:
Տեղակայման մեթոդներ
Վերջին տարիներին Kubernetes-ում ստեղծվել են տեղակայման տարբեր մեթոդներ և գործիքներ.
- Հիմնված է հայրենի Kubernetes/Customize կաղապարների վրա. Սա Kubernetes-ում հավելվածներ տեղակայելու ամենահեշտ ձևն է: Մշակողը ստեղծում է հիմնական YAML ֆայլերը և կիրառում դրանք: Նույն ձևանմուշները անընդհատ վերաշարադրելուց ազատվելու համար մշակվել է Kustomize-ը (այն Kubernetes-ի կաղապարները վերածում է մոդուլների): Նշում. թարգմ.Kustomize-ը ինտեգրվել է kubectl-ին .
- Սաղավարտի գծապատկերներ. Ղեկի գծապատկերները թույլ են տալիս ստեղծել կաղապարների հավաքածուներ, սկզբնական բեռնարկղեր, կողային վահանակներ և այլն, որոնք օգտագործվում են հարմարեցման ավելի ճկուն տարբերակներով հավելվածներ տեղադրելու համար, քան կաղապարների վրա հիմնված մոտեցման դեպքում: Այս մեթոդը հիմնված է կաղապարված YAML ֆայլերի վրա: Helm-ը դրանք լցնում է տարբեր պարամետրերով, այնուհետև ուղարկում է Tiller-ին՝ կլաստերային բաղադրիչ, որը տեղակայում է դրանք կլաստերում և թույլ է տալիս թարմացումներ և հետադարձումներ կատարել: Կարևորն այն է, որ Helm-ը, ըստ էության, պարզապես տեղադրում է ցանկալի արժեքները ձևանմուշների մեջ և այնուհետև դրանք կիրառում է նույն կերպ, ինչպես դա արվում է ավանդական մոտեցմամբ: (Կարդացեք ավելին այն մասին, թե ինչպես է այն աշխատում և ինչպես կարող եք օգտագործել այն մեր կայքում - մոտ. թարգմ.). Գոյություն ունեն պատրաստի Helm գծապատկերների լայն տեսականի, որոնք ընդգրկում են խնդիրների լայն շրջանակ:
- Այլընտրանքային գործիքներ. Կան բազմաթիվ այլընտրանքային գործիքներ: Նրանց բոլորի ընդհանուրն այն է, որ նրանք որոշ կաղապարային ֆայլեր վերածում են Kubernetes-ով ընթեռնելի YAML ֆայլերի, այնուհետև օգտագործում են դրանք:
Մեր աշխատանքում մենք անընդհատ օգտագործում ենք Helm գծապատկերները կարևոր գործիքների համար (քանի որ դրանք արդեն պատրաստ շատ բաներ ունեն, ինչը շատ ավելի հեշտ է դարձնում կյանքը) և «մաքուր» Kubernetes YAML ֆայլեր՝ մեր սեփական հավելվածները տեղակայելու համար:
Քաշեք և հրում
Իմ վերջին բլոգային գրառումներից մեկում ես ներկայացրեցի գործիքը , որը թույլ է տալիս կաղապարներ մուտքագրել Git պահոցը և թարմացնել տեղակայումը կոնտեյների յուրաքանչյուր կատարումից կամ մղումից հետո: Իմ փորձը ցույց է տալիս, որ այս գործիքը հիմնականներից մեկն է ձգողական մոտեցումը խթանելու գործում, ուստի ես հաճախ կանդրադառնամ դրան: Եթե ցանկանում եք ավելին իմանալ, թե ինչպես օգտագործել այն, այստեղ .
NB! GitOps-ի օգտագործման բոլոր առավելությունները մնում են նույնը երկու մոտեցումների համար:
Քաշի վրա հիմնված մոտեցում
Ձգողական մոտեցումը հիմնված է այն փաստի վրա, որ բոլոր փոփոխությունները կիրառվում են կլաստերի ներսում: Կլաստերի ներսում կա օպերատոր, որը պարբերաբար ստուգում է համապատասխան Git և Docker Registry պահեստները: Եթե նրանց մոտ որևէ փոփոխություն տեղի ունենա, կլաստերի վիճակը թարմացվում է ներսում: Այս գործընթացը սովորաբար համարվում է շատ անվտանգ, քանի որ ոչ մի արտաքին հաճախորդ մուտք չունի կլաստերի ադմինիստրատորի իրավունքները:
Կոալիցիայում:
- Ոչ մի արտաքին հաճախորդ իրավունք չունի փոփոխություններ կատարելու կլաստերի մեջ. բոլոր թարմացումները տարածվում են ներսից:
- Որոշ գործիքներ նաև թույլ են տալիս համաժամացնել Helm աղյուսակի թարմացումները և դրանք կապել կլաստերի հետ:
- Docker Registry-ը կարող է սկանավորվել նոր տարբերակների համար: Եթե հասանելի է նոր պատկեր, ապա Git-ի պահոցը և տեղակայումը թարմացվում են նոր տարբերակով:
- Pull գործիքները կարող են բաշխվել տարբեր անվանատարածքներում՝ տարբեր Git պահոցներով և թույլտվություններով: Դրա շնորհիվ կարող է օգտագործվել բազմաբնակարանային մոդել: Օրինակ՝ A թիմը կարող է օգտագործել A անվանումների տարածքը, B թիմը կարող է օգտագործել B անվանումների տարածքը, իսկ ենթակառուցվածքի թիմը կարող է օգտագործել գլոբալ տարածությունը:
- Որպես կանոն, գործիքները շատ թեթև են։
- Համակցված է այնպիսի գործիքների հետ, ինչպիսիք են օպերատորը , գաղտնիքները կարող են գաղտնագրված պահել Git-ի պահոցում և առբերվել կլաստերի ներսում։
- CD խողովակաշարերի հետ կապ չկա, քանի որ տեղակայումները տեղի են ունենում կլաստերի ներսում:
Դեմ:
- Helm գծապատկերներից տեղակայման գաղտնիքները կառավարելը ավելի դժվար է, քան սովորականները, քանի որ դրանք նախ պետք է գեներացվեն, ասենք, կնքված գաղտնիքների տեսքով, ապա վերծանվեն ներքին օպերատորի կողմից, և միայն դրանից հետո հասանելի դառնան ձգողական գործիքին: Այնուհետև կարող եք գործարկել թողարկումը Helm-ում՝ արդեն տեղադրված գաղտնիքների արժեքներով: Ամենահեշտ ձևը գաղտնիք ստեղծելն է Helm-ի բոլոր արժեքներով, որոնք օգտագործվում են տեղակայման համար, այն վերծանել և հանձնել Git-ին:
- Երբ դուք օգտագործում եք ձգողական մոտեցում, դուք կապվում եք քաշող գործիքների հետ: Սա սահմանափակում է կլաստերի մեջ տեղակայման գործընթացը հարմարեցնելու հնարավորությունը: Օրինակ, Kustomize-ը բարդանում է նրանով, որ այն պետք է գործարկվի մինչև վերջնական ձևանմուշները հանձնվեն Git-ին: Ես չեմ ասում, որ դուք չեք կարող օգտագործել ինքնուրույն գործիքներ, բայց դրանք ավելի դժվար է ինտեգրվել ձեր տեղակայման գործընթացին:
Հրում վրա հիմնված մոտեցում
Հրաժարական մոտեցման դեպքում արտաքին համակարգը (հիմնականում CD խողովակաշարերը) գործարկում է կլաստերի տեղակայումը Git պահոցում կատարելուց հետո կամ եթե նախորդ CI խողովակաշարը հաջող է: Այս մոտեցմամբ համակարգը մուտք ունի դեպի կլաստեր:
Կոալիցիայում:
- Անվտանգությունը որոշվում է Git պահեստի և կառուցման խողովակաշարի կողմից:
- Helm գծապատկերների տեղակայումն ավելի հեշտ է և աջակցում է Helm հավելվածներին:
- Գաղտնիքներն ավելի հեշտ է կառավարել, քանի որ գաղտնիքները կարող են օգտագործվել խողովակաշարերում, ինչպես նաև կարող են պահվել կոդավորված Git-ում (կախված օգտագործողի նախասիրություններից):
- Կապ չկա կոնկրետ գործիքի հետ, քանի որ ցանկացած տեսակի կարող է օգտագործվել:
- Կոնտեյների տարբերակների թարմացումները կարող են իրականացվել կառուցման խողովակաշարի միջոցով:
Դեմ:
- Կլաստերային մուտքի տվյալները գտնվում են կառուցման համակարգի ներսում:
- Տեղակայման բեռնարկղերի թարմացումը դեռևս ավելի հեշտ է ձգման գործընթացով:
- Խիստ կախվածություն CD համակարգից, քանի որ մեզ անհրաժեշտ խողովակաշարերը կարող են ի սկզբանե գրված լինել Gitlab Runners-ի համար, այնուհետև թիմը որոշում է տեղափոխվել Azure DevOps կամ Jenkins... և ստիպված կլինի տեղափոխել մեծ թվով կառուցված խողովակաշարեր:
Արդյունքներ. Հրե՞լ, թե՞ քաշել:
Ինչպես սովորաբար լինում է, յուրաքանչյուր մոտեցում ունի իր դրական և բացասական կողմերը: Որոշ առաջադրանքներ ավելի հեշտ է իրականացնել մեկի հետ, իսկ ավելի դժվար՝ մյուսի հետ: Սկզբում ես ձեռքով էի տեղակայում, բայց երբ հանդիպեցի Weave Flux-ի մասին մի քանի հոդվածների, որոշեցի իրականացնել GitOps գործընթացները բոլոր նախագծերի համար: Հիմնական ձևանմուշների համար սա հեշտ էր, բայց հետո ես սկսեցի դժվարությունների հանդիպել Helm գծապատկերների հետ: Այն ժամանակ Weave Flux-ն առաջարկում էր միայն Helm Chart Operator-ի տարրական տարբերակը, բայց նույնիսկ հիմա որոշ առաջադրանքներ ավելի բարդ են՝ գաղտնիքներ ձեռքով ստեղծելու և դրանք կիրառելու անհրաժեշտության պատճառով: Դուք կարող եք պնդել, որ pull մոտեցումը շատ ավելի ապահով է, քանի որ կլաստերի հավատարմագրերը հասանելի չեն կլաստերի սահմաններից դուրս, ինչը այն դարձնում է ավելի ապահով, որ արժե հավելյալ ջանք գործադրել:
Որոշ մտածելուց հետո ես եկա անսպասելի եզրակացության, որ դա այդպես չէ։ Եթե խոսենք բաղադրիչների մասին, որոնք պահանջում են առավելագույն պաշտպանություն, ապա այս ցանկը կներառի գաղտնի պահեստավորում, CI/CD համակարգեր և Git պահեստներ։ Նրանց ներսում եղած տեղեկատվությունը շատ խոցելի է և առավելագույն պաշտպանության կարիք ունի։ Բացի այդ, եթե ինչ-որ մեկը մտնի ձեր Git պահոց և կարողանա այնտեղ սեղմել կոդը, նրանք կարող են տեղակայել այն, ինչ ուզում են (լինի դա քաշել, թե հրել) և ներթափանցել կլաստերի համակարգեր: Այսպիսով, ամենակարևոր բաղադրիչները, որոնք պետք է պաշտպանված լինեն, Git պահեստն ու CI/CD համակարգերն են, այլ ոչ թե կլաստերի հավատարմագրերը: Եթե դուք ունեք լավ կազմաձևված քաղաքականություն և անվտանգության վերահսկում այս տեսակի համակարգերի համար, և կլաստերի հավատարմագրերը արդյունահանվում են միայն խողովակաշարերի մեջ՝ որպես գաղտնիք, ապա ձգողական մոտեցման հավելյալ անվտանգությունը կարող է այնքան արժեքավոր չլինել, որքան ենթադրվում էր սկզբում:
Այսպիսով, եթե pull մոտեցումն ավելի աշխատատար է և անվտանգության առավելություն չի տալիս, տրամաբանական չէ՞ օգտագործել միայն հրում մոտեցումը: Բայց ինչ-որ մեկը կարող է պնդել, որ push մոտեցման դեպքում դուք չափազանց կապված եք CD համակարգի հետ և, հավանաբար, ավելի լավ է դա չանել, որպեսզի հետագայում ավելի հեշտ լինի միգրացիաներ իրականացնել:
Իմ կարծիքով (ինչպես միշտ), դուք պետք է օգտագործեք այն, ինչը առավել հարմար է կոնկրետ դեպքի կամ կոմբինատի համար: Անձամբ ես օգտագործում եմ երկու մոտեցումներն էլ՝ Weave Flux-ը ձգողականության վրա հիմնված տեղակայումների համար, որոնք հիմնականում ներառում են մեր սեփական ծառայությունները, և հուզական մոտեցում Helm-ի և plugins-ի հետ, ինչը հեշտացնում է Helm գծապատկերները կլաստերի վրա և թույլ է տալիս անխափան ստեղծել գաղտնիքներ: Կարծում եմ, որ երբեք չի լինի մեկ լուծում, որը հարմար է բոլոր դեպքերի համար, քանի որ միշտ կան շատ նրբերանգներ, և դրանք կախված են կոնկրետ կիրառությունից։ Այսպես ասվեց, ես բարձր խորհուրդ եմ տալիս GitOps-ը. այն շատ է հեշտացնում կյանքը և բարելավում անվտանգությունը:
Հուսով եմ, որ այս թեմայի վերաբերյալ իմ փորձը կօգնի ձեզ որոշել, թե որ մեթոդն է ավելի հարմար ձեր տեղակայման տեսակի համար, և ես ուրախ կլինեմ լսել ձեր կարծիքը:
Հ.Գ Նշում թարգմանչից
Ձգվող մոդելի բացասական կողմն այն է, որ դժվար է արտապատկերված մանիֆեստները տեղադրել Git-ում, բայց ոչ մի բացասական կողմ չկա այն, որ pull մոդելի CD խողովակաշարն ապրում է շրջանառությունից առանձին և ըստ էության դառնում է կատեգորիայի խողովակաշար: Շարունակական Դիմում. Հետևաբար, էլ ավելի մեծ ջանքեր կպահանջվեն բոլոր տեղակայումներից դրանց կարգավիճակը հավաքելու և գրանցամատյաններին/կարգավիճակին ինչ-որ կերպ հասանելիություն ապահովելու համար, նախընտրելի է CD համակարգի հղումով:
Այս առումով, push մոդելը թույլ է տալիս մեզ տրամադրել թողարկման առնվազն որոշ երաշխիքներ, քանի որ խողովակաշարի ծառայության ժամկետը կարող է հավասարվել թողարկման ժամկետին:
Մենք փորձեցինք երկու մոդելները և եկանք նույն եզրակացությունների, ինչ հոդվածի հեղինակը.
- Ձգող մոդելը մեզ հարմար է մեծ թվով կլաստերների վրա համակարգի բաղադրիչների թարմացումներ կազմակերպելու համար (տես. ).
- GitLab CI-ի վրա հիմնված push մոդելը լավ հարմարեցված է Helm գծապատկերների օգտագործմամբ հավելվածները տարածելու համար: Միևնույն ժամանակ, խողովակաշարերի ներսում տեղակայումների տեղակայումը վերահսկվում է գործիքի միջոցով . Ի դեպ, մեր այս նախագծի համատեքստում մենք լսեցինք մշտական «GitOps»-ը, երբ քննարկեցինք DevOps-ի ինժեներների հրատապ խնդիրները KubeCon Europe'19-ում մեր ստենդում:
PPS թարգմանիչից
Կարդացեք նաև մեր բլոգում.
- «";
- «";
- «";
- «.
Հարցմանը կարող են մասնակցել միայն գրանցված օգտվողները։ , խնդրում եմ:
Դուք օգտագործում եք GitOps-ը:
-
Այո, քաշեք մոտեցեք
-
Այո, հրում
-
Այո, քաշեք + հրեք
-
Այո, մեկ այլ բան
-
Ոչ
Քվեարկել է 30 օգտատեր։ 10 օգտատեր ձեռնպահ է մնացել։
Source: www.habr.com