GitOps. ևս մեկ բառ, թե՞ առաջընթաց ավտոմատացման մեջ:

Մեզանից շատերը, նկատելով մեկ այլ նոր տերմին ՏՏ բլոգոլորտում կամ կոնֆերանսում, վաղ թե ուշ տալիս են նմանատիպ հարց. «Ի՞նչ է սա: Պարզապես ևս մեկ բռունցք, «զանգվածային բառ», թե՞ իսկապես արժանի մի բան, որը արժանի է ուշադրության, ուսումնասիրության և նոր հորիզոնների խոստմանը»: Նույնը ինձ հետ եղավ տերմինի հետ կապված GitOps որոշ ժամանակ առաջ. Զինված բազմաթիվ առկա հոդվածներով, ինչպես նաև ընկերության գործընկերների գիտելիքներով Գիտլաբը, ես փորձեցի պարզել, թե ինչ գազան է սա, և ինչպիսին կարող է լինել դրա օգտագործումը գործնականում:

Ի դեպ, տերմինի նորության մասին GitOps Մեր վերջին հարցումը նաև ասում է. հարցվածների կեսից ավելին դեռ չի սկսել աշխատել դրա սկզբունքներով։

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

Ամպային ծառայությունները շատ հաջող կատարեցին այս պահանջները, և հենց նրանք զգալի խթան հաղորդեցին մոտեցման զարգացմանը IaC. Սա հասկանալի է։ Ի վերջո, նրանք հնարավորություն տվեցին կարգավորել ամբողջովին վիրտուալ տվյալների կենտրոնը. չկան ֆիզիկական սերվերներ, դարակաշարեր կամ ցանցային բաղադրիչներ, ամբողջ ենթակառուցվածքը կարելի է նկարագրել սկրիպտների և կազմաձևման ֆայլերի միջոցով:

Այսպիսով, ո՞րն է տարբերությունը: GitOps - ից IaC? Հենց այս հարցով ես սկսեցի իմ հետաքննությունը: Գործընկերների հետ զրուցելուց հետո ես կարողացա հետևյալ համեմատությունը բերել.

GitOps

IaC

Ամբողջ կոդը պահվում է git պահոցում

Կոդի տարբերակումը պարտադիր չէ

Դեկլարատիվ կոդ Նկարագրություն / Idempotency

Ընդունելի են ինչպես հռչակագրային, այնպես էլ հրամայական նկարագրությունները

Փոփոխություններն ուժի մեջ են մտնում Merge Request/Pull Request մեխանիզմների միջոցով

Համաձայնագիրը, հաստատումը և համագործակցությունը պարտադիր չեն

Թարմացման տեղադրման գործընթացը ավտոմատացված է

Թարմացման տեղադրման գործընթացը ստանդարտացված չէ (ավտոմատ, ձեռքով, ֆայլերի պատճենում, հրամանի տողի օգտագործում և այլն):

Այլ կերպ ասած GitOps ծնվել է հենց սկզբունքների կիրառմամբ IaC. Նախ, ենթակառուցվածքները և կոնֆիգուրացիան այժմ կարող են պահվել այնպես, ինչպես հավելվածները: Կոդը հեշտ է պահել, հեշտ է համօգտագործել, համեմատել և օգտագործել տարբերակման հնարավորությունները: Տարբերակներ, ճյուղեր, պատմություն. Եվ այս ամենը մի վայրում, որը հանրությանը հասանելի է ողջ թիմի համար: Ուստի տարբերակների կառավարման համակարգերի օգտագործումը դարձավ միանգամայն բնական զարգացում։ Մասնավորապես, git-ը, որպես ամենատարածված:

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

Հետաքրքրասիրություն GitOps, իհարկե, նաև այն փաստով, որ դա որևէ վաճառողի հետ կապված արտադրանք, պլագին կամ հարթակ չէ: Դա ավելի շատ պարադիգմ է և սկզբունքների մի շարք, որը նման է մեզ ծանոթ մեկ այլ տերմինի՝ DevOps:

