Ենթակառուցվածքը որպես ծածկագիր՝ առաջին ծանոթություն

Մեր ընկերությունը գտնվում է SRE թիմում ներգրավելու գործընթացում: Այս ամբողջ պատմության մեջ ես մտա զարգացման կողմից: Ընթացքում ես հայտնեցի մտքեր և պատկերացումներ, որոնք ուզում եմ կիսվել այլ մշակողների հետ: Այս արտացոլման հոդվածում ես խոսում եմ այն ​​մասին, թե ինչ է տեղի ունենում, ինչպես է դա տեղի ունենում, և ինչպես կարող են բոլորը շարունակել ապրել դրա հետ:

Մեր ներքին միջոցառման ելույթների հիման վրա գրված հոդվածաշարի շարունակությունը DevForum:

1. Շրյոդինգերի կատուն առանց տուփի. կոնսենսուսի խնդիրը բաշխված համակարգերում:
2. Ենթակառուցվածքը որպես ծածկագիր. (Դու այստեղ ես)
3. Typescript պայմանագրերի ստեղծում՝ օգտագործելով C# մոդելները: (Ընթացքի մեջ է...)
4. Ներածություն Raft կոնսենսուսի ալգորիթմին: (Ընթացքի մեջ է...)
...

Մենք որոշեցինք ստեղծել SRE թիմ՝ իրականացնելով գաղափարները google sre. Նրանք հավաքագրեցին ծրագրավորողներ իրենց սեփական ծրագրավորողներից և ուղարկեցին նրանց մի քանի ամսով վերապատրաստվելու:

Թիմն ուներ հետևյալ մարզական խնդիրները.

• Նկարագրեք մեր ենթակառուցվածքը, որը հիմնականում Microsoft Azure-ում է կոդի տեսքով (Terraform և շուրջբոլորը):
• Սովորեցրեք մշակողներին, թե ինչպես աշխատել ենթակառուցվածքների հետ:
• Պատրաստել ծրագրավորողներին աշխատանքային պարտականությունների համար:

Մենք ներկայացնում ենք Ենթակառուցվածք հասկացությունը որպես ծածկագիր

Աշխարհի սովորական մոդելում (դասական վարչարարություն) ենթակառուցվածքների մասին գիտելիքները տեղակայված են երկու տեղում.

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

Երկու դեպքում էլ մենք հայտնվում ենք կախվածության մեջ.

• կամ այն ​​մարդուց, ով մահկանացու է, ենթակա է հիվանդության, սիրահարվածության, տրամադրության փոփոխության և պարզապես սովորական աշխատանքից ազատվելու.
• կամ ֆիզիկապես աշխատող մեքենայից, որը նույնպես ընկնում է, գողանում, անակնկալներ ու անհարմարություններ է ներկայացնում։

Անշուշտ պետք է ասել, որ իդեալականորեն ամեն ինչ պետք է թարգմանվի մարդու կողմից ընթեռնելի, պահպանվող, լավ գրված կոդով:

Այսպիսով, ենթակառուցվածքը որպես ծածկագիր (Incfastructure as Code - IaC) ամբողջ գոյություն ունեցող ենթակառուցվածքի նկարագրությունն է կոդի տեսքով, ինչպես նաև դրա հետ աշխատելու և դրանից իրական ենթակառուցվածքի ներդրման հարակից գործիքներ:

Ինչու՞ ամեն ինչ թարգմանել կոդով:Մարդիկ մեքենաներ չեն. Նրանք չեն կարողանում ամեն ինչ հիշել։ Մարդու և մեքենայի արձագանքը տարբեր է. Ավտոմատացված ցանկացած բան պոտենցիալ ավելի արագ է, քան մարդու կողմից արված ցանկացած բան: Ամենակարևորը ճշմարտության մեկ աղբյուրն է։

Որտեղի՞ց են գալիս SRE-ի նոր ինժեներները:Այսպիսով, մենք որոշեցինք աշխատանքի ընդունել նոր SRE ինժեներների, բայց որտեղի՞ց դրանք ձեռք բերել: Գիրք ճիշտ պատասխաններով (Google SRE Գիրք) պատմում է մեզ՝ մշակողների կողմից։ Ի վերջո, նրանք աշխատում են կոդով, և դու հասնում ես իդեալական վիճակի։

Մենք երկար ժամանակ նրանց համար շատ էինք փնտրում մեր ընկերությունից դուրս կադրային շուկայում: Բայց մենք պետք է խոստովանենք, որ մենք չգտանք որևէ մեկին, որը համապատասխանում է մեր խնդրանքներին: Ստիպված էի փնտրել սեփական ժողովրդի մեջ։

