Ինչպես վերահսկել ձեր ցանցային ենթակառուցվածքը: Գլուխ չորրորդ. Ավտոմատացում. Կաղապարներ

Այս հոդվածը վեցերորդն է «Ինչպես վերահսկել ձեր ցանցային ենթակառուցվածքը» շարքից: Շարքի բոլոր հոդվածների բովանդակությունը և հղումները կարելի է գտնել այստեղ.

Մի քանի թեմաներ թողած՝ որոշեցի նոր գլուխ սկսել։

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

DevOps ցանցի համար

Սցենարով կոնֆիգուրացիա ստեղծելը, ՏՏ ենթակառուցվածքում փոփոխությունները վերահսկելու համար GIT-ի օգտագործումը, հեռակա «վերբեռնումը»՝ այս գաղափարներն առաջին տեղում են, երբ մտածում եք DevOps մոտեցման տեխնիկական իրականացման մասին: Առավելությունները ակնհայտ են. Բայց, ցավոք, կան նաև թերություններ.

Երբ ավելի քան 5 տարի առաջ մեզ մոտ եկան մեր ծրագրավորողները՝ ցանցային աշխատողները, այս առաջարկներով, մենք հիացած չէինք:

Պետք է ասեմ, որ մենք ժառանգել ենք բավականին խայտաբղետ ցանց՝ բաղկացած մոտ 10 տարբեր վաճառողների սարքավորումներից։ Հարմար էր որոշ բաներ կարգավորել մեր սիրելի cli-ի միջոցով, բայց մյուսներում մենք նախընտրեցինք օգտագործել GUI-ը: Բացի այդ, «կենդանի» սարքավորումների վրա երկար աշխատանքը մեզ սովորեցրել է իրական ժամանակում կառավարել: Օրինակ, փոփոխություններ կատարելիս ես ինձ շատ ավելի հարմարավետ եմ զգում անմիջապես cli-ի միջոցով աշխատելիս: Այս կերպ ես կարող եմ արագ տեսնել, որ ինչ-որ բան սխալ է տեղի ունեցել և հետ եմ գցել փոփոխությունները: Այս ամենը որոշակի հակասության մեջ էր նրանց պատկերացումների հետ։

Այլ հարցեր նույնպես առաջանում են, օրինակ՝ ինտերֆեյսը կարող է փոքր-ինչ փոխվել ծրագրաշարի տարբերակից տարբերակ: Սա, ի վերջո, կհանգեցնի նրան, որ ձեր սցենարը սխալ «կոնֆիգուր» կստեղծի: Ես չէի ցանկանա արտադրությունն օգտագործել «ներս մտնելու» համար։

Կամ ինչպե՞ս հասկանալ, որ կոնֆիգուրացիայի հրամանները ճիշտ են կիրառվել և ինչ անել սխալի դեպքում։

Չեմ ուզում ասել, որ այս բոլոր հարցերն անլուծելի են։ Պարզապես «Ա» ասելը, հավանաբար, իմաստ ունի նաև «B» ասելը, և եթե ցանկանում եք օգտագործել նույն գործընթացները փոփոխությունների վերահսկման համար, ինչ մշակման ժամանակ, ապա արտադրությունից բացի պետք է ունենաք մշակող և բեմադրող միջավայրեր: Հետո այս մոտեցումը ամբողջական տեսք ունի: Բայց որքան կարժենա:

Բայց կա մի իրավիճակ, երբ թերությունները գործնականում հարթվում են, և մնում են միայն առավելությունները։ Խոսքս դիզայներական աշխատանքների մասին է:

Ծրագիր

Վերջին երկու տարիների ընթացքում ես մասնակցում եմ մեծ մատակարարի համար տվյալների կենտրոն կառուցելու նախագծին: Այս նախագծում ես պատասխանատու եմ F5-ի և Palo Alto-ի համար: Cisco-ի տեսանկյունից սա «երրորդ կողմի սարքավորում» է։

Անձամբ ինձ համար այս նախագծում կա երկու հստակ փուլ:

Առաջին փուլ

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

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

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

Այժմ մենք կարող էինք մի փոքր նայել մեր շուրջը:
Եվ սա երկրորդ փուլի սկիզբն էր։

Երկրորդ փուլ

Ես որոշեցի ավտոմատացնել գործընթացը:

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

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

Այսպիսով, YAML և Jinja2-ն օգտագործելիս YAML ֆայլը կազմաձևման պարամետրերով, ինչպիսիք են IP հասցեները, BGP AS համարները, ... կատարելապես կատարում է NIP-ի դերը, մինչդեռ Jinja2 ձևանմուշները ներառում են դիզայնին համապատասխան շարահյուսություն, այսինքն՝ այն ըստ էության LLD-ի արտացոլումը:

YAML-ը և Jinja2-ը սովորելու համար պահանջվեց երկու օր: Մի քանի լավ օրինակներ բավական են հասկանալու համար, թե ինչպես է դա աշխատում: Այնուհետև մոտ երկու շաբաթ պահանջվեց մեր դիզայնին համապատասխանող բոլոր ձևանմուշները ստեղծելու համար. մեկ շաբաթ Պալո Ալտոյի համար և ևս մեկ շաբաթ F5-ի համար: Այս ամենը տեղադրվել է կորպորատիվ githab-ում։

Այժմ փոփոխության գործընթացը այսպիսի տեսք ուներ.

• փոխել է YAML ֆայլը
• ստեղծել է կազմաձևման ֆայլ՝ օգտագործելով ձևանմուշ (Jinja2)
• պահված հեռավոր պահոցում
• բեռնել է ստեղծված կոնֆիգուրացիան սարքավորման վրա
• Ես սխալ տեսա
• փոխել է YAML ֆայլը կամ Jinja2 ձևանմուշը
• ստեղծել է կազմաձևման ֆայլ՝ օգտագործելով ձևանմուշ (Jinja2)
• ...