Ընկերությունը Գիտլաբը մենք մշակել ենք այս նոր տերմինի երկու սահմանում՝ տեսական և գործնական: Սկսենք տեսականից.

GitOps-ը մեթոդաբանություն է, որն ընդունում է հավելվածների մշակման համար օգտագործվող DevOps-ի լավագույն սկզբունքները, ինչպիսիք են տարբերակների վերահսկումը, համագործակցությունը, նվագախումբը, CI/CD-ն և կիրառում դրանք ենթակառուցվածքների կառավարման ավտոմատացման մարտահրավերներին:

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

Գործնական տեսանկյունից մենք նկարագրում ենք GitOps հետեւյալ կերպ.

Մենք արդեն քննարկել ենք ենթակառուցվածքը որպես կոդ՝ որպես այս բանաձևի հիմնական բաղադրիչներից մեկը: Ներկայացնենք մնացած մասնակիցներին.

Միաձուլման հարցում (այլընտրանքային անուն Pull Request): Գործընթացի առումով, MR-ը կոդի փոփոխությունները կիրառելու և այնուհետև մասնաճյուղերը միացնելու հարցում է: Բայց մեր օգտագործած գործիքների առումով սա ավելի շատ հնարավորություն է ամբողջական պատկերացում կազմել կատարվող բոլոր փոփոխությունների մասին. վերջնական ակնկալվող արդյունքը. Եթե ​​խոսում ենք ենթակառուցվածքային կոդի մասին, ապա մեզ հետաքրքրում է, թե կոնկրետ ինչպես է փոխվելու ենթակառուցվածքը, քանի՞ նոր ռեսուրս կավելացվի կամ հեռացվի, փոխվի։ Ցանկալի է ավելի հարմար և հեշտ ընթերցվող ձևաչափով: Ամպային մատակարարների համար լավ գաղափար է իմանալ, թե ինչպիսի ֆինանսական ազդեցություն կունենա այս փոփոխությունը:

Բայց MR-ը նաև համագործակցության, փոխազդեցության և հաղորդակցության միջոց է: Այն վայրը, որտեղ գործում է հակակշիռների և հակակշիռների համակարգը։ Պարզ մեկնաբանություններից մինչև պաշտոնական հաստատումներ և հաստատումներ:

Դե, վերջին բաղադրիչը. CI/CD-ն, ինչպես արդեն գիտենք, հնարավորություն է տալիս ավտոմատացնել ենթակառուցվածքի փոփոխությունների և թեստավորման գործընթացը (շարահյուսության պարզ ստուգումից մինչև ավելի բարդ ստատիկ կոդի վերլուծություն): Եվ նաև դրեյֆի հետագա հայտնաբերման մեջ. տարբերություններ համակարգի իրական և ցանկալի վիճակի միջև: Օրինակ՝ ձեռքով չթույլատրված փոփոխությունների կամ համակարգի ձախողման արդյունքում։

Այո, ժամկետը GitOps մեզ ոչ մի բոլորովին նոր բան չի ներկայացնում, չի հայտնագործում անիվը, այլ պարզապես կիրառում է արդեն իսկ կուտակված փորձը նոր ոլորտում: Բայց հենց այստեղ է նրա ուժը։

Եվ եթե հանկարծ ձեզ հետաքրքրի, թե ինչպես է այս ամենը գործնականում երևում, ապա ես ձեզ հրավիրում եմ նայել մեր Մաստեր Կլաս, որտեղ ես քայլ առ քայլ ասում եմ ձեզ, թե ինչպես օգտագործել GitLab-ը.

• Իրականացնել GitOps-ի հիմնական սկզբունքները

• Ստեղծեք և փոփոխություններ կատարեք ամպային ենթակառուցվածքում (օգտագործելով Yandex Cloud-ի օրինակը)

• Ավտոմատացրեք համակարգի շեղման հայտնաբերումը ցանկալի վիճակից՝ օգտագործելով ակտիվ մոնիտորինգ

https://bit.ly/34tRpwZ

Source: www.habr.com