Խնդիրներ Ենթակառուցվածքը որպես ծածկագիր

Հիմա եկեք նայենք օրինակներին, թե ինչպես ենթակառուցվածքը կարող է կոշտ կոդավորվել կոդի մեջ: Կոդը լավ գրված է, որակյալ, մեկնաբանություններով և ներքևումներով։

Օրինակ կոդ Terraforma-ից:

Օրինակ կոդ Ansible-ից:

Պարոնայք, եթե միայն այդքան պարզ լիներ: Մենք իրական աշխարհում ենք, և այն միշտ պատրաստ է զարմացնել ձեզ, ներկայացնել անակնկալներ և խնդիրներ։ Այստեղ նույնպես առանց նրանց չի կարող:

1. Առաջին խնդիրն այն է, որ շատ դեպքերում IaC-ն ինչ-որ dsl է:

Իսկ DSL-ն իր հերթին կառուցվածքի նկարագրությունն է։ Ավելի ճիշտ, այն, ինչ դուք պետք է ունենաք. Json, Yaml, փոփոխություններ որոշ խոշոր ընկերություններից, որոնք եկել են իրենց սեփական dsl-ով (HCL-ն օգտագործվում է terraform-ում):

Խնդիրն այն է, որ այն կարող է հեշտությամբ չպարունակել այնպիսի ծանոթ բաներ, ինչպիսիք են.

• փոփոխականներ;
• պայմաններ;
• ինչ-որ տեղ մեկնաբանություններ չկան, օրինակ, Json-ում, լռելյայն դրանք չեն տրամադրվում;
• գործառույթներ;
• և ես նույնիսկ չեմ խոսում այնպիսի բարձր մակարդակի բաների մասին, ինչպիսիք են դասերը, ժառանգությունը և այդ ամենը:

2. Նման կոդի երկրորդ խնդիրն այն է, որ ամենից հաճախ դա տարասեռ միջավայր է. Սովորաբար դուք նստում և աշխատում եք C#-ով, այսինքն. մեկ լեզվով, մեկ կույտով, մեկ էկոհամակարգով: Եվ այստեղ դուք ունեք տեխնոլոգիաների հսկայական բազմազանություն:

Շատ իրական իրավիճակ է, երբ bash-ը python-ով գործարկում է ինչ-որ գործընթաց, որի մեջ մտցվում է Json-ը: Դուք վերլուծում եք այն, հետո ինչ-որ այլ գեներատոր արտադրում է ևս 30 ֆայլ: Այս ամենի համար Azure Key Vault-ից ստացվում են մուտքային փոփոխականներ, որոնք միանում են drone.io-ի համար նախատեսված փլագինին, որը գրված է Go-ում, և այդ փոփոխականներն անցնում են yaml-ի միջով, որը ստեղծվել է jsonnet կաղապարի շարժիչից գեներացիայի արդյունքում։ Բավականին դժվար է ունենալ խիստ լավ նկարագրված կոդ, երբ ունես այդքան բազմազան միջավայր:

Ավանդական զարգացումը մեկ առաջադրանքի շրջանակներում գալիս է մեկ լեզվով։ Այստեղ մենք աշխատում ենք մեծ թվով լեզուներով։

3. Երրորդ խնդիրը թյունինգն է. Մենք սովոր ենք զովացնել խմբագիրներին (Ms Visual Studio, Jetbrains Rider), որոնք ամեն ինչ անում են մեզ համար: Իսկ եթե մենք էլ հիմար լինենք, կասեն, որ սխալ ենք։ Դա նորմալ և բնական է թվում:

Բայց ինչ-որ տեղ մոտակայքում կա VSCode, որում կան որոշ պլագիններ, որոնք ինչ-որ կերպ տեղադրված են, աջակցվում կամ չեն աջակցվում: Նոր տարբերակները դուրս եկան և չաջակցվեցին: Ֆունկցիայի իրականացմանը սովորական անցումը (նույնիսկ եթե այն գոյություն ունի) դառնում է բարդ և ոչ տրիվիալ խնդիր: Փոփոխականի պարզ վերանվանումը տասնյակ ֆայլերի նախագծում կրկնություն է: Դուք հաջողակ կլինեք, եթե նա տեղադրի այն, ինչ ձեզ հարկավոր է: Իհարկե, այստեղ-այնտեղ կա հետին լուսավորություն, կա ավտոմատ լրացում, ինչ-որ տեղ կա ֆորմատավորում (չնայած Windows-ի տերրաֆորմով դա ինձ մոտ չաշխատեց):

