Վերադարձել եմ Terraform-ից CloudFormation՝ և ափսոսում եմ

Վարկածային ենթակառուցումը ներկայացնել կոդի տեսքով՝ կրկնվող տեքստային ձևաչափով, սկսել է լավագույն բանաձևերից մեկը համակարգերի համար, որից անհրաժեշտ չէ հրաժարվել։ Այս պրակտիկայի անվանումն է՝ Ինչպես ենթակառուցումը որպես կոդ՝ և այս պրակտիկան իրականացնելիս, հատկապես AWS-ում, կա երկու տարածված գործիք՝ Terraform և CloudFormation.

Որոշում եմ համեմատել Terraform-ի և CloudFormation-ի հետ կապված փորձերը

Մինչև իմ գալը Twitch (այնպիսի же Amazon Jr.) ես աշխատել եմ մի ստարտափում և երեք տարի օգտագործել եմ Terraform։ Իմ նոր վայրում ես նույնպես լայնորեն օգտագործում էի Terraform, մինչ ընկերությունը որոշեց անցնել ամբողջովին Amazon ձևին, ներառյալ CloudFormation-ն։ Ես զգալի աշխատանք կատարել եմ երկու գործիքների լավագույն պրակտիկաների մշակման վրա, և երկուսն էլ օգտագործել եմ շատ բարդ աշխատանքային ընթացքներում կազմակերպության մասշտաբով։ Հետագայում, ուշադիր գնահատելով Terraform-ից CloudFormation-ի անցման հետևանքները, ես համոզվեցի, որ Terraform, հավանաբար, լավագույն ընտրությունն է կազմակերպության համար։

Terraform Սա հոգնեցուցիչ է

Ծրագրային ապահովման բետա-տարբերակ

Terraform դեռ նույնիսկ 1.0 տարբերակը չի ունեցել, և սա հիմնավոր պատճառ է այն չօգտագործելու։ Այն ժամանակ, երբ ես առաջին անգամ փորձեցի այն, այն շատ էր փոխվել, սակայն այդ ժամանակ terraform apply մոտոհետեւաբար, հաճախ թերանում էր մի քանի թարմացումներից կամ պարզապես մի քանի տարվա օգտագործումից հետո։ Ես կասեի, որ «այժմ ամեն ինչ տարբեր է», սակայն… կարծես, բոլորը այսպես են ասում, չէ՞։ Կան փոփոխություններ, որոնք անհամատեղելի են նախորդ տարբերակների հետ, թեև դրանք պահանջված են, և նույնիսկ կա զգացումը, որ ռեսուրսների պահոցների սինտաքսն ու տարրեր ճիշտ են։ Գործիքը երևում է դեռևս իսկապես դարձել է ավելի լավ, բայց… :-0

Հակառակ դեպքում, AWS-ն լավ աշխատանք է կատարել, պահպանելով նախորդ տարբերակների հետ համատեղելիությունը։ Թերևս, որովհետև նրանց ծառայությունները փայլուն փորձարկվում են ընկերության ներսում, և միայն հետո, անվանումը փոխելով, հրապարակվում են։ Ուստի «լավ աշխատանք է կատարել» դեռ ձանձրալի ասված է։ API-ների նախորդ տարբերակների հետ համատեղելիության պահպանելը նման բազմազան և բարդ համակարգի համար, ինչպիսին AWS-ն է, անհավատալի դժվար է։ Որքա՛ն էլ որ նրանք տառապել են հանրային API-ները պահպանելու համար, ինչպիսի լայն օգտագործման համար, պետք է հասկանալ, թե որքան դժվար է դա անել տարիների ընթացքում։ Իսկ CloudFormation-ի վարքագիծը իմ հիշողություներում երբևէ չի փոխվել անցնող տարիների ընթացքում։

Բարի գալուստ, ոտք… սա գնդակ է

Որքան գիտեմ, ռեսուրսը հեռացնել արտաքին CloudFormation ստեկից ձեր CF ստեկը չեք կարող տեղափոխել: Թերևս դա նման է Terraform-ին: Այն թույլ է տալիս գոյություն ունեցող ռեսուրսները ներմուծել ձեր ստեկը: Այս ֆունկցիան, կարելի է ասել, զարմանալի է, բայց մեծ ուժի հետ գալիս է նաև մեծ պատասխանատվություն: Պարզապես ռեսուրսը ստեկին ավելացնելու դեպքում, մինչեւ աշխատեք ձեր ստեկի հետ, հնարավոր չէ ջնջել կամ փոխել այդ ռեսուրսը: Ու einmal սա ինձ վրա անդրադարձավ: Ինչ-որ մեկը Twitch-ի կայքում, առանց որևէ վատ մտադրության, պատահաբար մի AWS անվտանգության խումբ ներմուծեց իր սեփական Terraform ստեկին: Մի քանի կոմանտ մտցրեց և... անվտանգության խումբը (միասին՝ ներհոսող տրաֆիկով) անհետացավ.

