Ենթակառուցվածքը որպես կոդ ներկայացնելը կրկնվող տեքստային ձևաչափով պարզ լավագույն պրակտիկա է համակարգերի համար, որոնք չեն պահանջում մկների հետ շփվել: Այս պրակտիկան ունի անուն. , և մինչ այժմ կան երկու հանրաճանաչ գործիք՝ այն իրականացնելու համար, հատկապես AWS-ում. и .
Փորձի համեմատություն Terraform-ի և CloudFormation-ի հետ
Մինչև գալը (նա է ) Ես աշխատել եմ և օգտագործել Terraform-ը երեք տարի: Նոր վայրում ես նույնպես ամբողջ ուժով օգտագործեցի Terraform-ը, իսկ հետո ընկերությունը անցում կատարեց ամեն ինչի a la Amazon-ին, ներառյալ CloudFormation-ը: Ես ջանասիրաբար մշակել եմ լավագույն փորձը երկուսի համար, և երկու գործիքներն էլ օգտագործել եմ շատ բարդ, կազմակերպչական աշխատանքների հոսքերում: Ավելի ուշ, Terraform-ից CloudFormation տեղափոխվելու հետևանքները մտածված կշռելուց հետո ես համոզվեցի, որ Terraform-ը հավանաբար լավագույն ընտրությունն է կազմակերպության համար:
Terraform Սարսափելի
Բետա ծրագրակազմ
Terraform-ը դեռ չի թողարկել նույնիսկ 1.0 տարբերակը, ինչը լավ պատճառ է այն չօգտագործելու համար: Այն շատ է փոխվել, երբ ես առաջին անգամ ինքս փորձեցի, բայց այն ժամանակ terraform apply հաճախ փչանում էր մի քանի թարմացումներից կամ պարզապես մի քանի տարի օգտագործելուց հետո: Ես կասեի, որ «հիմա ամեն ինչ այլ է», բայց… դա այն է, ինչ կարծես թե ասում են բոլորը, չէ՞: Կան փոփոխություններ, որոնք անհամատեղելի են նախորդ տարբերակների հետ, թեև դրանք տեղին են, և նույնիսկ թվում է, թե ռեսուրսների խանութների շարահյուսությունն ու աբստրակցիան այժմ այն է, ինչ մեզ անհրաժեշտ է: Գործիքը կարծես թե իսկապես լավացել է, բայց... :-0
Մյուս կողմից, AWS-ը լավ աշխատանք է կատարել՝ պահպանելով հետընթաց համատեղելիությունը: Սա, հավանաբար, պայմանավորված է նրանով, որ նրանց ծառայությունները հաճախ մանրակրկիտ փորձարկվում են կազմակերպության ներսում և միայն դրանից հետո, վերանվանվելով, հրապարակվում: Այնպես որ, «նրանք շատ ջանք գործադրեցին» թերագնահատում է: API-ների հետ հետ համատեղելիության պահպանումը այնպիսի բազմազան և բարդ համակարգի համար, ինչպիսին AWS-ն է, աներևակայելի դժվար է: Յուրաքանչյուր ոք, ով ստիպված է եղել պահպանել հանրային API-ներ, որոնք օգտագործվում են նույնքան լայնորեն, որքան նրանք, պետք է հասկանան, թե որքան դժվար է դա անել այդքան երկար տարիներ: Բայց CloudFormation-ի պահվածքը, իմ հիշողության մեջ, երբեք չի փոխվել տարիների ընթացքում:
Հանդիպեք ոտքին... դա փամփուշտ է
Որքան գիտեմ, ջնջիր ռեսուրսը դրսից CloudFormation կույտը ձեր CF կույտից հնարավոր չէ: Նույնը վերաբերում է Terraform-ին: Այն թույլ է տալիս ներմուծել առկա ռեսուրսները ձեր բուրգ: Գործառույթը, կարելի է ասել, զարմանալի է, բայց մեծ հզորությամբ մեծ պատասխանատվություն է գալիս: Դուք պարզապես պետք է ռեսուրս ավելացնեք կույտին, և մինչ դուք աշխատում եք ձեր կույտի հետ, չեք կարող ջնջել կամ փոխել այս ռեսուրսը: Մի օր դա հակադարձեց. Մի օր Twitch-ում ինչ-որ մեկը պատահաբար ներմուծեց մեկ ուրիշի AWS անվտանգության խումբը սեփական Terraform բուրգ՝ առանց որևէ չարության: Մուտքագրեցի մի քանի հրամաններ և... անվտանգության խումբը (մուտքային տրաֆիկի հետ միասին) անհետացավ։
Terraform Great
Վերականգնում թերի վիճակներից
Երբեմն CloudFormation-ը չի կարողանում ամբողջությամբ անցնել մի վիճակից մյուսը: Միաժամանակ նա կփորձի վերադառնալ նախորդին։ Ափսոս, որ դա միշտ չէ, որ իրագործելի է։ Ավելի ուշ տեղի ունեցածի վրիպազերծումը կարող է շատ սարսափելի լինել. դուք երբեք չգիտեք, թե արդյոք CloudFormation-ը ուրախ կլինի, որ այն կոտրվում է, նույնիսկ միայն այն շտկելու համար: Հնարավո՞ր կլինի վերադառնալ նախկին վիճակին, թե ոչ, նա իսկապես չգիտի, թե ինչպես որոշել և, ըստ նախնականի, ժամերով կախված է հրաշքի սպասելով:
Մյուս կողմից, Terraform-ը հակված է վերականգնել ձախողված անցումներից շատ ավելի նրբագեղ և առաջարկում է վրիպազերծման առաջադեմ գործիքներ:
Փաստաթղթերի վիճակի ավելի հստակ փոփոխություններ
«Լավ, բեռի հավասարակշռող, դու փոխվում ես: Բայց ինչպես?"
— անհանգիստ ինժեներ, պատրաստ է սեղմել «ընդունել» կոճակը:
Երբեմն ես պետք է որոշ մանիպուլյացիաներ անեմ CloudFormation փաթեթում բեռնվածության հավասարակշռողի հետ, ինչպես օրինակ՝ պորտի համար ավելացնել կամ փոխել անվտանգության խումբը: ClouFormation-ը վատ փոփոխություններ է ցուցադրում: Ես, քորոցների և ասեղների վրա, կրկնակի ստուգում եմ yaml ֆայլը տասը անգամ, որպեսզի համոզվեմ, որ ես չեմ ջնջել որևէ անհրաժեշտ բան և չեմ ավելացրել որևէ ավելորդ բան:
Terraform-ն այս առումով շատ ավելի թափանցիկ է: Երբեմն նա նույնիսկ չափազանց թափանցիկ է (կարդալ՝ նյարդայնացնող): Բարեբախտաբար, վերջին տարբերակը ներառում է փոփոխությունների բարելավված ցուցադրում, որպեսզի այժմ կարողանաք տեսնել, թե ինչ է փոխվում:
Ճկունություն
Գրեք ծրագրակազմը հետընթաց:
Կոպիտ ասած, երկարակյաց ծրագրային ապահովման ամենակարեւոր հատկանիշը փոփոխություններին հարմարվելու ունակությունն է: Գրեք ցանկացած ծրագրակազմ հետընթաց: Ամենից հաճախ ես սխալներ եմ թույլ տվել՝ օգտվելով «պարզ» ծառայությունից, այնուհետև սկսելով ամեն ինչ խցկել մեկ CloudFormation կամ Terraform կույտի մեջ: Եվ իհարկե, ամիսներ անց պարզվեց, որ ես ամեն ինչ սխալ էի հասկացել, և ծառայությունն իրականում պարզ չէր: Եվ հիմա ես պետք է ինչ-որ կերպ կոտրեմ մեծ բուրգը փոքր բաղադրիչների: Երբ աշխատում եք CloudFormation-ի հետ, դա հնարավոր է անել միայն նախ վերստեղծելով գոյություն ունեցող կույտը, և ես դա չեմ անում իմ տվյալների բազաների հետ: Մյուս կողմից, 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 gizmos-ները արդիական են:
- Առաջնորդել: Լավ է հնչում. Եվ մենք դրա համար սցենար կգրենք:
- Я: Հիանալի! Եվ սցենարը, հավանաբար, դեռ պետք է պարամետրեր սահմանի: Նա կընդունի՞ դրանք։
- Առաջնորդել: Թող տանի ուր գնում է։
- ЯԳործընթացը կարող է փոխվել, և հետընթաց համատեղելիությունը կկորչի: Կպահանջվի ինչ-որ իմաստային տարբերակի վերահսկում:
- Առաջնորդել: Հանճարեղ միտք!
- ЯԳործիքները կարող են փոխվել ձեռքով, օգտագործողի միջերեսի ներսում: Սա ստուգելու և շտկելու միջոց է պետք:
…3 տարի անց.
- ԱռաջնորդելԵվ մենք ստացանք տերրաֆորմ:
Պատմության բարոյականությունը հետևյալն է. նույնիսկ եթե դու Ամազոնի ամեն ինչում գլխի վրա, դուք դեռ օգտագործում եք ինչ-որ բան, որը AWS-ից չէ, և այս ծառայություններն ունեն վիճակ, որն օգտագործում է կազմաձևման լեզու՝ այդ վիճակը համաժամեցված պահելու համար:
CloudFormation lambda vs 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-past են արել այլ նախագծերի հսկայական կտորներ իրենց սեփականի մեջ, իսկ հետո դրանք խառնել են մինչև այն սկսել է աշխատել: Կաշխատեի՞ք այսպես «մարտական» կոդով ձեր ընկերությունում: Մենք միայն գրադարաններից չենք օգտագործում: Այո, բայց ո՞ւր ենք մենք առանց ընդհանուր գրադարանների սկզբունքորեն:
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