Այս գրելու պահին vscode-terraform plugin դեռ չեն թողարկվել 0.12 տարբերակին աջակցելու համար, չնայած այն թողարկվել է 3 ամիս:

Ժամանակն է մոռանալ...

1. Կարգաբերում:
2. Refactoring գործիք.
3. Ավտոմատ լրացում.
4. Կազմման ընթացքում սխալների հայտնաբերում.

Ծիծաղելի է, բայց սա նաև մեծացնում է զարգացման ժամանակը և ավելացնում սխալների թիվը, որոնք անխուսափելիորեն տեղի են ունենում:

Ամենավատն այն է, որ մենք ստիպված ենք մտածել ոչ թե այն մասին, թե ինչպես ձևավորել, ֆայլերը թղթապանակների դասավորել, քայքայել, ծածկագիրը դարձնել պահպանելի, ընթեռնելի և այլն, այլ այն մասին, թե ինչպես կարող եմ ճիշտ գրել այս հրամանը, քանի որ ինչ-որ կերպ այն սխալ եմ գրել: .

Որպես սկսնակ, դուք փորձում եք սովորել տերրաֆորմներ, և IDE-ն ձեզ ամենևին չի օգնում: Երբ փաստաթղթեր կան, մտեք ներս և նայեք: Բայց եթե նոր ծրագրավորման լեզու մտնեիր, IDE-ն քեզ կասեր, որ տենց տեսակ կա, բայց տենց բան չկա։ Առնվազն int կամ string մակարդակում: Սա հաճախ օգտակար է:

Ինչ վերաբերում է թեստերին:

Դուք հարցնում եք. «Ի՞նչ կասեք թեստերի մասին, պարոնայք ծրագրավորողներ»: Լուրջ տղաները փորձարկում են ամեն ինչ արտադրության վրա, և դա դժվար է: Ահա տերրաֆորմ մոդուլի միավորի փորձարկման օրինակ՝ կայքից Microsoft.

Նրանք լավ փաստաթղթեր ունեն։ Ինձ միշտ դուր է եկել Microsoft-ը փաստաթղթերի և ուսուցման նկատմամբ իր մոտեցման համար: Բայց պետք չէ լինել քեռի Բոբ՝ հասկանալու համար, որ սա կատարյալ ծածկագիր չէ: Նշեք վավերացումը դեպի աջ:

Միավորի թեստի խնդիրն այն է, որ դուք և ես կարող ենք ստուգել Json-ի ելքի ճիշտությունը: Ես գցեցի 5 պարամետր և ինձ տվեցին Json ոտքի սփռոց 2000 տողով: Ես կարող եմ վերլուծել, թե ինչ է կատարվում այստեղ, հաստատել թեստի արդյունքը...

Դժվար է վերլուծել Json-ին Go-ում: Եվ դուք պետք է գրեք Go-ում, քանի որ terraform in Go-ն լավ պրակտիկա է այն լեզվով փորձարկելու համար, որով գրում եք: Օրենսգրքի կազմակերպումն ինքնին շատ թույլ է։ Միևնույն ժամանակ, սա լավագույն գրադարանն է թեստավորման համար։

Microsoft-ն ինքն է գրում իր մոդուլները՝ փորձարկելով դրանք այս կերպ։ Իհարկե բաց կոդով է: Այն ամենը, ինչի մասին ես խոսում եմ, կարող եք գալ և ուղղել: Ես կարող եմ նստել և շտկել ամեն ինչ մեկ շաբաթվա ընթացքում, բաց կոդով VS կոդի պլագիններ, տերրաֆորմներ, պլագին պատրաստել հեծանվորդի համար: Գուցե գրեք մի քանի անալիզատոր, ավելացնեք լինտերներ, փորձարկեք գրադարան: Ես կարող եմ ամեն ինչ անել: Բայց դա այն չէ, ինչ ես պետք է անեի:

Լավագույն փորձի Ենթակառուցվածքը որպես ծածկագիր

Անցնենք առաջ։ Եթե ​​IaC-ում թեստեր չկան, IDE-ն ու թյունինգը վատն են, ապա գոնե լավագույն փորձը պետք է լինի: Ես պարզապես գնացի Google Analytics և համեմատեցի երկու որոնման հարցում՝ Terraform-ի լավագույն փորձը և c#-ի լավագույն փորձը:

Ի՞նչ ենք մենք տեսնում։ Անխիղճ վիճակագրությունը մեզ ձեռնտու չէ. Նյութի քանակը նույնն է. C#-ի մշակման ժամանակ մենք պարզապես լեցուն ենք նյութերով, ունենք գերլավագույն փորձ, կան գրքեր, որոնք գրված են փորձագետների կողմից, ինչպես նաև գրքերի վրա գրված այլ փորձագետների կողմից, ովքեր քննադատում են այդ գրքերը: Պաշտոնական փաստաթղթերի, հոդվածների, վերապատրաստման դասընթացների և այժմ նաև բաց կոդով մշակման ծով:

Ինչ վերաբերում է IaC-ի խնդրանքին. այստեղ դուք փորձում եք քիչ առ քիչ տեղեկատվություն հավաքել highload կամ HashiConf հաշվետվություններից, պաշտոնական փաստաթղթերից և Github-ի բազմաթիվ խնդիրներից: Ինչպե՞ս բաշխել այս մոդուլները ընդհանրապես, ի՞նչ անել դրանց հետ: Թվում է, թե սա իրական խնդիր է... Կա մի համայնք, պարոնայք, որտեղ ցանկացած հարցի համար ձեզ կտրվի 10 մեկնաբանություն Github-ում։ Բայց դա հենց այնպես չէ:

Ցավոք սրտի, այս պահին փորձագետները նոր են սկսում ի հայտ գալ: Առայժմ դրանք շատ քիչ են։ Իսկ ինքը՝ համայնքը, կախված է տարրական մակարդակի վրա:

Ո՞ւր է գնում այս ամենը և ինչ անել

Դուք կարող եք թողնել ամեն ինչ և վերադառնալ C#՝ հեծանվորդի աշխարհ: Բայց ոչ. Ինչո՞ւ եք անհանգստացնում դա անել, եթե լուծում չեք գտնում: Ստորև ներկայացնում եմ իմ սուբյեկտիվ եզրակացությունները. Կարող եք վիճել ինձ հետ մեկնաբանություններում, հետաքրքիր կլինի։

Անձամբ ես խաղադրույք եմ կատարում մի քանի բանի վրա.

1. Այս ոլորտում զարգացումը տեղի է ունենում շատ արագ։ Ահա DevOps-ի հարցումների ժամանակացույցը:

   
   
   Թեման գուցե աժիոտաժ է, բայց հենց այն փաստը, որ ոլորտն աճում է, որոշակի հույս է տալիս։

   Եթե ​​ինչ-որ բան այդքան արագ աճում է, ապա անպայման կհայտնվեն խելացի մարդիկ, ովքեր ձեզ կասեն, թե ինչ անել, ինչ չանել։ Հանրաճանաչության աճը հանգեցնում է նրան, որ միգուցե ինչ-որ մեկը ժամանակ ունենա վերջապես jsonnet-ում vscode-ի համար պլագին ավելացնելու համար, որը թույլ կտա անցնել գործառույթի իրականացմանը, այլ ոչ թե որոնել այն ctrl+shift+f-ի միջոցով։ Քանի որ իրերը զարգանում են, ավելի շատ նյութեր են հայտնվում: Google-ից SRE-ի մասին գրքի թողարկումը դրա հիանալի օրինակն է:

2. Կան ավանդական զարգացման մշակված տեխնիկա և պրակտիկա, որոնք մենք կարող ենք հաջողությամբ կիրառել այստեղ: Այո, կան նրբերանգներ թեստավորման և տարասեռ միջավայրի, ոչ բավարար գործիքակազմի հետ, բայց կուտակվել են հսկայական թվով պրակտիկաներ, որոնք կարող են օգտակար և օգտակար լինել:

   Չնչին օրինակ՝ համագործակցություն զույգ ծրագրավորման միջոցով: Դա շատ է օգնում պարզել այն: Երբ մոտակայքում ունեք հարևան, ով նույնպես փորձում է ինչ-որ բան հասկանալ, միասին ավելի լավ կհասկանաք։

   Հասկանալը, թե ինչպես է կատարվում ռեֆակտորինգը, օգնում է այն իրականացնել նույնիսկ նման իրավիճակում։ Այսինքն՝ կարելի է միանգամից չփոխել ամեն ինչ, այլ փոխել անվանումը, հետո փոխել տեղը, հետո կարող ես առանձնացնել ինչ-որ հատված, օհ, բայց այստեղ բավարար մեկնաբանություններ չկան։

Ամփոփում

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

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

Source: www.habr.com