Terraform Կարևոր է

Հետ վերադարձ՝ անբավարար վիճակներից

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

Terraform, հակառակը, մի կերպ վերականգնում է անհաջող փուլերից ավելի վայելավետ եւ առաջարկում է ընդլայնված սխեմայի մատակարարում:

More clear document state changes

«Լավ, բեռնման բալանսировщик, դու փոխվում ես: Բայց ինչպես?»

- մտահոգված ինժեներ, պատրաստ է սեղմել «ընդունել» կոճակը.

Sometimes I need to make some manipulations with the load balancer in the CloudFormation stack — for instance, add a port number or modify a security group. CloudFormation shows changes poorly. I, however, double-check the yaml file ten times or so, to ensure that I haven’t deleted anything essential and haven’t added anything unnecessary.

Terraform is much clearer in this regard. Sometimes it even gets too transparent (read: annoying). Fortunately, the latest version includes improved change visualization — now it’s clear what changes.

Ճկունություն

Write software backwards.

To be straightforward, the most important distinctive feature of long-lasting software is its ability to adapt to changes. Write any software backwards. I often stumbled upon taking a 'simple' service, and then started trying to cram everything into a single CloudFormation or Terraform stack. And of course, after months it turned out that I hadn’t understood everything correctly, and the service was really not simple! And now I need to somehow break a large stack into smaller components. When working with CloudFormation, this can be done only by first recreating the existing stack, which I don’t do with my databases. On the other hand, Terraform allowed dissecting the stack into more understandable smaller parts.

Modules in git

Terraform-ի կոդը բաժանել բազմաթիվ ստեկերի միջև շատ ավելի հեշտ է, քան CloudFormation-ի կոդը: Terraform-ով կարող եք կոդը տեղադրել git ռեպոզիտորիայում և դիմել նրան, օգտագործելով սեմանտիկ տարբերակների կառավարում: Ով էլ, որ ունենա մուտք այդ ռեպոզիտորիայում, կարող է կրկին օգտագործել ընդհանուր կոդը: CloudFormation-ի համարժեքը S3-ն է, բայց դրա նույն առավելությունները չկան, և չկա ոչ մի պատճառ, որ մենք պետք է հրաժարվենք git-ից՝ ի օգուտ S3-ի:

Հիմնարկը աճում էր, և ընդհանուր ստեկեր բաժանելու կարողությունը հասավ քննադատական մակարդակի: Terraform-ով բոլորն հեշտ և բնական կերպով ստացվում են, մինչդեռ CloudFormation-ը ստիպում է ձեզ օղակներով ցատկել, մինչև դուք ստանաք ինչ-որ նման բան:

Operations as code

«Սկրիպտենք, և վերջ».

— ինժեներ 3 տարի առաջ, մինչև Terraform-ը հայտնաբերելը.

Արհեստականորեն գործարկելով ծրագրավորման մշակման մեջ Go կամ Java ծրագիր, դա պարզապես կոդ չէ.

Code as Code

Սակայն կա նաև ենթակառուցվածքը, որի վրա այն աշխատում է.

Ինչպես ենթակառուցումը որպես կոդ

Բայց այն որտեղից եկավ? Ինչպես պետք է այն մոնիտորել? Որտեղ է ձեր կոդը? Պետք է արդյոք մշակողների համար հասցե ունենալ:

Operations as Code

Ծրագրային մշակող լինելու նշանակում է, որ դուք պարզապես կոդ չեք գրում.

Ոչ միայն AWS: Դուք հավանաբար օգտագործում եք այլ մատակարարների ծառայություններ: SignalFx, PagerDuty կամ Github: Որպեսզի, գուցե ունեք ներքին Jenkins սերվեր CI/CD-ի համար կամ ներքին Grafana մոնիտորինգի վահանակ: Infra as Code ընտրվում է բազմաթիվ պատճառներով, և յուրաքանչյուրն էլ equally կարևոր է ծրագրային բոլոր ոլորտների համար:

Երբ ես աշխատում էի Twitch-ում, մենք արագացնում էինք ծառայությունները խառնված տեղադրված համակարգերում և Amazon-ի AWS համակարգերում: Մենք դրոշմում էինք և պահպանում բազմաթիվ միկրոծառայություններ, մեծացնելով շահագործման ծախսերը: Լսումները տեղի էին ունենում հետևյալ կերպ.

• Ես: Ահ, չափազանց շատ շարժումներ մեկ միկրոծառայությունը արագացնելու համար: Սա ինձ հարկավոր է, որպեսզի ստեղծեմ AWS հաշիվ (մենք գնում էին 2 հաշիվների վրա միկրոծառայություն), հետո այս — ծանուցումների կարգավորման համար, հետո սա — կոդի ռեպոզիտորիային, և այս — էլեկտրոնային հասցեների ցուցակին, և այս ևս...
• Դիտարկում: Սկրիպտենք, և վերջ.
• Ես: Լավ, բայց ինքն սկրիպտը կունենա փոփոխություն: Կպահանջվի մի եղանակ, թե ինչպես պետք է ստուգել, որ այդ ամենն Amazon-ի ներկառուցված միջոցները ունեն актуальное состояние.
• Դիտարկում: Եղբայր, լավ է: Եվ դրա համար մենք կգրենք սկրիպտ.
• Ես: Հիանալի! Ամանակը պետք է նաև պարամետրեր մշակում: Նա ընդունի դրանք?
• Դիտարկում: Այո, կհանդիպի, ինչ վերաբերում է սրան!
• Ես: Պրոցեսը կարող է փոխվել, կորցնելով հետադարձ համատեղելիությունը: Պետք է ինչ-որ սեմանտիկ տարբերակների կառավարում:
• Դիտարկում: Գերազանց գաղափար!
• Ես: Գործիքները կարող են փոխվել ձեռքով, օգտվողի ինտերֆեյսի ներսում: Մենք պետք է եղանակ, թե ինչպես դա ստուգել և շտկել.

…3 տարի անց:

• Դիտարկում: Եվ մենք ստացանք terraform.

Մորալը այսպես է. անգամ եթե դուք մեծ սիրով եք Amazon-ի մեջ, դեռ մի բան էլ, դուք օգտագործում եք այլ ծառայություններ, որոնք չեն հանդիսանում AWS-ից, և այս ծառայություններում կա վիճակ, որը օգտագործում է լեզուն դրանց Կոնֆիգուրացիան ճիշտ սինխրոնիզացնելու համար։

CloudFormation lambda և git-մոդուլներ terraform

lambda-ն CloudFormation-ի լուծումն է օգտագործողի տրամադրուող տրամաբանության հարցի համար։ Lambda-ի միջոցով կարող եք ստեղծել մակրոներ կամ ապահող ռեսուրս. Այս մոտեցումը ներկայացնում է լրացուցիչ բարդություններ, որոնք չկան Git մոդուլների սեմանտիկ տարբերակման մեջ Terraform-ում։ Ինձ համար ամենակարևոր խնդիրներից մեկը դարձավ գրանտների կառավարումը բոլոր այս անձնական lambda-ների համար (իսկ դա տասնյակ AWS հաշիվներ է)։ Մյուս կարևորությունը դարձավ «ինչի՞ն ինչն առաջ եկավ՝ պաշտոնաբանն, թե սուննդը» հարցը, որը կապված էր lambda-ի կոդի հետ։ Այս ինքնաբերաբար գործառույթը՝ ենթակառուցվածք և կոդ, և նա ինքն էր պահանջում մշակում և թարմացումներ։ Վերջին պատասխաններից մեկն էր lambda կոդի փոփոխությունների սեմանտիկ թարմացումները դժվարության մասին. պետք էր անել այնպես, որ կառավարման գործողությունները առանց անմիջական հրամանի չունենային փոփոխություններ տարբեր գործարկումների միջև։

Ախր, հիշում եմ, որ ցանկացա ստեղծել կլարետային տեղադրում Elastic Beanstalk միջավայրի համար ավանդական բեռների բաշխիչի միջոցով։ Այն ամենաբարդ կլիներ, եթե հարցնեի երկրորդ տեղադրումն EB-ի համար արտադրական միջավայրի կողքին, կատարելով մեկ քայլ՝ ավտոմատորեն սանդղակումների կլարետային տեղադրման խմբը միացնել LB արտադրական միջավայրի տեղադրմանը։ Այժմ, երբ Terraform-ն օգտագործում է ASG beantalk իբրև ելք, դա պահանջում է 4 ավելորդ կոդային տող Terraform-ում։ Երբ հարցրի, թե կա՞ արդյոք համապատասխանում լուծում CloudFormation-ում, ինձ ցույց տվեցին git-ում մի ամբողջ ռեպոզիտոր, անցումները և մնացածը մեկ տեղահանության համար, և ամեն ինչ դա՝ մեկ դժբախտ 4 տողի կոդի համար։

