Ինչ է GitOps-ը:

Նշում. թարգմ.Վերջերս հրապարակումից հետո նյութը GitOps-ում քաշելու և մղելու մեթոդների մասին, մենք ընդհանուր առմամբ հետաքրքրություն տեսանք այս մոդելի նկատմամբ, բայց այս թեմայով ռուսալեզու հրապարակումներ շատ քիչ էին (ուղղակի Habré-ում չկան): Հետևաբար, մենք ուրախ ենք ձեր ուշադրությանն առաջարկել մեկ այլ հոդվածի թարգմանություն, թեև գրեթե մեկ տարի առաջ: — Weaveworks-ից, որի ղեկավարը հորինել է «GitOps» տերմինը։ Տեքստը բացատրում է մոտեցման էությունը և առկաներից հիմնական տարբերությունները:

Մեկ տարի առաջ հրապարակեցինք GitOps-ի ներածություն. Այն ժամանակ մենք կիսվեցինք, թե ինչպես Weaveworks թիմը գործարկեց SaaS ամբողջովին Kubernetes-ի վրա հիմնված և մշակեց մի շարք հանձնարարական լավագույն փորձեր՝ ամպային բնիկ միջավայրում տեղակայելու, կառավարելու և մոնիտորինգի համար:

Հոդվածը հայտնի դարձավ. Այլ մարդիկ սկսեցին խոսել GitOps-ի մասին և սկսեցին նոր գործիքներ հրապարակել գնալ մղել, զարգացում, գաղտնիքները, գործառույթները, շարունակական ինտեգրում եւ այլն։ Հայտնվել է մեր կայքում մեծ թվով հրապարակումներ և GitOps-ի օգտագործման դեպքեր: Բայց որոշ մարդիկ դեռ հարցեր ունեն. Ինչո՞վ է մոդելը տարբերվում ավանդականից: ենթակառուցվածքը որպես ծածկագիր և շարունակական առաքում (շարունակական առաքում)? Արդյո՞ք անհրաժեշտ է Kubernetes օգտագործել:

Մենք շուտով հասկացանք, որ անհրաժեշտ է նոր նկարագրություն՝ առաջարկելով.

1. Մեծ թվով օրինակներ և պատմություններ;
2. GitOps-ի հատուկ սահմանում;
3. Համեմատություն ավանդական շարունակական առաքման հետ:

Այս հոդվածում մենք փորձել ենք անդրադառնալ այս բոլոր թեմաներին: Այն ապահովում է GitOps-ի թարմացված ներածություն և մշակողի և CI/CD-ի հեռանկարը: Մենք հիմնականում կենտրոնանում ենք Kubernetes-ի վրա, թեև մոդելը կարելի է ընդհանրացնել:

Հանդիպեք GitOps-ին

Պատկերացրեք Ալիսին։ Նա ղեկավարում է «Family Insurance»-ը, որն առաջարկում է առողջության, ավտոմեքենայի, տան և ճանապարհորդական ապահովագրություն այն մարդկանց, ովքեր չափազանց զբաղված են, որպեսզի իրենք կարողանան պարզել պայմանագրերի մանրամասները: Նրա բիզնեսը սկսվեց որպես կողմնակի նախագիծ, երբ Ալիսը աշխատում էր բանկում որպես տվյալների գիտնական: Մի օր նա հասկացավ, որ կարող է օգտագործել առաջադեմ համակարգչային ալգորիթմներ՝ տվյալների ավելի արդյունավետ վերլուծության և ապահովագրական փաթեթներ ձևակերպելու համար: Ներդրողները ֆինանսավորեցին նախագիծը, և այժմ նրա ընկերությունը տարեկան ավելի քան 20 միլիոն դոլար եկամուտ է բերում և արագ աճում է: Ներկայումս տարբեր պաշտոններում աշխատում է 180 մարդ։ Սա ներառում է տեխնոլոգիական թիմ, որը մշակում, պահպանում է կայքը, տվյալների բազան և վերլուծում հաճախորդների բազան: 60 հոգուց բաղկացած թիմը գլխավորում է ընկերության տեխնիկական տնօրեն Բոբը։

Բոբի թիմը արտադրական համակարգեր է տեղակայում ամպի մեջ: Նրանց հիմնական հավելվածներն աշխատում են GKE-ում՝ օգտվելով Kubernetes-ից Google Cloud-ում: Բացի այդ, նրանք իրենց աշխատանքում օգտագործում են տարբեր տվյալների և վերլուծական գործիքներ:

