Կրկնվող տեքստային ձևաչափով ենթակառուցվածքը որպես կոդ ներկայացնելը պարզ լավագույն պրակտիկա է համակարգերի համար, որոնք չեն պահանջում մկնիկի թրթռում: Այս պրակտիկան ստացել է անուն. , և մինչ այժմ կան երկու հանրաճանաչ գործիք դա անելու համար, հատկապես AWS-ում. и .
Համեմատելով իմ փորձը Terraform-ի և CloudFormation-ի հետ
Մինչև միանալը (նա է ) Ես շատ աշխատեցի և օգտագործել Terraform-ը երեք տարի: Իմ նոր վայրում ես նաև ամբողջությամբ օգտագործեցի Terraform-ը, և այնուհետև ընկերությունն ինձ դրդեց անցնել Amazon-ի ամեն ինչի, ներառյալ CloudFormation-ը: Ես քրտնաջան աշխատել եմ երկուսի համար էլ լավագույն փորձը մշակելու համար, և երկու գործիքներն էլ օգտագործել եմ շատ բարդ, կազմակերպչական աշխատանքների հոսքերում: Ավելի ուշ, Terraform-ից CloudFormation տեղափոխվելու հետևանքները ուշադիր դիտարկելուց հետո ես համոզվեցի, որ Terraform-ը հավանաբար լավագույն ընտրությունն է կազմակերպության համար:
Terraform-ը սարսափելի է
Ծրագրաշարի բետա տարբերակը
Terraform-ը դեռ 1.0-ից դուրս չէ, ինչը լավ պատճառ է այն չօգտագործելու համար: Այն շատ է փոխվել, երբ ես առաջին անգամ ինքս փորձեցի, բայց այն ժամանակ terraform apply հաճախ խափանում էր մի քանի թարմացումներից կամ ընդամենը մի քանի տարի օգտագործելուց հետո: Ես կասեի, որ «հիմա ամեն ինչ այլ է», բայց… բոլորն այդպես են ասում, չէ՞: Կան փոփոխություններ, որոնք անհամատեղելի են նախորդ տարբերակների հետ, թեև դրանք տեղին են, և նույնիսկ թվում է, թե ռեսուրսների պահեստավորման շարահյուսությունն ու աբստրակցիան այժմ այն է, ինչ մեզ անհրաժեշտ է: Թվում է, թե գործիքն իսկապես ավելի լավ է դարձել, բայց… :-0
Մյուս կողմից, AWS-ը լավ աշխատանք է կատարել՝ պահպանելով համատեղելիությունը նախորդ տարբերակների հետ: Հավանաբար, դա պայմանավորված է նրանով, որ նրանց ծառայությունները հաճախ մանրակրկիտ փորձարկվում են կազմակերպության ներսում և միայն դրանից հետո, վերանվանվելուց հետո, դրանք հրապարակվում են: Այսպիսով, «նրանք շատ փորձեցին» դեռևս թերագնահատված է: API-ների հետ հետ համատեղելիության պահպանումը AWS-ի նման բազմատեսակ և բարդ համակարգի համար աներևակայելի դժվար է: Յուրաքանչյուր ոք, ով ստիպված է եղել պահպանել հանրային API-ները, որոնք լայնորեն օգտագործվում են, պետք է հասկանան, թե որքան դժվար է դա անել այսքան տարիների ընթացքում: Բայց որքան ես հիշում եմ, CloudFormation-ի վարքագիծը երբեք չի փոխվել տարիների ընթացքում:
Հանդիպեք ոտքին... դա փամփուշտ է
Որքան գիտեմ, ջնջիր ռեսուրսը օտար Հնարավոր չէ փոխել CloudFormation փաթեթը ձեր CF կույտից: Դա մոտավորապես նույնն է Terraform-ի դեպքում: Այն թույլ է տալիս ներմուծել առկա ռեսուրսները ձեր բուրգ: Գործառույթը, կարելի է ասել, զարմանալի է, բայց մեծ ուժի հետ գալիս է մեծ պատասխանատվություն: Երբ դուք ռեսուրս եք դնում փաթեթի մեջ, դուք չեք կարող ջնջել կամ փոխել այդ ռեսուրսը, երբ աշխատում եք ձեր stack-ի հետ: Մի օր այն վերադարձավ ինձ հետապնդելու: Ինչ-որ կերպ, ինչ-որ մեկը Twitch-ում, առանց որևէ չարամիտ նպատակի, պատահաբար ներմուծել է ուրիշի AWS անվտանգության խումբը սեփական Terraform փաթեթ: Մուտքագրեցի մի քանի հրաման և... անվտանգության խումբը (մուտքային տրաֆիկի հետ միասին) անհետացավ։
Տերրաֆորմ Մեծ
Վերականգնում թերի վիճակներից
Երբեմն CloudFormation-ը չի կարողանում ամբողջությամբ անցնել մի վիճակից մյուսը: Միաժամանակ նա կփորձի վերադառնալ նախորդին։ Ցավոք, դա միշտ չէ, որ իրագործելի է: Ձեր ունեցածի վրիպազերծումը կարող է մի փոքր սարսափելի լինել. դուք երբեք չգիտեք, թե արդյոք CloudFormation-ը ուրախ կլինի տեսնել այն կոտրված, նույնիսկ եթե դա պարզապես վերանորոգման համար է: Բայց արդյոք հնարավոր կլինի վերադառնալ նախկին վիճակին, թե ոչ, նա իրականում չգիտի ինչպես որոշել և լռելյայն ժամերով կախվում է հրաշքի սպասելով:
Մյուս կողմից, Terraform-ը հակված է վերականգնել ձախողված անցումներից շատ ավելի նրբագեղ և առաջարկում է վրիպազերծման լայնածավալ գործիքներ:
Փաստաթղթի վիճակի ավելի հստակ փոփոխություններ
«Լավ, բեռի հավասարակշռող, դու փոխվում ես։ Բայց ինչպե՞ս։
— անհանգստացած ինժեներ, որը պատրաստ է սեղմել ընդունելության կոճակը:
Երբեմն ես պետք է որոշ մանիպուլյացիաներ անեմ CloudFormation փաթեթում բեռնվածության հավասարակշռիչի հետ, օրինակ՝ ավելացնել պորտի համարը կամ փոխել անվտանգության խումբը: ClouFormation-ը վատ է ցույց տալիս փոփոխությունները: Ես, քորոցների և ասեղների վրա, տասն անգամ նորից ստուգում եմ yaml ֆայլը, որպեսզի համոզվեմ, որ չեմ ջնջել որևէ անհրաժեշտ բան կամ ավելորդ բան չեմ ավելացրել:
Terraform-ն այս առումով շատ ավելի թափանցիկ է: Երբեմն դա նույնիսկ չափազանց թափանցիկ է (կարդացեք՝ զայրացնող): Բարեբախտաբար, վերջին տարբերակը ներառում է փոփոխությունների բարելավված ցուցադրում. այժմ դուք կարող եք հստակ տեսնել, թե ինչ է փոխվում:
Ճկունություն
Գրեք ծրագրակազմը հակառակ ուղղությամբ:
Կոպիտ ասած, երկարակյաց ծրագրային ապահովման ամենակարեւոր հատկանիշը փոփոխություններին հարմարվելու ունակությունն է: Գրեք ցանկացած ծրագիր հակառակ ուղղությամբ: Ես ամենից հաճախ խաբվում էի, երբ օգտագործում էի «պարզ» ծառայություն, իսկ հետո սկսեցի ամեն ինչ խցկել մեկ CloudFormation կամ Terraform կույտի մեջ: Եվ իհարկե, ամիսներ անց պարզվեց, որ ես ամեն ինչ սխալ էի հասկացել, և ծառայությունն իրականում պարզ չէր: Այսպիսով, ես պետք է ինչ-որ կերպ կոտրեմ մեծ բուրգը փոքր բաղադրիչների: CloudFormation-ի հետ աշխատելիս դուք կարող եք դա անել միայն նախ վերստեղծելով գոյություն ունեցող կույտը, իսկ ես դա չեմ անում իմ DB-ների հետ: Terraform-ը թույլ է տվել կտրատել կույտը և այն բաժանել ավելի հասկանալի փոքր կտորների:
Մոդուլներ git-ում
Terraform կոդով մի քանի կույտերով կիսելը շատ ավելի հեշտ է, քան CloudFormation կոդը: Terraform-ի հետ դուք կարող եք տեղադրել ձեր կոդը git պահոցում և մուտք գործել դրան՝ օգտագործելով իմաստաբանական տարբերակի կառավարում: Յուրաքանչյուր ոք, ով մուտք ունի այս պահոց, կարող է կրկին օգտագործել ընդհանուր կոդը: CloudFormation-ի համարժեքը S3-ն է, բայց այն չունի նույն առավելությունները, և պատճառ չկա, որ մենք երբևէ հրաժարվենք git-ից՝ հօգուտ S3-ի:
Կազմակերպությունն աճեց, և ընդհանուր կույտերը կիսելու ունակությունը հասավ կրիտիկական մակարդակի: Terraform-ը այս ամենը դարձնում է հեշտ և բնական, մինչդեռ CloudFormation-ը ձեզ կստիպի ցատկել օղակների միջով, նախքան նման բան աշխատելը:
Գործողությունները որպես կոդ
«Սցենարավորենք ու վերջ»։
— Ինժեներ Terraform անիվը հայտնագործելուց 3 տարի առաջ։
Երբ խոսքը վերաբերում է ծրագրային ապահովման մշակմանը, Go-ն կամ Java ծրագիրը ավելին է, քան պարզապես կոդ:
Կոդը որպես ծածկագիր
Կա նաև այն ենթակառուցվածքը, որի վրա այն գործում է։
Ենթակառուցվածքները `որպես ծածկագիր
Բայց որտեղի՞ց նա եկավ: Ինչպե՞ս վերահսկել այն: Որտե՞ղ է ապրում ձեր կոդը: Արդյո՞ք ծրագրավորողներին անհրաժեշտ է թույլտվություն մուտք գործելու համար:
Գործողությունները որպես ծածկագիր
Ծրագրային ապահովման մշակող լինելն ավելին է, քան պարզապես կոդ գրելը:
Դա միայն AWS-ը չէ. դուք հավանաբար օգտագործում եք այլ մատակարարներ: SignalFx, PagerDuty կամ Github: Գուցե դուք ունեք ներքին Jenkins սերվեր CI/CD-ի համար կամ ներքին Grafana վահանակ մոնիտորինգի համար: Infra as Code-ն ընտրվում է տարբեր պատճառներով, որոնք բոլորը հավասարապես կարևոր են ծրագրային ապահովման հետ կապված ամեն ինչի համար:
Երբ ես աշխատում էի Twitch-ում, մենք արագացնում էինք ծառայությունները ներկառուցված և Amazon AWS համակարգերի մեջ: Մենք ջարդում և պահպանում էինք բազմաթիվ միկրոծառայություններ՝ ավելացնելով գործառնական ծախսերը: Քննարկումներն ընթացան այսպես.
- ЯԱնիծյալ, դա մեծ շարժում է մեկ միկրոսերվիսը արագացնելու համար: Ես պետք է օգտագործեմ այս բանը AWS հաշիվ ստեղծելու համար (մենք պատրաստվում էինք 2 հաշիվների վրա միկրոսերվիս), այնուհետև սա՝ ծանուցումները կարգավորելու համար, սա կոդի պահոցի համար, և սա էլփոստի ցուցակի համար, և այս մեկը…
- Առաջատար: Եկեք սցենար գրենք և վերջ։
- ЯԼավ, բայց սցենարն ինքնին կփոխվի: Պետք է գտնել միջոց՝ ստուգելու, թե արդյոք այս բոլոր ներկառուցված Amazon-ի իրերը արդիական են:
- ԱռաջատարԼավ է հնչում: Եվ մենք դրա համար սցենար կգրենք։
- Я: Հիանալի! Իսկ սցենարին, հավանաբար, դեռ պետք կլինի պարամետրեր տալ։ Նա կընդունի՞ դրանք։
- Առաջատար— Հա, կընդունի, էլ ի՞նչ անի։
- ЯԳործընթացը կարող է փոխվել՝ կորցնելով հետին համատեղելիությունը: Կպահանջվի ինչ-որ իմաստային տարբերակի վերահսկում:
- Առաջատար: Հիանալի գաղափար!
- ЯԳործիքները կարող են փոխվել ձեռքով, օգտագործողի միջերեսում: Սա ստուգելու և շտկելու միջոց է պետք:
…3 տարի անց.
- ԱռաջատարԵվ մենք ստացանք տերրաֆորմ:
Պատմության բարոյականությունը հետևյալն է. նույնիսկ եթե դու մինչև իմ ականջները ամեն ինչում Amazon, դուք դեռ օգտագործում եք ոչ AWS-ի մի բան, և այդ ծառայություններն ունեն վիճակ, որն օգտագործում է կազմաձևման լեզու՝ այդ վիճակը համաժամեցված պահելու համար:
CloudFormation lambda vs terraform git մոդուլներ
lambda-ն CloudFormation-ի լուծումն է մաքսային տրամաբանության հարցում: Լամբդայով դուք կարող եք կամ . Այս մոտեցումը ներկայացնում է լրացուցիչ բարդություններ, որոնք Terraform-ի git մոդուլների իմաստային տարբերակումը չունի: Ինձ համար ամենահրատապ խնդիրը բոլոր այս օգտվողների լամբդաների թույլտվությունների կառավարումն էր (որը տասնյակ AWS հաշիվներ է): Մյուս կարևոր խնդիրն այն էր, թե «ինչն առաջացավ՝ հավը, թե ձուն»։ խնդիր՝ կապված լամբդա կոդի հետ։ Ֆունկցիան ինքնին ենթակառուցվածք և կոդ է, և այն ինքնին մոնիտորինգի և թարմացումների կարիք ունի: Դագաղի վերջնական մեխը լամբդա կոդի փոփոխությունները իմաստայինորեն թարմացնելու դժվարությունն էր. Անհրաժեշտ էր նաև համոզվել, որ առանց ուղղակի հրամանի ստեկի գործողությունները չեն փոխվում գործարկումների միջև:
Հիշում եմ, որ մի անգամ ես ուզում էի ստեղծել դեղձանիկի տեղակայում Elastic Beanstalk միջավայրի համար դասական բեռի հավասարակշռիչով: Ամենահեշտ ձևը կլինի երկրորդ տեղակայումը EB-ում արտադրության կողքին՝ մեկ քայլ առաջ գնալով. համատեղելով ավտոմասշտաբային դեղձանիկների տեղակայման խումբը LB-ի տեղակայման համար արտադրության մեջ: Եվ քանի որ Terraform-ը օգտագործում է , սա կպահանջի 4 լրացուցիչ տող կոդ Terraform-ում: Երբ ես հարցրի, թե արդյոք կա՞ համադրելի լուծում CloudFormation-ում, ինձ մատնանշեցին մի ամբողջ git պահոց՝ տեղակայման խողովակաշարով, և այն ամենը, ինչ կարող էր անել Terraform-ի 4 տող կոդի խայտառակությունը:
Այն ավելի լավ է հայտնաբերում շեղումը:
Համոզվեք, որ իրականությունը համապատասխանում է սպասելիքներին:
— Գործառնությունները որպես ծածկագիր շատ հզոր հատկանիշ է, քանի որ այն օգնում է ապահովել, որ իրականությունը համապատասխանում է սպասելիքներին: Այն հասանելի է ինչպես CloudFormation-ի, այնպես էլ Terraform-ի հետ: Բայց քանի որ արտադրության կույտը մեծանում էր, CloudFormation-ի դրեյֆի հայտնաբերումը ավելի ու ավելի շատ կեղծ պոզիտիվներ էր տալիս:
Terraform-ի հետ դուք ունեք շատ ավելի առաջադեմ կյանքի ցիկլի կեռիկներ՝ շեղումներ հայտնաբերելու համար: Օրինակ, դուք մուտքագրում եք հրամանը ուղղակիորեն ECS առաջադրանքի սահմանման մեջ, եթե ցանկանում եք անտեսել որոշակի առաջադրանքի սահմանման փոփոխությունները՝ առանց անտեսելու ամբողջ ECS-ի տեղակայման փոփոխությունները:
CDK և CloudFormation-ի ապագան
CloudFormation-ը դժվար է կառավարել լայնածավալ ենթակառուցվածքային մասշտաբներով: Այս դժվարություններից շատերը ճանաչված են, և գործիքին անհրաժեշտ են նման բաներ , կոդով ամպային ենթակառուցվածքը սահմանելու և AWS CloudFormation-ի միջոցով գործարկելու շրջանակ։ Հետաքրքիր կլինի տեսնել, թե ապագայում ինչ է սպասվում aws-cdk-ին, բայց նա դժվարությամբ կմրցի Terraform-ի մյուս ուժեղ կողմերի հետ. CloudFormation-ը գործարկելու համար կպահանջվեն գլոբալ փոփոխություններ:
Terraform-ից հիասթափությունից խուսափելու համար
Սա «ենթակառուցվածք է որպես ԿՈԴ», ոչ թե «որպես տեքստ»:
Terraform-ից իմ առաջին տպավորությունը բավականին վատ էր: Կարծում եմ՝ ուղղակի չհասկացա մոտեցումը։ Գրեթե բոլոր ինժեներները սկզբում ակամայից այն ընկալում են որպես տեքստի ձևաչափ, որը պետք է վերածվի ցանկալի ենթակառուցվածքի: ԱՅԴ ՄԻ ԱՐԵՔ:
Ծրագրային ապահովման լավ մշակման ճշմարտացիությունը վերաբերում է նաև Terraform-ին
Ես տեսել եմ շատ պրակտիկաներ, որոնք ընդունված են լավ կոդ գրելու համար, անտեսվել են Terraform-ում: Դուք տարիներ շարունակ սովորել եք լավ ծրագրավորող դառնալու համար։ Մի հրաժարվեք այս փորձից միայն այն պատճառով, որ աշխատում եք Terraform-ի հետ: Ծրագրային ապահովման լավ մշակման սկզբունքը վերաբերում է նաև Terraform-ին:
Ինչպե՞ս կարող եք չփաստաթղթավորել կոդը:
Ես հանդիպել եմ հսկայական Terraform կույտերի, որոնք ընդհանրապես փաստաթղթեր չունեն: Ինչպե՞ս կարող եք գրել կոդ էջերում՝ ընդհանրապես առանց որևէ փաստաթղթի: Ավելացրեք փաստաթղթեր, որոնք բացատրում են ձեր կոդը Terraform (այստեղ շեշտը դնում ենք «կոդ» բառի վրա), ինչու է այս բաժինը կարևոր և ինչ եք անում:
Ինչպե՞ս կարող եք տեղակայել ծառայություններ, որոնք ժամանակին եղել են մեկ հիմնական հիմնական() ֆունկցիա:
Ես տեսել եմ շատ բարդ Terraform կույտեր, որոնք ներկայացված են որպես մեկ մոդուլ: Ինչու՞ մենք նման ծրագրակազմ չենք տեղադրում: Ինչո՞ւ ենք մեծ ֆունկցիաները բաժանում փոքրերի: Նույն պատասխանները վերաբերում են Terraform-ին: Եթե ձեր մոդուլը չափազանց մեծ է, դուք պետք է այն բաժանեք ավելի փոքր մոդուլների:
Ձեր ընկերությունը գրադարաններից չի՞ օգտվում:
Ես տեսել եմ, որ ինժեներները նոր նախագիծ են մշակում Terraform-ի միջոցով՝ պարզապես copy-pasting-փակելով այլ նախագծերի հսկայական կտորներ իրենց սեփականի մեջ, և այնուհետև աշխատելով նրանց հետ, մինչև որ այն գործի: Կաշխատեի՞ք այսպես ձեր ընկերությունում «մարտական» կոդով: Մենք պարզապես իզուր չենք օգտագործում գրադարանները: Այո, բայց ո՞ւր կլինեինք մենք առանց հանրային գրադարանների սկզբունքորեն։
PEP8 կամ gofmt չե՞ք օգտագործում:
Լեզուների մեծ մասն ունի ստանդարտ ընդունված ձևաչափման սխեմա: Python-ում դա PEP8 է: Գոյում — gofmt. Terraform-ն ունի իր սեփականը. terraform fmt. Վայելեք այն լավ առողջությամբ:
Կօգտագործեի՞ք React-ը առանց JavaScript-ի իմացության:
Terraform մոդուլները կարող են պարզեցնել որոշ բարդ ենթակառուցվածքներ, որոնք դուք կառուցում եք, բայց դա չի նշանակում, որ դուք կարող եք ընդհանրապես բաց թողնել այն: Ցանկանու՞մ եք Terraform-ը ճիշտ օգտագործել՝ առանց ռեսուրսները հասկանալու: Դուք դատապարտված եք. ժամանակը կանցնի, և դուք երբեք չեք տիրապետի Terraform-ին:
Դուք կոդավորում եք միայնակներով կամ կախվածության ներարկումով:
Կախվածության ներարկումը ճանաչված լավագույն փորձ է ծրագրային ապահովման մշակման համար և նախընտրելի է միայնակներից: Ինչպե՞ս է սա օգտակար Terraform-ում: Ես տեսել եմ Terraform մոդուլներ, որոնք կախված են հեռավոր վիճակից: Հեռավոր վիճակից վերցվող մոդուլներ գրելու փոխարեն, գրեք մոդուլ, որն ընդունում է պարամետրեր: Եվ հետո փոխանցեք այս պարամետրերը մոդուլին:
Ձեր գրադարանները տասը բան լավ են անում, թե՞ մի բան՝ հիանալի:
Լավագույն աշխատող գրադարաններն այն գրադարաններն են, որոնք կենտրոնանում են մեկ առաջադրանքի վրա, որը նրանք չափազանց լավ են անում: Terraform-ի մեծ մոդուլներ գրելու փոխարեն, որոնք փորձում են ամեն ինչ անել միանգամից, դրանք կազմեք կտորների, որոնք լավ են անում մի բան: Եվ հետո դրանք միացրեք ըստ անհրաժեշտության:
Ինչպե՞ս եք փոփոխություններ կատարել գրադարաններում՝ առանց հետադարձ համատեղելիության:
Համօգտագործվող Terraform մոդուլը, ինչպես սովորական գրադարանը, կարիք ունի ինչ-որ ձևի՝ փոփոխությունները փոխանցելու օգտատերերին, որոնք հետ համատեղելի չեն: Անհանգստացնող է, երբ նման փոփոխություններ են տեղի ունենում գրադարաններում, և նույնքան անհանգստացնող է, երբ Terraform մոդուլներում ոչ հետհամատեղելի փոփոխություններ են կատարվում: Terraform մոդուլներ օգտագործելիս խորհուրդ է տրվում օգտագործել git tags և semver:
Արդյո՞ք արտադրական ծառայությունն աշխատում է ձեր նոութբուքի կամ տվյալների կենտրոնում:
Hashicorp-ն ունի այնպիսի գործիքներ, ինչպիսիք են ձեր տերրաֆորմը գործարկելու համար: Այս կենտրոնացված ծառայությունները հեշտացնում են կառավարել, աուդիտ և հաստատել հողային փոփոխությունները:
Թեստեր չե՞ք գրում։
Ինժեներները գիտակցում են, որ կոդը պետք է փորձարկվի, բայց հաճախ անտեսում են դա անել Terraform-ի հետ աշխատելիս: Սա հղի է ենթակառուցվածքների համար վտանգավոր հետեւանքներով։ Ես խորհուրդ եմ տալիս «փորձարկել» կամ «ստեղծել նմուշներ» կույտերի մոդուլների միջոցով, որոնք կարող են ճիշտ տեղակայվել CI/CD-ի ընթացքում փորձարկման համար:
Terraform և Microservices
Միկրոսպասարկման ընկերությունների կյանքն ու մահը կախված է նոր միկրոսերվիսների աշխատանքային կույտերի արագությունից, նորարարությունից և ոչնչացումից:
Միկրոծառայությունների ճարտարապետության ամենատարածված բացասական կողմը, որից երբեք չի ազատվում, կապված է աշխատանքի հետ, ոչ թե կոդի: Եթե դուք Terraform-ը համարում եք միկրոծառայությունների ենթակառուցվածքի ճարտարապետության ենթակառուցվածքի ավտոմատացման միջոց, դուք բաց եք թողնում համակարգի իրական առավելությունները: Հիմա արդեն .
Source: www.habr.com