Այն լավ է հայտնաբերում ջրի թեթևությունը

Համոզվեք, որ իրականությունը համապատասխանում է սպասումները։

Հայտնաբերման ջրի թեթևությունը — շատ հզոր գործառնություն որպես կոդ, քանի որ օգնում է համոզել, որ իրականությունը համապատասխանում է սպասումներին։ Այն հասանելի է թե CloudFormation-ի, թե Terraform-ի հետ։ Բայց աշխատանակի սանդղակի աճում, ջրի թեթևության հայտնաբերման գործընթացում CloudFormation-ն տալիս էր ավելորդ բացահայտման արդյունքներ։

עם Terraform դուք ունեք շատ առաջադեմ կյանքի ցիկլի հալումները ջրի թեթևություն հայտնաբերելու համար։ Օրինակ դուք մուտք եք ներմուծում հրամանը ignore_changes այն ուղիղ ECS վերաձևման մեջ, եթե ցանկանում եք անտեսել վերաձևման որևէ կոնկրետ փոփոխություններ առանց էլ ունենալով լիովին թոշակի դիրքերում։

CDK և CloudFormation-ի ապագան

CloudFormation-ը դժվար է կառավարել մեծ, միջին ենթակառուցվածքների իրավիճակներում։ Հատկապես այդ դժվարություններից շատերն ընդունված են, և գործիքին անհրաժեշտ են նման բաներ, ինչպիսիք են aws-cdk, կառուցվածքը Ամազոնի CloudFormation-ով ամպային ենթակառուցվածքի սահմանման համար: Interesting կլինի տեսնել, թե ինչ է սպասվում aws-cdk-ին ապագայում, բայց դա դժվար կլիներ մրցակցել Terraform-ի այլ առավելությունների հետ; CloudFormation-ը ավելի մրցունակ դարձնելու համար անհրաժեշտ են գլոբալ փոփոխություններ։

Որպեսզի Terraform-ը ձեզ չհիասթափեցնի

Այս համար «ճարտարապետություն որպես ԿՈԴ» է, այլ ոչ թե «ինչպես տեքստ»։

Ես առաջին տպավորությունրս ունեցա Terraform-ի մասին մտահոգիչ: Որպեսզի հասկանամ մոտեցումը, մտածում եմ։ ՄAlmost բոլոր ինժեներները առաջին ժամանակ հպանցիկ ընկալում են այն որպես տեքստային ձևաչափ, որը պետք է վերածվի ցանկալի ենթակառուցվածքի: ԲԱՐՁՐՉՈՒՄ ՉԷ, ՈՐՏԵ՞Ւ։

Ծրագրային ապահովման զարգացման լավ ճշմարտությունները վերաբերում են նաև Terraform-ին

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

Ինչպե՞ս կարելի է որակյալ կոդ չավանդել։

Ես հանդիպել եմ տպավորիչ մեծ Terraform ստեկներին, որոնք ինչպես քաղաքականակերպեն բարձրաստիճան։ Ինչպե՞ս կարելի է գրել կոդ էջերով՝ առանց որևէ փաստաթղթավորման։ Ավելացրեք փաստաթղթավորում, որը բացատրում է ձեր կոդ Terraform (հարվածը այստեղ «կոդ» բառին)՝ ինչու է այս բաժինը այդքան կարևոր, և ինչ եք անում։

Ինչպե՞ս կարելի է զարգացնել ծառայություններ, որոնք նախկինում եղել են մեկ մեծ main() ֆունկցիա։

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

Դուք ձեր ընկերությունն օգտագործո՞ւմ է գրադարաններ:

Ես տեսել եմ, թե ինչպես են ինժեներները, նոր նախագիծ ստեղծելու համար Terraform-ով, հենց այնպես պաստայով այն մեծ կտորից, որ ձեռք բերել են իրենց սեփականներից և հետո կտրել, մինչև դա սկսեց աշխատել: Ինչքան պիտի ձեր ընկերությունում աշխատել այդպես «կռված» կոդի հետ? Մենք պարզապես չենք օգտագործում գրադարանները։ Այո, չունեք ամեն ինչ գրադարան պետք է լինի, բայց ուր ենք մենք առանց ընդհանուր գրադարանների ընդհանրապես?!