Family Insurance-ը չձեռնարկվեց օգտագործել բեռնարկղեր, բայց ընկավ Docker-ի խանդավառության մեջ: Շուտով ընկերությունը հայտնաբերեց, որ GKE-ն հեշտացրել է կլաստերների տեղակայումը նոր հնարավորություններ փորձարկելու համար: Jenkins CI-ի և Quay-ի համար ավելացվել են կոնտեյներների ռեեստրը կազմակերպելու համար, գրվել են սկրիպտներ Ջենքինսի համար, որոնք նոր կոնտեյներներ և կոնֆիգուրացիաներ են մղել GKE:

Որոշ ժամանակ է անցել։ Ալիսն ու Բոբը հիասթափված էին իրենց ընտրած մոտեցման կատարումից և բիզնեսի վրա դրա ազդեցությունից: Բեռնարկղերի ներդրումը չի բարելավել արտադրողականությունը այնքան, որքան հույս ուներ թիմը: Երբեմն տեղակայումները կոտրվում էին, և անհասկանալի էր, թե արդյոք կոդի փոփոխություններն են մեղավոր: Պարզվեց նաև, որ դժվար է հետևել կազմաձևերի փոփոխություններին: Հաճախ անհրաժեշտ էր ստեղծել նոր կլաստեր և հավելվածներ տեղափոխել դրան, քանի որ դա ամենահեշտ ձևն էր վերացնելու այն խառնաշփոթը, որը դարձել էր համակարգը: Ալիսը վախենում էր, որ հավելվածի զարգացմանը զուգահեռ իրավիճակը կվատթարանա (ի լրումն, մեքենայական ուսուցման վրա հիմնված նոր նախագիծ էր պատրաստվում): Բոբը ավտոմատացրել էր աշխատանքի մեծ մասը և չէր հասկանում, թե ինչու էր խողովակաշարը դեռ անկայուն, լավ չէր ծավալվում և պարբերաբար ձեռքով միջամտություն էր պահանջում:

Հետո նրանք իմացան GitOps-ի մասին: Այս որոշումը պարզվեց հենց այն, ինչ նրանց անհրաժեշտ էր վստահորեն առաջ գնալու համար։

Ալիսն ու Բոբը տարիներ շարունակ լսում էին Git-ի, DevOps-ի և ենթակառուցվածքների մասին՝ որպես կոդերի աշխատանքային հոսքեր: GitOps-ի եզակին այն է, որ այն բերում է լավագույն փորձի մի շարք՝ և՛ վերջնական, և՛ նորմատիվ, այս գաղափարներն իրականացնելու համար Kubernetes-ի համատեքստում: Այս թեման բազմիցս բարձրացավ, ներառյալ ներս Weaveworks բլոգ.

Family Insurance-ը որոշում է իրականացնել GitOps-ը: Այժմ ընկերությունն ունի շահագործման ավտոմատացված մոդել, որը համատեղելի է Kubernetes-ի և կոմբայնների հետ արագություն հետ կայունությունորովհետեւ նրանք:

• պարզել է, որ թիմի արտադրողականությունը կրկնապատկվել է՝ առանց որևէ մեկի խելագարվելու.
• դադարեցրել է սցենարների սպասարկումը: Փոխարենը, նրանք այժմ կարող են կենտրոնանալ նոր առանձնահատկությունների վրա և բարելավել ինժեներական մեթոդները.
• մենք կատարելագործել ենք տեղակայման գործընթացն այնպես, որ այն հազվադեպ է փչանում.
• հնարավորություն ստացավ վերականգնել տեղակայումները մասնակի ձախողումներից հետո՝ առանց ձեռքի միջամտության.
• գնված օգտագործվածоԱվելի մեծ վստահություն առաքման համակարգերի նկատմամբ: Ալիսը և Բոբը հայտնաբերեցին, որ նրանք կարող են թիմը բաժանել միկրոսպասարկման թիմերի, որոնք աշխատում են զուգահեռաբար.
• կարող է ամեն օր 30-50 փոփոխություն կատարել նախագծում յուրաքանչյուր խմբի ջանքերով և փորձել նոր տեխնիկա.
• Հեշտ է նախագիծ ներգրավել նոր ծրագրավորողների, ովքեր հնարավորություն ունեն մի քանի ժամվա ընթացքում թարմացումներ ներկայացնել արտադրության մեջ՝ օգտագործելով ձգման հարցումները.
• հեշտությամբ անցնել աուդիտ SOC2-ի շրջանակներում (Ծառայություններ մատուցողների կողմից տվյալների անվտանգ կառավարման պահանջներին համապատասխանության համար, կարդացեք ավելին, օրինակ. այստեղ - մոտ. թարգմ.).