Հասկանալի է, որ սկզբում շատ ժամանակ էր ծախսվում խմբագրումների վրա, բայց մեկ-երկու շաբաթ անց դա բավականին հազվադեպ էր դառնում։

Լավ թեստ և ամեն ինչ կարգաբերելու հնարավորությունը հաճախորդի ցանկությունն էր փոխել անվանման կոնվենցիան: Նրանք, ովքեր աշխատել են F5-ի հետ, հասկանում են իրավիճակի խստությունը։ Բայց ինձ համար ամեն ինչ բավականին պարզ էր: Ես փոխեցի անունները YAML ֆայլում, ջնջեցի ամբողջ կոնֆիգուրացիան սարքավորումներից, ստեղծեցի նորը և վերբեռնեցի այն: Ամեն ինչ, ներառյալ սխալների շտկումը, տևեց 4 օր՝ երկու օր յուրաքանչյուր տեխնոլոգիայի համար: Դրանից հետո ես պատրաստ էի հաջորդ փուլին, այն է՝ DEV և Staging տվյալների կենտրոնների ստեղծմանը։

Dev and Staging

Բեմադրությունն իրականում ամբողջությամբ կրկնօրինակում է արտադրությունը: Dev-ը խիստ հանված պատճեն է, որը կառուցված է հիմնականում վիրտուալ սարքաշարի վրա: Իդեալական իրավիճակ նոր մոտեցման համար։ Եթե ​​ես առանձնացնեմ իմ ծախսած ժամանակը ընդհանուր գործընթացից, ապա կարծում եմ, որ աշխատանքը տևել է ոչ ավելի, քան 2 շաբաթ։ Հիմնական ժամանակը դիմացինին սպասելն է և միասին խնդիրներ փնտրելը։ 3-րդ կողմի իրականացումը գրեթե աննկատ մնաց մյուսների կողմից: Նույնիսկ ժամանակ կար ինչ-որ բան սովորելու և Habré-ում մի քանի հոդված գրելու համար :)

To ամփոփել

Այսպիսով, ի՞նչ ունեմ ես ամենավերջում:

• Կազմաձևը փոխելու համար ինձ մնում է միայն փոխել պարզ, հստակ կառուցվածքային YAML ֆայլը՝ կազմաձևման պարամետրերով: Ես երբեք չեմ փոխում python-ի սկրիպտը և շատ հազվադեպ (միայն սխալի դեպքում) ես փոխում եմ Jinja2 ջերմությունը
• Փաստաթղթային տեսանկյունից սա գրեթե իդեալական իրավիճակ է։ Դուք փոխում եք փաստաթղթերը (YAML ֆայլերը ծառայում են որպես NIP) և վերբեռնում այս կոնֆիգուրացիան սարքավորում: Այս կերպ ձեր փաստաթղթերը միշտ թարմացվում են

Այս ամենը հանգեցրեց նրան, որ

• սխալի մակարդակը իջել է գրեթե 0-ի
• Առօրյայի 90 տոկոսն անհետացել է
• իրականացման արագությունը զգալիորեն աճել է

PAY, F5Y, ACY

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

Վճարելու = տեղակայում Pալո Aից Yaml = Պալո Ալտո Յամլից
F5Y = տեղակայում F5 - ից Yամլ = F5 - ից Yaml (շուտով)
ACY = տեղակայում ACես ից Yամլ = F5 - ից YJR

Մի քանի խոսք կավելացնեմ ACY-ի մասին (չշփոթել ACI-ի հետ):

Նրանք, ովքեր աշխատել են ACI-ի հետ, գիտեն, որ այս հրաշքը (և լավ իմաստով նույնպես) հաստատ չի ստեղծվել ցանցային աշխատողների կողմից :): Մոռացեք այն ամենը, ինչ գիտեիք ցանցի մասին, դա ձեզ օգտակար չի լինի:
Դա մի փոքր չափազանցված է, բայց մոտավորապես փոխանցում է այն զգացումը, որը ես անընդհատ զգում եմ վերջին 3 տարիների ընթացքում՝ աշխատելով ACI-ի հետ:

Եվ այս դեպքում ACY-ն ոչ միայն հնարավորություն է ստեղծելու փոփոխությունների վերահսկման գործընթաց (որը հատկապես կարևոր է ACI-ի դեպքում, քանի որ այն պետք է լինի ձեր տվյալների կենտրոնի կենտրոնական և ամենակարևոր մասը), այլ նաև տալիս է ձեզ. օգտագործողի համար հարմար ինտերֆեյս կոնֆիգուրացիա ստեղծելու համար:

Այս նախագծի ինժեներներն օգտագործում են Excel-ը՝ YAML-ի փոխարեն ACI-ն կարգավորելու համար ճիշտ նույն նպատակների համար: Excel-ի օգտագործման առավելություններն, իհարկե, կան.

• ձեր NIP-ը մեկ ֆայլում
• գեղեցիկ նշաններ, որոնց դիտումը հաճելի է հաճախորդի համար
• դուք կարող եք օգտագործել որոշ Excel գործիքներ

Բայց կա մեկ մինուս, և իմ կարծիքով այն գերազանցում է դրական կողմերին: Փոփոխությունները վերահսկելը և թիմային աշխատանքը համակարգելը շատ ավելի դժվար է դառնում:

ACY-ն իրականում նույն մոտեցումների կիրառությունն է, որը ես օգտագործել եմ երրորդ կողմի համար՝ ACI-ն կարգավորելու համար:

Source: www.habr.com