Դա դուք չէ՞, օգտագործում եք PEP8 կամ gofmt?

Շատ լեզուներում ընդունված ստանդարտ ձևաչափման սխեմա կա: Python-ում դա PEP8-ն է։ Go-ում՝ gofmt։ Terraform-ը ունի իր համար: terraform fmt. Օգտագործեք ազատության վրա!

Դուք կօգտագործեք React, առանց JavaScript-ի իմանալու՞:

Terraform մոդուլները կարող են հեշտացնել ստեղծած իր ենթակառուցվածքը, բայց դա չի նշանակում, որ ձեզ չի հետաքրքրի պահը։ Ուրեմն, ցանկանում եք ճիշտ օգտագործել Terraform-ը առանց ռեսուրսների իմացության: Դուք դատապարտված եք՝ ժամանակն անցնելու է, բայց դուք դեռ չեք освоացնի Terraform-ը։

Դուք կոդում եք սինգլտոնները, կամ կախվածություն մուտք գործելիս։

Ավտոմատացում՝ խոստացված ամենալավ պրակտիկան ծրագրային ապահովման զարգացում, որը նախընտրում են սինգլտոնները։ Ինչպես դա կարող է օգտակար լինել Terraform-ում։ Ես հանդիպել եմ Terraform մոդուլների, որոնք վաղեմի վիճակներից կախվածություն ունեն։ Փոխարենը, քանի որ դուք գրել եք մոդուլներ, որոնք արդյունք են առցանց վիճակից, գրեք մոդուլ, որը ընդունում է պարամետրեր։ Այնուհետև փոխանցեք այդ պարամետրերը մոդուլին։

Արդյոք ձեր գրադարանը տասը բան կատարո՞ւմ է լավ կամ մեկը՝ գերազանց։

Լավագույնը աշխատում են գրադարանները, որոնք կենտրոնանում են մի գործի վրա, որը նրանք կատարում են գերազանց։ Փոխարենը, քան գրել մեծ Terraform մոդուլներ, որոնք փորձում են անել ամեն բան միասին, կազմեք դրանք մասերից, որոնք լավ կատարում են ինչ-որ մի բան։ Այնուհետև համադրեք դրանք այնպես, ինչպես հարկավոր է։

Ինչպես եք գործում գրադարանը փոփոխություններ կատարելու ժամանակ հակառակ համապատասխանության։

Թեև ընդհանուր Terraform մոդուլը, ինչպես և սովորական գրադարանը, պետք է somehow հարցնել օգտագործողներին փոփոխություններ կատարելու մասին հակառակ համապատասխանության։ Երբ նման փոփոխություններ են տեղի ունենում գրադարաններում, դա irritates, և նույն կերպ irritates, երբ փոփոխություններն առանց հակառակ համապատասխանության են լինում Terraform մոդուլների մեջ։ Խորհուրդ է տրվում օգտագործել git tags և semver Terraform մոդուլներ օգտագործելիս։

Արդյոք արտադրական ծառայությունը գործարկվել է ձեր նոութբուքում կամ տվյալ կենտրոնում։

Hashicorp-ը ունի գործիքներ, ինչպես terraform cloud ձեր terraform-ը գործարկելու համար։ Այս կենտրոնացված ծառայությունները հեշտացնում են مدیریت, աուդիտ և Terraform-ի փոփոխությունների հաստատումը։

Դուք արդյոք չեք գրում թեստեր՞։

Հեշներ ընդունում են, որ ծածկագրերը պետք է փորձարկվեն, բայց հաճախ ինքներն էլ մոռանում են ստուգել, աշխատելով Terraform-ի հետ։ Ինֆրաստրուկտուրայի համար դա կարող է բերել խոտոր պահերի։ Ես խորհուրդ եմ տալիս «թեստեր» կամ «նախնական օրինակներ» ստեղծել փաթեթների օգտագործման հետ, որոնք կարող են ճիշտ տեղադրվել ստուգումների ժամանակ CI/CD-ի ընթացքում։

Terraform և միկրով υπηρεություններ

Միկրով ծառայությունների ընկերությունների կյանքն ու մահը կախված են արագության, թարմացման և նոր միկրով ծառայությունների աշխատանքային փաթեթների ոչնչացմաններից։

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

Ընտանիք: habr.com