Ինչ է պատահել:

GitOps-ը երկու բան է.

1. Գործառնական մոդել Kubernetes-ի և cloud native-ի համար: Այն տրամադրում է լավագույն փորձի մի շարք կոնտեյներային կլաստերների և հավելվածների տեղակայման, կառավարման և մոնիտորինգի համար: Նրբագեղ սահմանումը ձևով մեկ սլայդ - ից Լուիս Ֆասեյրա:
2. Ծրագրերի վրա հիմնված հավելվածների կառավարման միջավայր ստեղծելու ուղին: Մենք կիրառում ենք Git աշխատանքային հոսքը և՛ գործառնությունների, և՛ զարգացման համար: Խնդրում ենք նկատի ունենալ, որ խոսքը ոչ միայն Git push-ի մասին է, այլ CI/CD և UI/UX գործիքների ամբողջ հավաքածուի կազմակերպման մասին:

Մի քանի խոսք Git-ի մասին

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

Ինչպես է աշխատում Kubernetes-ը

Մեր պատմության մեջ Ալիսն ու Բոբը մի որոշ ժամանակ Kubernetes-ի հետ աշխատելուց հետո դիմեցին GitOps-ին: Իրոք, GitOps-ը սերտորեն կապված է Kubernetes-ի հետ. դա գործառնական մոդել է ենթակառուցվածքների և Kubernetes-ի վրա հիմնված հավելվածների համար:

Ի՞նչ է տալիս Kubernetes-ը օգտվողներին:

Ահա մի քանի հիմնական հատկանիշներ.

1. Kubernetes մոդելում ամեն ինչ կարելի է նկարագրել դեկլարատիվ ձևով։
2. Kubernetes API սերվերն ընդունում է այս հայտարարությունը որպես մուտքագրում և այնուհետև անընդհատ փորձում է կլաստերը բերել հայտարարագրում նկարագրված վիճակի:
3. Հռչակագրերը բավարար են՝ նկարագրելու և կառավարելու աշխատանքային ծանրաբեռնվածության լայն տեսականի՝ «հավելվածներ»:
4. Արդյունքում, հավելվածի և կլաստերի փոփոխությունները տեղի են ունենում հետևյալի պատճառով.
   • կոնտեյների պատկերների փոփոխություններ;
   • դեկլարատիվ բնութագրերի փոփոխություններ.
   • շրջակա միջավայրի սխալներ, օրինակ՝ կոնտեյների վթար:

Kubernetes-ի մեծ կոնվերգենցիայի հնարավորությունները

Երբ ադմինիստրատորը կատարում է կազմաձևման փոփոխություններ, Kubernetes նվագախումբը դրանք կկիրառի կլաստերի վրա, քանի դեռ նրա վիճակը չի մոտենա նոր կոնֆիգուրացիան. Այս մոդելն աշխատում է Kubernetes-ի ցանկացած ռեսուրսի համար և ընդարձակելի է Պատվերով ռեսուրսների սահմանումներով (CRD): Հետևաբար, Kubernetes-ի տեղակայումները ունեն հետևյալ հրաշալի հատկությունները.

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

Ինչպես է աշխատում GitOps-ը

Մենք բավականաչափ սովորել ենք Kubernetes-ի մասին՝ բացատրելու, թե ինչպես է աշխատում GitOps-ը:

Վերադառնանք Family Insurance-ի միկրոսերվիսների թիմերին։ Ի՞նչ են նրանք սովորաբար անում: Նայեք ստորև բերված ցանկին (եթե դրա մեջ որևէ առարկա տարօրինակ կամ անծանոթ է թվում, խնդրում ենք հրաժարվել քննադատությունից և մնալ մեզ հետ): Սրանք ընդամենը Ջենկինսի վրա հիմնված աշխատանքային հոսքերի օրինակներ են: Այլ գործիքների հետ աշխատելիս շատ այլ գործընթացներ կան:

Հիմնական բանն այն է, որ մենք տեսնում ենք, որ յուրաքանչյուր թարմացում ավարտվում է կազմաձևման ֆայլերի և Git պահեստների փոփոխություններով: Git-ի այս փոփոխությունները ստիպում են «GitOps օպերատորին» թարմացնել կլաստերը.

1.Աշխատանքային գործընթաց.Jenkins build - վարպետ մասնաճյուղ.
Առաջադրանքների ցանկ.

• Ջենկինսը պիտակավորված պատկերները մղում է Quay;
• Jenkins-ը հրում է կազմաձևման և Helm գծապատկերները դեպի հիմնական պահեստավորման դույլ;
• Ամպային ֆունկցիան պատճենում է կազմաձևերը և գծապատկերները հիմնական պահեստի դույլից դեպի հիմնական Git պահեստ;
• GitOps օպերատորը թարմացնում է կլաստերը:

2. Jenkins build - ազատում կամ թեժ շտկման ճյուղ:

• Ջենկինսը մղում է չպիտակավորված պատկերները դեպի Quay;
• Ջենկինսը հրում է կազմաձևման և Helm գծապատկերները դեպի բեմականացման պահեստային դույլ;
• Ամպային ֆունկցիան պատճենում է կազմաձևերը և գծապատկերները բեմականացման պահոցից մինչև փուլային Git պահոց;
• GitOps օպերատորը թարմացնում է կլաստերը:

3. Jenkins build - զարգացնել կամ ցուցադրել մասնաճյուղը:

• Ջենկինսը մղում է չպիտակավորված պատկերները դեպի Quay;
• Jenkins-ը դրում է կազմաձևման և Helm գծապատկերները մշակման պահեստավորման դույլի մեջ;
• Ամպային ֆունկցիան պատճենում է կազմաձևերը և գծապատկերները մշակման պահեստի դույլից մինչև զարգացող Git պահոց;
• GitOps օպերատորը թարմացնում է կլաստերը:

4. Նոր հաճախորդի ավելացում:

• Կառավարիչը կամ ադմինիստրատորը (LCM/ops) կանչում է Gradle-ին՝ սկզբնապես տեղակայելու և կարգավորելու ցանցի բեռի հավասարակշռող սարքերը (NLBs);
• LCM/ops-ը կատարում է նոր կազմաձև՝ տեղակայումը թարմացումներին նախապատրաստելու համար.
• GitOps օպերատորը թարմացնում է կլաստերը:

GitOps-ի համառոտ նկարագրությունը

1. Նկարագրեք ամբողջ համակարգի ցանկալի վիճակը՝ օգտագործելով յուրաքանչյուր միջավայրի համար դեկլարատիվ բնութագրերը (մեր պատմության մեջ Բոբի թիմը սահմանում է համակարգի ամբողջ կազմաձևը Git-ում):
   • Git պահոցը ճշմարտության միակ աղբյուրն է ողջ համակարգի ցանկալի վիճակի վերաբերյալ:
   • Ցանկալի վիճակի բոլոր փոփոխությունները կատարվում են Git-ում կատարվող պարտավորությունների միջոցով:
   • Բոլոր ցանկալի կլաստերի պարամետրերը նույնպես դիտելի են հենց կլաստերում: Այս կերպ մենք կարող ենք որոշել, թե արդյոք դրանք համընկնում են (համընկնում, զուգամետ) կամ տարբերվել (տարբերվել, տարանջատվել) ցանկալի և դիտված վիճակներ.
2. Եթե ​​ցանկալի և դիտարկված վիճակները տարբերվում են, ապա.
   • Գոյություն ունի կոնվերգենցիայի մեխանիզմ, որը վաղ թե ուշ ավտոմատ կերպով համաժամացնում է թիրախը և դիտարկվող վիճակները: Կլաստերի ներսում Kubernetes-ը դա անում է:
   • Գործընթացը անմիջապես սկսվում է «կատարված փոփոխության» ահազանգով:
   • Որոշ կարգավորելի ժամանակահատվածից հետո «տարբերման» ահազանգը կարող է ուղարկվել, եթե նահանգները տարբեր են:
3. Այս կերպ, Git-ի բոլոր պարտավորությունները առաջացնում են ստուգելի և ոչ հզոր թարմացումներ կլաստերի համար:
   • Վերադարձը նախկինում ցանկալի վիճակի մերձեցումն է:
4. Կոնվերգենցիան վերջնական է. Դրա առաջացումը նշվում է հետևյալով.
   • Որոշակի ժամանակահատվածի համար տարբեր ազդանշաններ չկան:
   • «կոնվերգացված» ահազանգ (օրինակ՝ webhook, Git writeback event):

Ի՞նչ է տարաձայնությունը:

Կրկին կրկնենք. Կլաստերի բոլոր ցանկալի հատկությունները պետք է դիտարկելի լինեն հենց կլաստերի մեջ.

Տարբերության որոշ օրինակներ.

• Կազմաձևման ֆայլի փոփոխություն Git-ում մասնաճյուղերի միաձուլման պատճառով:
• Կազմաձևման ֆայլի փոփոխություն՝ GUI-ի հաճախորդի կողմից կատարված Git-ի կատարման պատճառով:
• Git-ում PR-ի շնորհիվ ցանկալի վիճակի բազմաթիվ փոփոխություններ, որին հաջորդում են կոնտեյների պատկերի և կազմաձևերի փոփոխությունները:
• Կլաստերի վիճակի փոփոխություն սխալի, ռեսուրսների կոնֆլիկտի պատճառով, որը հանգեցնում է «վատ վարքագծի» կամ ուղղակի պատահական շեղման սկզբնական վիճակից:

Ո՞րն է կոնվերգենցիայի մեխանիզմը:

Մի քանի օրինակներ.

• Բեռնարկղերի և կլաստերների համար կոնվերգենցիայի մեխանիզմը տրամադրվում է Kubernetes-ի կողմից։
• Նույն մեխանիզմը կարող է օգտագործվել Kubernetes-ի վրա հիմնված հավելվածները և դիզայները կառավարելու համար (օրինակ՝ Istio և Kubeflow):
• Ապահովում է Kubernetes-ի, պատկերների պահեստների և Git-ի միջև գործառնական փոխազդեցությունը կառավարելու մեխանիզմ GitOps օպերատոր Weave Flux, որը մաս է կազմում Weave Cloud.
• Բազային մեքենաների համար կոնվերգենցիայի մեխանիզմը պետք է լինի դեկլարատիվ և ինքնավար: Մեր սեփական փորձից կարելի է ասել, որ Terraform ամենամոտն այս սահմանմանը, բայց դեռ պահանջում է մարդու վերահսկողություն: Այս առումով, GitOps-ը ընդլայնում է Ենթակառուցվածքի ավանդույթը՝ որպես կոդ:

GitOps-ը համատեղում է Git-ը Kubernetes-ի հիանալի կոնվերգենցիայի շարժիչի հետ՝ շահագործման մոդել տրամադրելու համար:

GitOps-ը թույլ է տալիս մեզ ասել. Միայն այն համակարգերը, որոնք կարելի է նկարագրել և դիտարկել, կարող են ավտոմատացվել և վերահսկվել.

GitOps-ը նախատեսված է ամբողջ ամպի բնիկ փաթեթի համար (օրինակ՝ Terraform և այլն)

GitOps-ը միայն Kubernetes-ը չէ: Մենք ցանկանում ենք, որ ամբողջ համակարգը դեկլարատիվ վարվի և օգտագործի կոնվերգենցիան: Ամբողջ համակարգ ասելով մենք հասկանում ենք Kubernetes-ի հետ աշխատող միջավայրերի հավաքածու, օրինակ՝ «dev կլաստեր 1», «արտադրություն» և այլն: Յուրաքանչյուր միջավայր ներառում է մեքենաներ, կլաստերներ, հավելվածներ, ինչպես նաև արտաքին ծառայությունների ինտերֆեյսներ, որոնք ապահովում են տվյալներ, մոնիտորինգ։ և այլն։

Ուշադրություն դարձրեք, թե որքան կարևոր է Terraform-ը bootstrapping խնդրի համար այս դեպքում: Kubernetes-ը պետք է տեղակայվի ինչ-որ տեղ, և Terraform-ի օգտագործումը նշանակում է, որ մենք կարող ենք կիրառել նույն GitOps-ի աշխատանքային հոսքերը՝ ստեղծելու կառավարման շերտ, որը հիմնված է Kubernetes-ի և հավելվածների վրա: Սա օգտակար լավագույն փորձ է:

Մեծ ուշադրություն կա GitOps հասկացությունների կիրառման վրա Kubernetes-ի վերևի շերտերում: Այս պահին կան GitOps տիպի լուծումներ Istio-ի, Helm-ի, Ksonnet-ի, OpenFaaS-ի և Kubeflow-ի, ինչպես նաև, օրինակ, Pulumi-ի համար, որոնք ստեղծում են շերտ՝ ամպային մայրենիի համար հավելվածներ մշակելու համար։

Kubernetes CI/CD՝ համեմատելով GitOps-ը այլ մոտեցումների հետ

Ինչպես նշվեց, GitOps-ը երկու բան է.

1. Վերը նկարագրված Kubernetes-ի և cloud native-ի գործառնական մոդելը:
2. Ճանապարհ դեպի մշակողների վրա հիմնված հավելվածների կառավարման միջավայր:

Շատերի համար GitOps-ը հիմնականում աշխատանքային հոսք է, որը հիմնված է Git pushes-ի վրա: Մենք նույնպես սիրում ենք նրան։ Բայց սա դեռ ամենը չէ. եկեք հիմա նայենք CI/CD խողովակաշարերին:

GitOps-ը հնարավորություն է տալիս շարունակական տեղակայում (CD) Kubernetes-ի համար

GitOps-ն առաջարկում է շարունակական տեղակայման մեխանիզմ, որը վերացնում է առանձին «տեղակայման կառավարման համակարգերի» անհրաժեշտությունը: Kubernetes-ն անում է ամբողջ աշխատանքը ձեզ համար:

• Հավելվածի թարմացումը պահանջում է թարմացում Git-ում: Սա գործարքային թարմացում է ցանկալի վիճակին: «Տեղակայումը» այնուհետև կատարվում է կլաստերի ներսում հենց Kubernetes-ի կողմից՝ հիմնվելով թարմացված նկարագրության վրա:
• Կախված Kubernetes-ի աշխատանքի բնույթից՝ այս թարմացումները կոնվերգենտ են: Սա ապահովում է շարունակական տեղակայման մեխանիզմ, որում բոլոր թարմացումները ատոմային են:
• Նշում: Weave Cloud առաջարկում է GitOps օպերատոր, որը միավորում է Git-ը և Kubernetes-ը և թույլ է տալիս CD-ն կատարել՝ համադրելով կլաստերի ցանկալի և ներկա վիճակը:

Առանց kubectl-ի և սցենարների

Դուք պետք է խուսափեք Kubectl-ի օգտագործումից՝ ձեր կլաստերը թարմացնելու համար, և հատկապես խուսափեք սկրիպտներից kubectl հրամանները խմբավորելու համար: Փոխարենը, GitOps խողովակաշարով օգտվողը կարող է թարմացնել իր Kubernetes կլաստերը Git-ի միջոցով:

Առավելությունները ներառում են.

1. Ճիշտ. Թարմացումների մի խումբ կարող է կիրառվել, համընկնել և վերջապես վավերացվել՝ մեզ մոտեցնելով ատոմային տեղակայման նպատակին: Ի հակադրություն, սկրիպտների օգտագործումը չի ապահովում մերձեցման որևէ երաշխիք (այս մասին ավելին ստորև):
2. Безопасность. Մեջբերում Kelsey Hightower. «Սահմանափակեք ձեր Kubernetes կլաստերի մուտքը ավտոմատացման գործիքներին և ադմինիստրատորներին, ովքեր պատասխանատու են այն վրիպազերծելու կամ պահպանելու համար»: տես նաեւ իմ հրապարակումը անվտանգության և տեխնիկական բնութագրերին համապատասխանության մասին, ինչպես նաև հոդված Homebrew-ի կոտրման մասին Ջենկինսի անզգույշ գրված սցենարից հավատարմագրերը գողանալով:
3. Օգտվողի փորձ. Kubectl-ը բացահայտում է Kubernetes օբյեկտի մոդելի մեխանիզմը, որը բավականին բարդ է: Իդեալում, օգտվողները պետք է փոխազդեն համակարգի հետ վերացականության ավելի բարձր մակարդակով: Այստեղ նորից կանդրադառնամ Քելսիին և խորհուրդ կտամ դիտել նման ռեզյումե.

Տարբերությունը CI-ի և CD-ի միջև

GitOps-ը բարելավում է առկա CI/CD մոդելները:

Ժամանակակից CI սերվերը նվագախմբի գործիք է: Մասնավորապես, դա ԿԻ խողովակաշարերի կազմակերպման գործիք է։ Դրանք ներառում են կառուցում, փորձարկում, միաձուլում դեպի բեռնախցիկ և այլն: CI սերվերները ավտոմատացնում են բարդ բազմաքայլ խողովակաշարերի կառավարումը: Ընդհանուր գայթակղություն է Kubernetes-ի թարմացումների մի շարք սցենար գրել և այն գործարկել որպես խողովակաշարի մաս՝ կլաստերի փոփոխությունները մղելու համար: Իրոք, սա այն է, ինչ անում են շատ փորձագետներ: Այնուամենայնիվ, սա օպտիմալ չէ, և ահա թե ինչու.

CI-ն պետք է օգտագործվի բեռնախցիկում թարմացումները մղելու համար, և Kubernetes կլաստերը պետք է փոխվի այդ թարմացումների հիման վրա՝ CD-ն ներսից կառավարելու համար: Մենք դա անվանում ենք քաշեք մոդել CD-ի համար, ի տարբերություն CI push մոդելի: CD-ն մաս է կազմում Runtime նվագախմբում.

Ինչու CI սերվերները չպետք է սկավառակներ անեն Kubernetes-ում ուղղակի թարմացումների միջոցով

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

Եկեք վերադառնանք Ալիսին և Բոբին:

Ի՞նչ խնդիրների են բախվել նրանք։ Bob's CI սերվերը կիրառում է փոփոխությունները կլաստերի վրա, բայց եթե այն խափանվի գործընթացում, Բոբը չի իմանա, թե ինչ վիճակում է (կամ պետք է լինի) կլաստերը կամ ինչպես շտկել այն: Նույնը հաջողության դեպքում է։

Ենթադրենք, որ Բոբի թիմը ստեղծեց նոր պատկեր և այնուհետև կարկատեց իր տեղակայումները՝ պատկերը տեղակայելու համար (բոլորը CI խողովակաշարից):

Եթե ​​պատկերը ստեղծվում է նորմալ, բայց խողովակաշարը ձախողվում է, թիմը պետք է պարզի.

• Թարմացումը գործարկվե՞լ է:
• Արդյո՞ք մենք նոր շինություն ենք սկսում: Արդյո՞ք դա կհանգեցնի անհարկի կողմնակի ազդեցությունների՝ նույն անփոփոխ պատկերի երկու կառուցապատման հնարավորությամբ:
• Արդյո՞ք պետք է սպասենք հաջորդ թարմացմանը՝ նախքան build-ը գործարկելը:
• Կոնկրետ ի՞նչը սխալվեց: Ո՞ր քայլերն են անհրաժեշտ կրկնել (և որոնք են անվտանգ կրկնելու համար):

Git-ի վրա հիմնված աշխատանքային հոսքի ստեղծումը չի երաշխավորում, որ Բոբի թիմը չի հանդիպի այս խնդիրների: Նրանք դեռ կարող են սխալվել commit push-ի, պիտակի կամ որևէ այլ պարամետրի հետ: Այնուամենայնիվ, այս մոտեցումը դեռ շատ ավելի մոտ է բացահայտ ամեն ինչ կամ ոչինչ մոտեցմանը:

Ամփոփելու համար, ահա թե ինչու CI սերվերները չպետք է զբաղվեն CD-ով.

• Թարմացման սցենարները միշտ չէ, որ որոշիչ են. Դրանցում հեշտ է սխալվել:
• CI սերվերները չեն համընկնում դեկլարատիվ կլաստերի մոդելին:
• Դժվար է երաշխավորել անզորությունը։ Օգտագործողները պետք է հասկանան համակարգի խորը իմաստաբանությունը:
• Ավելի դժվար է վերականգնվել մասնակի ձախողումից հետո։

Նշում Helm-ի մասին. Եթե ցանկանում եք օգտագործել Helm-ը, խորհուրդ ենք տալիս այն համատեղել GitOps օպերատորի հետ, ինչպիսին է. Flux-Helm. Սա կօգնի ապահովել կոնվերգենցիան: Հելմն ինքնին ոչ դետերմինիստական ​​է, ոչ էլ ատոմային:

GitOps-ը որպես Kubernetes-ի համար շարունակական առաքում իրականացնելու լավագույն միջոց

Ալիսի և Բոբի թիմն իրականացնում է GitOps-ը և պարզում է, որ շատ ավելի հեշտ է դարձել աշխատել ծրագրային ապահովման արտադրանքների հետ, պահպանել բարձր կատարողականություն և կայունություն: Եկեք ավարտենք այս հոդվածը նկարազարդմամբ, որը ցույց է տալիս, թե ինչպիսին է նրանց նոր մոտեցումը: Հիշեք, որ մենք հիմնականում խոսում ենք հավելվածների և ծառայությունների մասին, սակայն GitOps-ը կարող է օգտագործվել մի ամբողջ հարթակ կառավարելու համար:

Գործող մոդել Kubernetes-ի համար

Նայեք հետևյալ գծապատկերին. Այն ներկայացնում է Git-ը և կոնտեյների պատկերների պահոցը որպես ընդհանուր ռեսուրսներ երկու կազմակերպված կյանքի ցիկլի համար.

• Շարունակական ինտեգրացիոն խողովակաշար, որը կարդում և գրում է ֆայլեր Git-ում և կարող է թարմացնել կոնտեյների պատկերների պահեստը:
• Runtime GitOps խողովակաշար, որը համատեղում է տեղակայումը կառավարման և դիտարկելիության հետ: Այն կարդում և գրում է ֆայլեր Git-ում և կարող է ներբեռնել կոնտեյների պատկերներ:

Որո՞նք են հիմնական բացահայտումները:

1. Մտահոգությունների տարանջատումԽնդրում ենք նկատի ունենալ, որ երկու խողովակաշարերն էլ կարող են հաղորդակցվել միայն Git-ը կամ պատկերների պահոցը թարմացնելու միջոցով: Այլ կերպ ասած, կա firewall CI-ի և գործարկման միջավայրի միջև: Մենք այն անվանում ենք «անփոփոխելիության firewall» (անփոփոխելիության firewall), քանի որ պահոցի բոլոր թարմացումները ստեղծում են նոր տարբերակներ։ Այս թեմայի վերաբերյալ լրացուցիչ տեղեկությունների համար տես 72-87 սլայդները այս ներկայացումը.
2. Դուք կարող եք օգտագործել ցանկացած CI և Git սերվերGitOps-ն աշխատում է ցանկացած բաղադրիչի հետ: Դուք կարող եք շարունակել օգտագործել ձեր սիրած CI և Git սերվերները, պատկերների պահեստները և թեստային փաթեթները: Շուկայում գործող գրեթե բոլոր այլ շարունակական առաքման գործիքները պահանջում են իրենց սեփական CI/Git սերվերը կամ պատկերների պահեստը: Սա կարող է սահմանափակող գործոն դառնալ ամպային բնիկի զարգացման գործում: GitOps-ի միջոցով կարող եք օգտագործել ծանոթ գործիքներ:
3. Իրադարձությունները որպես ինտեգրման գործիքՀենց որ Git-ի տվյալները թարմացվեն, Weave Flux-ը (կամ Weave Cloud օպերատորը) տեղեկացնում է գործարկման ժամանակը: Ամեն անգամ, երբ Kubernetes-ն ընդունում է փոփոխությունների հավաքածու, Git-ը թարմացվում է: Սա ապահովում է GitOps-ի համար աշխատանքային հոսքերի կազմակերպման պարզ ինտեգրացիոն մոդել, ինչպես ցույց է տրված ստորև:

Ամփոփում

GitOps-ն ապահովում է թարմացման ուժեղ երաշխիքներ, որոնք պահանջվում են ցանկացած ժամանակակից CI/CD գործիքի համար.

• ավտոմատացում;
• կոնվերգենցիա;
• անզորություն;
• դետերմինիզմ.

Սա կարևոր է, քանի որ այն առաջարկում է գործառնական մոդել ամպի բնիկ մշակողների համար:

• Համակարգերի կառավարման և մոնիտորինգի ավանդական գործիքները կապված են գործառնական թիմերի հետ, որոնք գործում են վազքագրքի շրջանակներում (սովորական ընթացակարգերի և գործողությունների մի շարք - մոտավորապես թարգմանություն), կապված կոնկրետ տեղակայման հետ:
• Ամպային բնիկ կառավարման մեջ դիտարկելիության գործիքները տեղակայման արդյունքները չափելու լավագույն միջոցն են, որպեսզի մշակող թիմը կարողանա արագ արձագանքել:

Պատկերացրեք բազմաթիվ կլաստերներ, որոնք ցրված են տարբեր ամպերի վրա և բազմաթիվ ծառայություններ իրենց թիմերով և տեղակայման պլաններով: GitOps-ն առաջարկում է մասշտաբով անփոփոխ մոդել այս ողջ առատությունը կառավարելու համար:

PS թարգմանչից

Կարդացեք նաև մեր բլոգում.

• «GitOps. Քաշելու և մղելու մեթոդների համեմատություն";
• «Ներկայացնում ենք Kubedog գրադարանը Kubernetes-ի ռեսուրսների մոնիտորինգի համար";
• «Kubernetes-ի ընդլայնում և լրացում (ակնարկ և վիդեո զեկույց).

Հարցմանը կարող են մասնակցել միայն գրանցված օգտվողները։ Մուտք գործել, խնդրում եմ:

Դուք գիտեի՞ք GitOps-ի մասին նախքան այս երկու թարգմանությունների հայտնվելը Habré-ում:

• Այո, ես ամեն ինչ գիտեի

• Միայն մակերեսորեն

• Ոչ

Քվեարկել է 35 օգտատեր։ 10 օգտատեր ձեռնպահ է մնացել։

Source: www.habr.com