Terraform-ի ենթակառուցվածքի նկարագրությունը ապագայի համար: Անտոն Բաբենկո (2018)

Շատերը գիտեն և օգտագործում են Terraform-ն իրենց ամենօրյա աշխատանքում, սակայն դրա լավագույն փորձը դեռ ձևավորված չէ: Յուրաքանչյուր թիմ պետք է հորինի իր մոտեցումներն ու մեթոդները։

Ձեր ենթակառուցվածքը գրեթե անկասկած սկսում է պարզ՝ մի քանի ռեսուրսներ + մի քանի մշակողներ: Ժամանակի ընթացքում այն ​​աճում է բոլոր տեսակի ուղղություններով: Գտնու՞մ եք միջոցներ Terraform մոդուլների մեջ խմբավորելու ռեսուրսները, ծածկագիրը թղթապանակների մեջ կազմակերպելու և էլ ի՞նչը կարող է սխալ լինել: (հայտնի վերջին բառերը)

Ժամանակն անցնում է, և դուք զգում եք, որ ձեր ենթակառուցվածքը ձեր նոր կենդանին է, բայց ինչո՞ւ: Ձեզ անհանգստացնում են ենթակառուցվածքի անբացատրելի փոփոխությունները, վախենում եք դիպչել ենթակառուցվածքին և ծածկագրին, արդյունքում՝ հետաձգում եք նոր ֆունկցիոնալությունը կամ նվազեցնում որակը...

Երեք տարի կառավարելով AWS-ի համար Terraform համայնքի մոդուլների հավաքածուն Github-ում և Terraform-ի երկարաժամկետ սպասարկումից հետո, Անտոն Բաբենկոն պատրաստ է կիսվել իր փորձով. ինչպես գրել TF մոդուլներ, որպեսզի ապագայում չվնասեն:

Զրույցի ավարտին մասնակիցները ավելի լավ կծանոթանան Terraform-ում ռեսուրսների կառավարման սկզբունքներին, Terraform-ում մոդուլների հետ կապված լավագույն փորձին և ենթակառուցվածքների կառավարման հետ կապված շարունակական ինտեգրման որոշ սկզբունքներին:

Ազատում պատասխանատվությունից: Նշում եմ, որ այս զեկույցը թվագրված է 2018 թվականի նոյեմբեր ամսին՝ արդեն 2 տարի է անցել։ Զեկույցում քննարկված Terraform 0.11 տարբերակն այլևս չի աջակցվում: Վերջին 2 տարիների ընթացքում թողարկվել է 2 նոր թողարկում, որոնք պարունակում են բազմաթիվ նորամուծություններ, բարելավումներ և փոփոխություններ։ Խնդրում ենք ուշադրություն դարձնել սրան և ստուգել փաստաթղթերը:

Հղումներ.

• terraform-community-modules + terraform-aws-modules
• antonbabenko/pre-commit-terraform — ավտոմատ ձևաչափման կոդը և փաստաթղթերը
• antonbabenko/terrapin - Terraform մոդուլների գեներատոր (WIP)
• antonbabenko/modules.tf-lambda - Terraform կոդերի գեներատոր տեսողական դիագրամներից (WIP)
• www.terraform-best-practices.com
• medium.com/@anton.babenko (Նոր գրառումները իմ անձնական կայքում www.antonbabenko.com/)
• @antonbabenko - Twitter, և մի շարք տարբեր Slacks

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

Ես աշխատում եմ Terraform-ի վրա և 2015 թվականից ակտիվ մասնակից և ներդրող եմ եղել Terraform-ի և Amazon-ի հետ կապված բազմաթիվ բաց կոդով նախագծերի:

Այդ ժամանակվանից ես բավականաչափ կոդ եմ գրել այն հետաքրքիր ձևով ներկայացնելու համար: Եվ ես հիմա կփորձեմ պատմել ձեզ այս մասին։

Ես կխոսեմ Terraform-ի հետ աշխատելու բարդությունների և առանձնահատկությունների մասին: Բայց դա իրականում HighLoad-ի թեման չէ: Եվ հիմա կհասկանաք, թե ինչու։

Ժամանակի ընթացքում ես սկսեցի գրել Terraform մոդուլներ: Օգտատերերը հարցեր են գրել, ես դրանք վերաշարադրել եմ։ Այնուհետև ես գրեցի տարբեր կոմունալ ծրագրեր՝ ծածկագիրը ֆորմատավորելու համար՝ օգտագործելով pre-commit hook և այլն:

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

Ես Ուկրաինայից եմ։ Ես երկար տարիներ ապրել եմ Նորվեգիայում։

Նաև այս զեկույցի համար տեղեկություններ են հավաքվել այն մարդկանցից, ովքեր գիտեն իմ անունը և գտնում են ինձ սոցիալական ցանցերում: Գրեթե միշտ նույն մականունն ունեմ։

https://github.com/terraform-aws-modules
https://registry.terraform.io/namespaces/terraform-aws-modules

Ինչպես նշեցի, ես Terraform AWS մոդուլների հիմնական սպասարկողն եմ, որը GitHub-ի ամենամեծ պահոցներից մեկն է, որտեղ մենք հյուրընկալում ենք մոդուլներ ամենատարածված առաջադրանքների համար՝ VPC, Autoscaling, RDS:

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

Terraform-ը հայտնվեց 2014 թվականին որպես օգտակար ծրագիր, որը թույլ էր տալիս գրել, պլանավորել և կառավարել ենթակառուցվածքը որպես կոդ: Հիմնական հասկացությունն այստեղ «ենթակառուցվածքը որպես ծածկագիր» է։

Բոլոր փաստաթղթերը, ինչպես ասացի, գրված են terraform.io. Հուսով եմ, որ շատերը գիտեն այս կայքի մասին և կարդացել են փաստաթղթերը: Եթե ​​այո, ուրեմն դուք ճիշտ տեղում եք։

Ահա թե ինչ տեսք ունի սովորական Terraform կազմաձևման ֆայլը, որտեղ մենք նախ սահմանում ենք որոշ փոփոխականներ:

Այս դեպքում մենք սահմանում ենք «aws_region»:

Այնուհետև մենք նկարագրում ենք, թե ինչ ռեսուրսներ ենք ուզում ստեղծել:

Մենք գործարկում ենք որոշ հրամաններ, մասնավորապես «terraform init»-ը՝ կախվածությունները և մատակարարները բեռնելու համար:

Եվ մենք գործարկում ենք «terraform application» հրամանը, որպեսզի ստուգենք, թե արդյոք նշված կոնֆիգուրացիան համապատասխանում է մեր ստեղծած ռեսուրսներին: Քանի որ մենք նախկինում ոչինչ չենք ստեղծել, Terraform-ը մեզ հուշում է ստեղծել այս ռեսուրսները:

Մենք դա հաստատում ենք։ Այսպիսով, մենք ստեղծում ենք մի դույլ, որը կոչվում է seasnail:

Կան նաև մի քանի նմանատիպ կոմունալ ծառայություններ: Ձեզանից շատերը, ովքեր օգտագործում են Amazon-ը, գիտեն AWS CloudFormation կամ Google Cloud Deployment Manager կամ Azure Resource Manager: Նրանցից յուրաքանչյուրն ունի իր որոշակի իրականացումը այս հանրային ամպային մատակարարներից յուրաքանչյուրի ներսում ռեսուրսների կառավարման համար: Terraform-ը հատկապես օգտակար է, քանի որ թույլ է տալիս կառավարել ավելի քան 100 պրովայդեր: (Ավելի մանրամասն այստեղ)

Այն նպատակները, որոնք Terraform-ը հետապնդել է հենց սկզբից.

• Terraform-ը տրամադրում է ռեսուրսների մեկ տեսակետ:
• Թույլ է տալիս աջակցել բոլոր ժամանակակից հարթակներին:
• Իսկ Terraform-ը հենց սկզբից նախագծվել է որպես օգտակար ծրագիր, որը թույլ է տալիս անվտանգ և կանխատեսելի կերպով փոխել ենթակառուցվածքը:

2014 թվականին «կանխատեսելի» բառն այս համատեքստում շատ անսովոր էր հնչում։

Terraform-ը ունիվերսալ կոմունալ ծրագիր է: Եթե ​​ունեք API, ապա կարող եք վերահսկել բացարձակապես ամեն ինչ.

• Դուք կարող եք օգտագործել ավելի քան 120 պրովայդեր՝ կառավարելու այն ամենը, ինչ ցանկանում եք:
• Օրինակ, դուք կարող եք օգտագործել Terraform-ը՝ նկարագրելու մուտքը GitHub-ի պահոցներ:
• Դուք նույնիսկ կարող եք ստեղծել և փակել սխալներ Jira-ում:
• Դուք կարող եք կառավարել New Relic չափումները:
• Դուք նույնիսկ կարող եք ֆայլեր ստեղծել dropbox-ում, եթե իսկապես ցանկանում եք:

Այս ամենը ձեռք է բերվում Terraform պրովայդերների միջոցով, որոնք ունեն բաց API, որը կարելի է նկարագրել Go-ում:

Ենթադրենք, մենք սկսեցինք օգտագործել Terraform-ը, կարդացինք որոշ փաստաթղթեր կայքում, դիտեցինք մի քանի տեսանյութ և սկսեցինք գրել main.tf, ինչպես ցույց էի տալիս նախորդ սլայդներում:

Եվ ամեն ինչ հիանալի է, դուք ունեք ֆայլ, որը ստեղծում է VPC:

Եթե ​​ցանկանում եք ստեղծել VPC, ապա նշեք մոտավորապես այս 12 տողերը: Նկարագրեք, թե որ տարածաշրջանում եք ցանկանում ստեղծել, IP հասցեների որ cidr_block օգտագործել: Այսքանը:

Բնականաբար, նախագիծն աստիճանաբար կաճի։

Եվ դուք այնտեղ կավելացնեք մի շարք նոր նյութեր՝ ռեսուրսներ, տվյալների աղբյուրներ, դուք կինտեգրվեք նոր մատակարարների հետ, հանկարծ կցանկանաք օգտագործել Terraform-ը՝ ձեր GitHub հաշվում օգտատերերին կառավարելու համար և այլն: Կարող եք օգտագործել տարբեր: DNS մատակարարներ, խաչեք ամեն ինչ: Terraform-ը դա հեշտացնում է:

Դիտարկենք հետևյալ օրինակը.

Դուք աստիճանաբար ավելացնում եք internet_gateway-ը, քանի որ ցանկանում եք, որ ձեր VPC-ի ռեսուրսներն ունենան ինտերնետ հասանելիություն: Սա լավ գաղափար է:

Արդյունքը հետևյալն է main.tf:

Սա main.tf-ի վերին հատվածն է:

Սա main.tf-ի ներքևի հատվածն է:

Այնուհետև ավելացնում եք ենթացանցը: Մինչ դուք ցանկանում եք ավելացնել NAT դարպասներ, երթուղիներ, երթուղային աղյուսակներ և մի շարք այլ ենթացանցեր, դուք կունենաք ոչ թե 38 տող, այլ մոտավորապես 200-300 տող:

Այսինքն՝ ձեր main.tf ֆայլը աստիճանաբար մեծանում է։ Եվ բավականին հաճախ մարդիկ ամեն ինչ դնում են մեկ ֆայլի մեջ։ 10-20 Կբ հայտնվում է main.tf. Պատկերացրեք, որ 10-20 Կբ-ը տեքստային բովանդակություն է: Եվ ամեն ինչ կապված է ամեն ինչի հետ։ Սրա հետ աշխատելն աստիճանաբար դժվար է դառնում։ 10-20 Kb-ը լավ օգտագործողի դեպք է, երբեմն ավելի շատ: Եվ մարդիկ միշտ չէ, որ կարծում են, որ դա վատ է:

Ինչպես սովորական ծրագրավորման դեպքում, այսինքն՝ ոչ ենթակառուցվածքում որպես կոդ, մենք սովոր ենք օգտագործել մի շարք տարբեր դասեր, փաթեթներ, մոդուլներ, խմբավորումներ: Terraform-ը թույլ է տալիս անել մոտավորապես նույն բանը:

• Կոդն աճում է։
• Ռեսուրսների միջև կախվածությունը նույնպես աճում է:

Իսկ մենք մեծ, մեծ կարիք ունենք։ Մենք հասկանում ենք, որ այլևս չենք կարող այսպես ապրել։ Մեր կոդը դառնում է հսկայական: 10-20 Kb-ը, իհարկե, այնքան էլ մեծ չէ, բայց մենք խոսում ենք միայն ցանցային ստեկի մասին, այսինքն՝ դուք միայն ավելացրել եք ցանցային ռեսուրսներ: Մենք չենք խոսում Application Load Balancer-ի, տեղակայման ES կլաստերի, Kubernetes-ի և այլնի մասին, որտեղ 100 Կբ հեշտությամբ կարելի է հյուսել: Եթե ​​այս ամենը գրեք, շատ շուտով կիմանաք, որ Terraform-ը տրամադրում է Terraform մոդուլներ։

Terraform մոդուլները ինքնամփոփ Terraform կոնֆիգուրացիա են, որը կառավարվում է որպես խումբ: Դա այն ամենն է, ինչ դուք պետք է իմանաք Terraform մոդուլների մասին: Նրանք բոլորովին խելացի չեն, թույլ չեն տալիս ինչ-որ բանից կախված բարդ կապեր հաստատել։ Այս ամենը ընկնում է մշակողների ուսերին: Այսինքն, սա պարզապես Terraform-ի մի տեսակ կոնֆիգուրացիա է, որը դուք արդեն գրել եք: Եվ դուք կարող եք պարզապես զանգահարել այն որպես խումբ:

Այսպիսով, մենք փորձում ենք հասկանալ, թե ինչպես ենք օպտիմալացնելու մեր 10-20-30 Կբ ծածկագիրը: Մենք աստիճանաբար հասկանում ենք, որ պետք է որոշ մոդուլներ օգտագործել։

Մոդուլների առաջին տեսակը, որը դուք հանդիպում եք, ռեսուրսային մոդուլներ են: Նրանք չեն հասկանում, թե ինչի մասին է ձեր ենթակառուցվածքը, ինչի մասին է ձեր բիզնեսը, որտեղ և ինչ պայմաններ կան։ Սրանք հենց այն մոդուլներն են, որոնք ես, բաց կոդով համայնքի հետ միասին, կառավարում ենք, և որոնք մենք առաջ ենք քաշել որպես ձեր ենթակառուցվածքի սկզբնական շինարարական բլոկներ:

Ռեսուրսների մոդուլի օրինակ:

Երբ մենք կանչում ենք ռեսուրսի մոդուլը, մենք նշում ենք, թե որ ճանապարհից պետք է բեռնենք դրա բովանդակությունը:

Մենք նշում ենք, թե որ տարբերակն ենք ուզում ներբեռնել։

Մենք այնտեղ փաստարկների մի փունջ ենք փոխանցում։ Այսքանը: Դա այն ամենն է, ինչ մենք պետք է իմանանք այս մոդուլն օգտագործելիս:

Շատերը կարծում են, որ եթե օգտագործեն վերջին տարբերակը, ամեն ինչ կայուն կլինի։ Բայց ոչ. Ենթակառուցվածքը պետք է տարբերակված լինի, մենք պետք է հստակ պատասխանենք, թե որ տարբերակի վրա է տեղակայվել այս կամ այն ​​բաղադրիչը։

Ահա կոդը, որը գտնվում է այս մոդուլի ներսում: Անվտանգության խմբի մոդուլ. Այստեղ ոլորումը գնում է 640-րդ տող։ Անվտանգության կռուպ ռեսուրսի ստեղծումը Amazon-ում ցանկացած հնարավոր կոնֆիգուրացիայով շատ ոչ տրիվիալ խնդիր է: Բավական չէ պարզապես ստեղծել անվտանգության խումբ և ասել, թե ինչ կանոններ պետք է փոխանցել նրան։ Դա շատ պարզ կլիներ։ Ամազոնի ներսում միլիոնավոր տարբեր սահմանափակումներ կան: Օրինակ, եթե դուք օգտագործում եք VPC վերջնակետ, նախածանցների ցուցակ, տարբեր API-ներ և փորձում է այս ամենը համատեղել մնացած ամեն ինչի հետ, ապա Terraform-ը թույլ չի տալիս դա անել։ Իսկ Amazon API-ն նույնպես դա թույլ չի տալիս: Հետևաբար, մենք պետք է թաքցնենք այս ամբողջ սարսափելի տրամաբանությունը մոդուլի մեջ և օգտատիրոջը տանք հենց այսպիսի տեսքի կոդը։

Օգտագործողը կարիք չունի իմանալու, թե ինչպես է այն պատրաստված ներսում։

Մոդուլների երկրորդ տեսակը, որը բաղկացած է ռեսուրսային մոդուլներից, արդեն լուծում է խնդիրներ, որոնք ավելի կիրառելի են ձեր բիզնեսի համար։ Հաճախ սա այն վայրն է, որը Terraform-ի ընդլայնումն է և սահմանում է որոշ կոշտ արժեքներ պիտակների, ընկերության ստանդարտների համար: Այնտեղ կարող եք նաև ավելացնել գործառույթներ, որոնք Terraform-ը ներկայումս թույլ չի տալիս օգտագործել: Սա հենց հիմա է: Այժմ 0.11 տարբերակը, որը պատրաստվում է դառնալ անցյալի բան: Բայց այնուամենայնիվ, նախապրոցեսորները, jsonnet-ը, cookiecutter-ը և մի շարք այլ բաներ այն օժանդակ մեխանիզմն են, որոնք պետք է օգտագործվեն լիարժեք աշխատանքի համար:

Հաջորդիվ ես ցույց կտամ դրա մի քանի օրինակներ:

Ենթակառուցվածքի մոդուլը կանչվում է ճիշտ նույն կերպ։

Նշված է աղբյուրը, որտեղից կարելի է ներբեռնել բովանդակությունը։

Արժեքների մի փունջ փոխանցվում և փոխանցվում են այս մոդուլին:

Հաջորդը, այս մոդուլի ներսում մի խումբ ռեսուրսների մոդուլներ կանչվում են VPC կամ Application Load Balancer ստեղծելու կամ անվտանգության խումբ ստեղծելու կամ Elastic Container Service կլաստերի համար:

Կան երկու տեսակի մոդուլներ. Սա կարևոր է հասկանալ, քանի որ այս զեկույցում իմ կողմից խմբավորված տեղեկատվության մեծ մասը գրված չէ փաստաթղթերում:

Եվ Terraform-ի փաստաթղթերն այս պահին բավականին խնդրահարույց են, քանի որ այն պարզապես ասում է, որ կան այս հնարավորությունները, դուք կարող եք դրանք օգտագործել: Բայց նա չի ասում, թե ինչպես օգտագործել այս հնարավորությունները, ինչու է ավելի լավ օգտագործել դրանք: Հետևաբար, շատ մեծ թվով մարդիկ գրում են մի բան, որի հետ նրանք չեն կարող ապրել:

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

Terraform ռեգիստր - https://registry.terraform.io/

Հուշում #0-ը ռեսուրսների մոդուլներ չգրելն է: Այս մոդուլների մեծ մասն արդեն գրված է ձեզ համար: Ինչպես ասացի, դրանք բաց կոդ են, չեն պարունակում ձեր բիզնեսի տրամաբանությունը, չունեն կոշտ կոդավորված արժեքներ IP հասցեների, գաղտնաբառերի և այլնի համար։ Մոդուլը շատ ճկուն է։ Եվ դա ամենայն հավանականությամբ արդեն գրված է։ Amazon-ի ռեսուրսների համար շատ մոդուլներ կան: Մոտ 650. Եվ դրանց մեծ մասը որակյալ է։

Այս օրինակում ինչ-որ մեկը եկավ ձեզ մոտ և ասաց. «Ես ուզում եմ կարողանամ կառավարել տվյալների բազան: Ստեղծեք մոդուլ, որպեսզի կարողանամ ստեղծել տվյալների բազա»: Անձը չգիտի Amazon-ի կամ Terraform-ի իրականացման մանրամասները: Նա պարզապես ասում է. «Ես ուզում եմ կառավարել MSSQL»: Այսինքն՝ նկատի ունենք, որ նա կկանչի մեր մոդուլը, այնտեղ կփոխանցի շարժիչի տեսակը և կնշի ժամային գոտին։

Եվ մարդը չպետք է իմանա, որ այս մոդուլի ներսում մենք կստեղծենք երկու տարբեր ռեսուրսներ՝ մեկը MSSQL-ի համար, երկրորդը՝ մնացած ամեն ինչի համար, միայն այն պատճառով, որ Terraform 0.11-ում չեք կարող նշել ժամային գոտու արժեքները որպես ընտրովի:

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

Սա երկրորդ փաստարկն է, որը բավականին կարևոր է, եթե դուք երկար ժամանակ օգտագործում եք Terraform-ը: Դուք ունեք պահեստ, որտեղ տեղադրում եք ձեր բոլոր Terraform մոդուլները ձեր ընկերության համար: Եվ միանգամայն նորմալ է, որ ժամանակի ընթացքում այս նախագիծը կհասնի մեկ կամ երկու մեգաբայթի։ Սա լավ է:

Բայց խնդիրն այն է, թե ինչպես է Terraform-ը անվանում այս մոդուլները: Օրինակ, եթե դուք մոդուլ եք կանչում յուրաքանչյուր առանձին օգտատեր ստեղծելու համար, Terraform-ը նախ բեռնելու է ամբողջ պահոցը, այնուհետև նավարկելու է այն թղթապանակը, որտեղ գտնվում է տվյալ մոդուլը: Այս կերպ դուք ամեն անգամ ներբեռնելու եք մեկ մեգաբայթ։ Եթե ​​դու կառավարում ես 100 կամ 200 օգտատեր, ապա կներբեռնես 100 կամ 200 մեգաբայթ, հետո կգնաս այդ թղթապանակը։ Այսպիսով, բնականաբար, դուք չեք ցանկանում ներբեռնել մի շարք նյութեր ամեն անգամ, երբ սեղմում եք «Terraform init»:

https://github.com/mbtproject/mbt

Այս խնդրի երկու լուծում կա. Առաջինը հարաբերական ուղիների օգտագործումն է: Այս կերպ կոդի մեջ նշում եք, որ թղթապանակը տեղական է (./): Եվ նախքան որևէ բան գործարկելը, դուք տեղական տարածքում կատարում եք այս պահոցի Git կլոնավորումը: Այս կերպ դուք դա անում եք մեկ անգամ:

Կան, իհարկե, շատ բացասական կողմեր: Օրինակ, դուք չեք կարող օգտագործել տարբերակը: Եվ սրա հետ երբեմն դժվար է ապրել:

Երկրորդ լուծում. Եթե ​​դուք ունեք շատ ենթամոդուլներ և արդեն ունեք հաստատված խողովակաշար, ապա կա MBT նախագիծը, որը թույլ է տալիս հավաքել բազմաթիվ տարբեր փաթեթներ մոնոպոզիտորիայից և վերբեռնել դրանք S3: Սա շատ լավ միջոց է։ Այսպիսով, iam-user-1.0.0.zip ֆայլը կկշռի ընդամենը 1 Կբ, քանի որ այս ռեսուրսի ստեղծման կոդը շատ փոքր է: Եվ դա շատ ավելի արագ կաշխատի:

Եկեք խոսենք այն մասին, թե ինչ չի կարող օգտագործվել մոդուլներում:

Ինչու է այս չարիքը մոդուլներում: Ամենավատ բանը օգտվողին ենթադրելն է: Ենթադրենք, որ օգտվողը մատակարարի նույնականացման տարբերակ է, որը կարող է օգտագործվել տարբեր մարդկանց կողմից: Օրինակ՝ բոլորս կյուրացնենք դերը։ Սա նշանակում է, որ Terraform-ը կստանձնի այս դերը: Եվ հետո այս դերով նա կկատարի այլ գործողություններ։

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

Երկրորդ չարիքը մատակարարողն է։ Այստեղ չարիքն այնքան էլ տրիվիալ չէ, քանի որ եթե դուք գրում եք կոդ, և այն աշխատում է ձեզ մոտ, ապա կարող եք մտածել, որ եթե այն աշխատում է, ապա ինչու փոխել այն։

Չարությունն այն է, որ դուք միշտ չէ, որ վերահսկում եք, թե երբ կգործարկվի այս մատակարարը, առաջին հերթին: Եվ երկրորդը, դուք չեք վերահսկում, թե ինչ է նշանակում aws ec2, այսինքն հիմա մենք խոսում ենք Linux-ի կամ Windows-ի մասին: Այսպիսով, դուք չեք կարող գրել մի բան, որը նույն կերպ կաշխատի տարբեր օպերացիոն համակարգերում կամ տարբեր օգտագործողների դեպքերի համար:

Ամենատարածված օրինակը, որը նշված է նաև պաշտոնական փաստաթղթերում, այն է, որ եթե դուք գրում եք aws_instance և նշում եք մի շարք փաստարկներ, ապա դրանում ոչ մի վատ բան չկա, եթե այնտեղ նշեք «local-exec» մատակարարը և գործարկեք ձեր ansible-ը: խաղագիրք.

Իրականում, այո, դրանում ոչ մի վատ բան չկա։ Բայց բառացիորեն շուտով դուք կհասկանաք, որ այս local-exec բանը գոյություն չունի, օրինակ, launch_configuration-ում:

Եվ երբ դուք օգտագործում եք launch_configuration, և ցանկանում եք ստեղծել autoscaling խումբ մեկ օրինակից, ապա launch_configuration-ում չկա «provisioner» հասկացություն: Գոյություն ունի «օգտագործողի տվյալներ» հասկացությունը:

Հետևաբար, ավելի ունիվերսալ լուծում է օգտագործողի տվյալների օգտագործումը: Եվ այն կգործարկվի կամ բուն օրինակում, երբ օրինակը միացված է, կամ նույն օգտատիրոջ տվյալների մեջ, երբ autoscaling խումբն օգտագործի այս launch_configuration-ը:

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

Եվ դրա համար ամենաճիշտ ռեսուրսը կոչվում է null_resource: Null_resource-ը կեղծ ռեսուրս է, որն իրականում երբեք չի ստեղծվում: Այն ոչ մի բանի չի դիպչում, ոչ մի API-ի, ոչ ավտոմատ մասշտաբավորման: Բայց դա թույլ է տալիս վերահսկել, թե երբ գործարկել հրամանը: Այս դեպքում հրամանը գործարկվում է ստեղծման ժամանակ:

ՈՒղեցույց http://bit.ly/common-traits-in-terraform-modules

Կան մի քանի նշաններ. Ես չեմ մանրամասնի բոլոր նշանները: Այս մասին հոդված կա. Բայց եթե դուք աշխատել եք Terraform-ի հետ կամ օգտագործել եք այլ մարդկանց մոդուլներ, ապա հաճախ եք նկատել, որ շատ մոդուլներ, ինչպես բաց կոդով կոդերի մեծ մասը, գրված են մարդկանց կողմից իրենց կարիքների համար: Մի մարդ գրեց ու լուծեց իր խնդիրը։ Ես այն կպցրի GitHub-ում, թող ապրի: Այն կապրի, բայց եթե այնտեղ փաստաթղթեր ու օրինակներ չկան, ուրեմն ոչ ոք չի օգտագործի։ Եվ եթե չկա որևէ ֆունկցիոնալություն, որը թույլ է տալիս լուծել իր կոնկրետ առաջադրանքից մի փոքր ավելին, ապա ոչ ոք նույնպես չի օգտագործի այն: Օգտագործողներին կորցնելու շատ եղանակներ կան:

Եթե ​​ցանկանում եք ինչ-որ բան գրել, որպեսզի մարդիկ օգտագործեն այն, ապա խորհուրդ եմ տալիս հետևել այս նշաններին.

Սա է `

• Փաստաթղթեր և օրինակներ.
• Ամբողջական ֆունկցիոնալություն:
• Խելամիտ կանխադրումներ:
• Մաքուր կոդը:
• Թեստեր:

Թեստերն այլ իրավիճակ են, քանի որ դրանք բավականին դժվար է գրել: Ես ավելի շատ հավատում եմ փաստաթղթերին և օրինակներին:

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

Սա փաստաթղթերի մոխրագույն մասն է: Դուք այժմ կարող եք մտածել. «Ինչ-որ բան անհասկանալի է: Համոզված չեմ»։ Բայց մենք կտեսնենք վեց ամսից:

Հիմա եկեք խոսենք, թե ինչպես կարելի է զանգահարել այս մոդուլները:

Մենք հասկանում ենք, որ մեր կոդը մեծանում է ժամանակի ընթացքում: Այլևս մեկ ֆայլ չունենք, մենք արդեն ունենք 20 ֆայլ։ Նրանք բոլորը մեկ թղթապանակում են: Կամ գուցե հինգ թղթապանակ: Միգուցե մենք սկսում ենք դրանք ինչ-որ կերպ բաժանել ըստ տարածաշրջանների, որոշ բաղադրիչների։ Հետո մենք հասկանում ենք, որ հիմա ունենք համաժամացման և նվագախմբի որոշ տարրական տարրեր։ Այսինքն՝ մենք պետք է հասկանանք, թե ինչ պետք է անենք, եթե փոխենք ցանցային ռեսուրսները, ինչ պետք է անենք մեր մնացած ռեսուրսների հետ, ինչպես առաջացնենք այդ կախվածությունները և այլն։

Երկու ծայրահեղություն կա. Առաջին ծայրահեղությունը բոլորը մեկում է: Մենք ունենք մեկ հիմնական ֆայլ: Առայժմ սա Terraform կայքի պաշտոնական լավագույն փորձն էր:

Բայց հիմա գրված է հնացած ու հանված։ Ժամանակի ընթացքում Terraform համայնքը հասկացավ, որ դա հեռու է լավագույն փորձից, քանի որ մարդիկ սկսեցին օգտագործել նախագիծը տարբեր ձևերով: Իսկ խնդիրներ կան։ Օրինակ, երբ մենք թվարկում ենք բոլոր կախվածությունները մեկ տեղում: Լինում են իրավիճակներ, երբ մենք սեղմում ենք «Terraform plan»-ը և մինչև Terraform-ը թարմացնի բոլոր ռեսուրսների վիճակները, կարող է շատ ժամանակ անցնել:

Շատ ժամանակ, օրինակ, 5 րոպե է։ Ոմանց համար սա շատ ժամանակ է: Ես տեսել եմ դեպքեր, երբ դա տևել է 15 րոպե: AWS API-ն 15 րոպե ծախսեց՝ փորձելով պարզել, թե ինչ է կատարվում յուրաքանչյուր ռեսուրսի վիճակի հետ: Սա շատ մեծ տարածք է։

Եվ, բնականաբար, հարակից խնդիր կառաջանա, երբ ուզում ես ինչ-որ բան փոխել մեկ տեղում, հետո սպասում ես 15 րոպե, և դա քեզ տալիս է որոշ փոփոխությունների կտավ։ Դուք թքեցիք, գրեցիք «Այո», և ինչ-որ բան սխալ ստացվեց: Սա շատ իրական օրինակ է։ Terraform-ը չի փորձում պաշտպանել ձեզ խնդիրներից: Այսինքն՝ ինչ ուզում ես, գրիր։ Խնդիրներ կլինեն՝ ձեր խնդիրները: Մինչ Terraform 0.11-ը չի փորձում որևէ կերպ օգնել ձեզ: 0.12-ում կան որոշակի հետաքրքիր վայրեր, որոնք թույլ են տալիս ասել. «Վասյա, դու իսկապես ուզում ես սա, կարո՞ղ ես խելքի գալ»:

Երկրորդ ճանապարհը այս տարածքի կրճատումն է, այսինքն՝ մի տեղից զանգերը կարող են ավելի քիչ միացված լինել մեկ այլ վայրից։

Միակ խնդիրն այն է, որ դուք պետք է ավելի շատ կոդ գրեք, այսինքն, դուք պետք է նկարագրեք փոփոխականները մեծ թվով ֆայլերում և թարմացնեք սա: Որոշ մարդկանց դա դուր չի գալիս: Սա նորմալ է ինձ համար։ Եվ ոմանք մտածում են. «Ինչու՞ սա գրել տարբեր տեղերում, ես այդ ամենը կդնեմ մեկ տեղում»: Սա հնարավոր է, բայց սա երկրորդ ծայրահեղությունն է։

Ո՞վ ունի այս ամենը մեկ տեղում: Մեկ, երկու, երեք հոգի, այսինքն՝ ինչ-որ մեկն օգտագործում է։

Իսկ ո՞վ է անվանում մեկ կոնկրետ բաղադրիչ, մեկ բլոկ կամ մեկ ենթակառուցվածքային մոդուլ: Հինգից յոթ հոգի: Սա թույն է:

Ամենատարածված պատասխանը ինչ-որ տեղ մեջտեղում է: Եթե ​​նախագիծը մեծ է, ապա դուք հաճախ կունենաք այնպիսի իրավիճակ, երբ ոչ մի լուծում հարմար չէ, և ամեն ինչ չէ, որ ստացվում է, այնպես որ դուք հայտնվում եք խառնուրդով: Սրա մեջ վատ բան չկա, քանի դեռ հասկանում ես, որ երկուսն էլ առավելություններ ունեն։

Եթե ​​ինչ-որ բան փոխվել է stack VPC-ում, և դուք ցանկանում էիք կիրառել այս փոփոխությունները EC2-ի վրա, այսինքն՝ ցանկանում էիք թարմացնել autoscaling խումբը, քանի որ ունեիք նոր ենթացանց, ապա ես անվանում եմ այս տեսակի կախվածության կազմակերպում: Կան որոշ լուծումներ. ով ինչ է օգտագործում:

Ես կարող եմ առաջարկել, թե ինչ լուծումներ կան։ Դուք կարող եք օգտագործել Terraform-ը կախարդություն անելու համար, կամ կարող եք օգտագործել makefiles՝ Terraform-ն օգտագործելու համար: Եվ տեսեք, թե արդյոք այնտեղ ինչ-որ բան փոխվել է, կարող եք այն գործարկել այստեղ:

Ինչպե՞ս է ձեզ դուր գալիս այս որոշումը: Որևէ մեկը հավատու՞մ է, որ սա հիանալի լուծում է: Ես ժպիտ եմ տեսնում, ակնհայտորեն կասկածներ են ներթափանցել:

Իհարկե, մի փորձեք սա տանը: Terraform-ը երբեք չի նախագծվել Terraform-ից գործարկվելու համար:

Մի զեկույցում նրանք ինձ ասացին. «Ոչ, սա չի աշխատի»: Բանն այն է, որ դա չպետք է աշխատի։ Թեև այնքան տպավորիչ է թվում, երբ կարող եք Terraform-ը գործարկել Terraform-ից, այնուհետև Terraform-ից, դուք չպետք է դա անեք: Terraform-ը միշտ պետք է շատ հեշտ սկսվի:

https://github.com/gruntwork-io/terragrunt/

Եթե ​​Ձեզ անհրաժեշտ է զանգերի նվագախումբ, երբ ինչ-որ բան փոխվել է մեկ տեղում, ապա կա Terragrunt:

Terragrunt-ը օգտակար ծրագիր է՝ Terraform-ի հավելում, որը թույլ է տալիս համակարգել և կազմակերպել ենթակառուցվածքային մոդուլների զանգերը:

Տիպիկ Terraform կազմաձևման ֆայլն այսպիսի տեսք ունի.

Դուք նշում եք, թե կոնկրետ որ մոդուլն եք ուզում զանգահարել:

Ի՞նչ կախվածություն ունի մոդուլը:

Իսկ ինչ փաստարկներ է ընդունում այս մոդուլը։ Ահա այն ամենը, ինչ պետք է իմանալ Terragrunt-ի մասին:

Փաստաթղթերն այնտեղ են, և GitHub-ում կա 1 աստղ: Բայց շատ դեպքերում սա այն է, ինչ դուք պետք է իմանաք: Եվ սա շատ հեշտ է իրականացնել այն ընկերություններում, որոնք նոր են սկսում աշխատել Terraform-ի հետ։

Այսպիսով, նվագախումբը Terragrunt է: Կան այլ տարբերակներ.

Հիմա եկեք խոսենք այն մասին, թե ինչպես աշխատել կոդի հետ:

Եթե ​​Ձեզ անհրաժեշտ է նոր հնարավորություններ ավելացնել ձեր կոդը, շատ դեպքերում դա հեշտ է: Դուք նոր ռեսուրս եք գրում, ամեն ինչ պարզ է։

Եթե ​​դուք ունեք մի ռեսուրս, որը նախապես ստեղծել եք, օրինակ, Terraform-ի մասին իմացել եք AWS հաշիվ բացելուց հետո և ցանկանում եք օգտագործել այն ռեսուրսները, որոնք արդեն ունեք, ապա տեղին կլինի ձեր մոդուլը ընդլայնել այս կերպ, որպեսզի այն աջակցում է առկա ռեսուրսների օգտագործմանը:

Եվ աջակցեց նոր ռեսուրսների ստեղծմանը, օգտագործելով բլոկային ռեսուրսը:

Ելքի վրա մենք միշտ վերադարձնում ենք ելքային ID-ն՝ կախված նրանից, թե ինչ է օգտագործվել:

Terraform 0.11-ում երկրորդ շատ կարևոր խնդիրը ցուցակների հետ աշխատելն է:

Դժվարությունն այն է, որ եթե մենք ունենանք օգտագործողների նման ցուցակ.

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

Ցուցակների հետ աշխատել պետական ​​միջավայրում: Ի՞նչ է պետական ​​միջավայրը: Սա այն իրավիճակն է, երբ նոր արժեք է ստեղծվում, երբ ստեղծվում է այս ռեսուրսը: Օրինակ՝ AWS Access Key կամ AWS Secret Key, այսինքն՝ երբ մենք ստեղծում ենք օգտատեր, մենք ստանում ենք նոր Access կամ Secret Key: Եվ ամեն անգամ, երբ մենք ջնջում ենք օգտվողին, այս օգտվողը կունենա նոր բանալի: Բայց սա ֆենգ շույ չէ, քանի որ օգտատերը չի ցանկանա մեզ հետ ընկերանալ, եթե ամեն անգամ, երբ ինչ-որ մեկը հեռանում է թիմից, նրա համար նոր օգտատեր ստեղծենք։

Սա է լուծումը։ Սա Jsonnet-ով գրված կոդը է: Jsonnet-ը Google-ի կաղապարային լեզու է:

Այս հրամանը թույլ է տալիս ընդունել այս ձևանմուշը և որպես արդյունք այն վերադարձնում է json ֆայլ, որը պատրաստված է ձեր ձևանմուշին համապատասխան:

Կաղապարն այսպիսի տեսք ունի.

Terraform-ը թույլ է տալիս աշխատել ինչպես HCL-ի, այնպես էլ Json-ի հետ նույն կերպ, այնպես որ, եթե դուք ունեք Json գեներացնելու հնարավորություն, ապա կարող եք այն սահեցնել Terraform-ի մեջ: .tf.json ընդլայնմամբ ֆայլը հաջողությամբ կներբեռնվի:

Եվ հետո մենք աշխատում ենք դրա հետ ինչպես միշտ՝ terraform init, terramorm application: Եվ մենք ստեղծում ենք երկու օգտվող:

Հիմա մենք չենք վախենում, եթե ինչ-որ մեկը հեռանա թիմից։ Մենք պարզապես կխմբագրենք json ֆայլը: Վասյա Պուպկինը գնաց, Պետյա Պյատոչկինը մնաց։ Պետյա Պյատոչկինը նոր բանալի չի ստանա.

Terraform-ի ինտեգրումն այլ գործիքների հետ իրականում Terraform-ի գործը չէ: Terraform-ը ստեղծվել է որպես ռեսուրսներ ստեղծելու հարթակ և վերջ։ Եվ այն ամենը, ինչ հայտնվում է ավելի ուշ, Terraform-ի մտահոգությունը չէ: Եվ այնտեղ հյուսելու կարիք չկա։ Կա Ansible, որն անում է այն ամենը, ինչ ձեզ հարկավոր է:

Բայց իրավիճակներ են առաջանում, երբ մենք ցանկանում ենք երկարացնել Terraform-ը և ինչ-որ բան ավարտելուց հետո ինչ-որ հրաման կանչել:

Առաջին ճանապարհը. Մենք ստեղծում ենք ելք, որտեղ գրում ենք այս հրամանը:

Եվ այնուհետև մենք կանչում ենք այս հրամանը shell terraform ելքից և նշում ենք մեր ուզած արժեքը: Այսպիսով, հրամանը կատարվում է բոլոր փոխարինված արժեքներով: Շատ հարմարավետ է։

Երկրորդ ճանապարհ. Սա null_resource-ի օգտագործումն է՝ կախված մեր ենթակառուցվածքի փոփոխություններից: Մենք կարող ենք զանգահարել նույն local-exe-ն, հենց որ որոշ ռեսուրսի ID-ն փոխվի:

Բնականաբար, այս ամենը հարթ է թղթի վրա, քանի որ Amazon-ը, ինչպես բոլոր հանրային պրովայդերները, ունի իր եզրային պատյանների մի փունջ:

Ամենատարածված եզրային դեպքն այն է, որ երբ բացում եք AWS հաշիվ, կարևոր է, թե որ շրջաններն եք օգտագործում. արդյո՞ք այս գործառույթը միացված է այնտեղ; գուցե բացել եք այն 2013 թվականի դեկտեմբերից հետո; գուցե դուք օգտագործում եք լռելյայն VPC-ում և այլն: Կան բազմաթիվ սահմանափակումներ: Եվ Amazon-ը դրանք սփռեց ամբողջ փաստաթղթերում:

Կան մի քանի բաներ, որոնցից խորհուրդ եմ տալիս խուսափել:

Սկսելու համար խուսափեք բոլոր ոչ գաղտնի փաստարկներից Terraform պլանի կամ Terraform CLI-ի ներսում: Այս ամենը կարող է դրվել կա՛մ tfvars ֆայլի, կա՛մ միջավայրի փոփոխականի մեջ:

Բայց ձեզ հարկավոր չէ անգիր անել այս ողջ կախարդական հրամանը: Terraform plan – var, և մենք գնում ենք: Առաջին փոփոխականը var է, երկրորդը՝ var, երրորդը՝ չորրորդը։ Ենթակառուցվածքի ամենակարևոր սկզբունքը որպես ծածկագիր, որը ես օգտագործում եմ ամենից հաճախ, այն է, որ պարզապես նայելով կոդը՝ ես պետք է հստակ պատկերացում ունենամ, թե ինչ է տեղակայված այնտեղ, ինչ վիճակում և ինչ արժեքներով: Եվ այսպես, ես ստիպված չեմ կարդալ փաստաթղթերը կամ հարցնել Վասյային, թե ինչ պարամետրեր է նա օգտագործել մեր կլաստերը ստեղծելու համար: Պարզապես պետք է բացեմ tfvars ընդլայնմամբ ֆայլը, որը հաճախ համընկնում է միջավայրի հետ, ու այնտեղ ամեն ինչ նայեմ։

Բացի այդ, մի օգտագործեք թիրախային փաստարկներ՝ շրջանակը նվազեցնելու համար: Դրա համար շատ ավելի հեշտ է օգտագործել փոքր ենթակառուցվածքային մոդուլներ:

Նաև պետք չէ սահմանափակել և ավելացնել զուգահեռությունը։ Եթե ​​ես ունեմ 150 ռեսուրս և ուզում եմ Amazon-ի զուգահեռությունը լռելյայն 10-ից հասցնել 100-ի, ապա, ամենայն հավանականությամբ, ինչ-որ բան սխալ կլինի: Կամ կարող է լավ լինել հիմա, բայց երբ Amazon-ն ասում է, որ դուք չափազանց շատ զանգեր եք կատարում, դուք դժվարության մեջ կլինեք:

Terraform-ը կփորձի վերագործարկել այս խնդիրների մեծ մասը, բայց դուք գրեթե ոչնչի չեք հասնի: Parallelism=1-ը կարևոր բան է, որը պետք է օգտագործվի, եթե AWS API-ի կամ Terraform մատակարարի ներսում ինչ-որ սխալի հանդիպեք: Եվ հետո դուք պետք է նշեք՝ parallelism=1 և սպասեք, մինչև Terraform-ը ավարտի մեկ զանգը, հետո երկրորդը, հետո երրորդը։ Նա դրանք մեկ առ մեկ կգործարկի։

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

Աշխատանքային տարածքները չեն ստեղծվել օգտվողների կողմից: Սա չի նշանակում, որ օգտատերերը GitHub-ի համարներում գրել են, որ մենք չենք կարող ապրել առանց Terraform աշխատանքային տարածքների: Ոչ, այսպես չէ: Terraform Enterprise-ը կոմերցիոն լուծում է: Terraform-ը HashiCorp-ից որոշեց, որ մեզ անհրաժեշտ են աշխատանքային տարածքներ, ուստի մենք այն հեռացրեցինք: Ինձ համար շատ ավելի հեշտ է այն դնել առանձին թղթապանակում: Հետո մի քիչ ավելի շատ ֆայլեր կլինեն, բայց ավելի պարզ կլինի։

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

Զեկույցի թեման գրված էր «ապագայի համար»։ Այս մասին շատ կարճ կխոսեմ։ Ապագայի համար դա նշանակում է, որ 0.12-ը շուտով կթողարկվի:

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

Բայց! Եթե ​​դուք ավելի քիչ ու ավելի պարզ եք գրում՝ օգտագործելով պատրաստի մոդուլներ և երրորդ կողմի լուծումներ, ապա ստիպված չեք լինի սպասել և հուսալ, որ 0.12-ը կգա և կուղղի ամեն ինչ ձեզ համար:

Շնորհակալություն զեկույցի համար: Դուք խոսեցիք ենթակառուցվածքի մասին որպես կոդ և բառացիորեն մեկ բառ ասացիք թեստերի մասին: Արդյո՞ք անհրաժեշտ են թեստեր մոդուլներում: Ո՞ւմ պատասխանատվությունն է սա: Արդյո՞ք ես պետք է ինքս գրեմ, թե՞ դա մոդուլների պատասխանատվությունն է:

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

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

Հողատարածք ամենահաճախ հիշատակվող գրադարաններից մեկն է, որը թույլ է տալիս գրել ինտեգրացիոն թեստեր Terraform-ի համար: Սա կոմունալ ծառայություններից մեկն է։ Ես նախընտրում եմ DSL տեսակը, օրինակ՝ rspec։

Անտոն, շնորհակալություն զեկույցի համար: Իմ անունը Վալերի է։ Մի փոքր փիլիսոփայական հարց տամ. Կա պայմանականորեն ապահովում, կա տեղակայում։ Տրամադրումը ստեղծում է իմ ենթակառուցվածքը, տեղակայման ժամանակ մենք այն լրացնում ենք ինչ-որ օգտակար բանով, օրինակ՝ սերվերներ, հավելվածներ և այլն: Եվ իմ գլխում է, որ Terraform-ը ավելի շատ տրամադրման համար է, իսկ Ansible-ն ավելի շատ տեղակայման համար է, քանի որ Ansible-ը նաև ֆիզիկական էթակառուցվածքի համար է։ թույլ է տալիս տեղադրել nginx, Postgres: Բայց միևնույն ժամանակ, Ansible-ը, կարծես, թույլ է տալիս տրամադրել, օրինակ, Amazon-ի կամ Google-ի ռեսուրսները: Բայց Terraform-ը նաև թույլ է տալիս տեղակայել որոշ ծրագրեր՝ օգտագործելով իր մոդուլները: Ձեր տեսանկյունից, կա՞ ինչ-որ սահման, որն անցնում է Terraform-ի և Ansible-ի միջև, որտեղ և ինչն է ավելի լավ օգտագործել: Կամ, օրինակ, կարծում եք, որ Ansible-ն արդեն աղբ է, դուք պետք է փորձեք օգտագործել Terraform-ը ամեն ինչի համար։

Լավ հարց, Վալերի: Ես կարծում եմ, որ Terraform-ը նպատակային առումով չի փոխվել 2014 թվականից: Այն ստեղծվել է ենթակառուցվածքների համար և մահացել են ենթակառուցվածքների համար։ Մենք դեռ ունեինք և կունենանք Ansible կոնֆիգուրացիայի կառավարման կարիք: Խնդիրն այն է, որ launch_configuration-ում առկա են օգտվողի տվյալներ: Եվ ահա դու քաշում ես Անսիբլին և այլն: Սա ստանդարտ տարբերակն է, որն ինձ ամենաշատն է դուր գալիս:

Եթե ​​մենք խոսում ենք գեղեցիկ ենթակառուցվածքի մասին, ապա կան Packer-ի նման կոմունալ ծառայություններ, որոնք հավաքում են այս պատկերը: Եվ այնուհետև Terraform-ն օգտագործում է տվյալների աղբյուրը՝ այս պատկերը գտնելու և դրա launch_configuration-ը թարմացնելու համար: Այսինքն, այս կերպ խողովակաշարն այն է, որ մենք նախ քաշում ենք Tracker-ը, ապա քաշում ենք Terraform-ը: Եվ եթե կառուցումը տեղի է ունենում, ապա տեղի է ունենում նոր փոփոխություն:

Բարեւ Ձեզ! Շնորհակալություն զեկույցի համար: Ես Միշան եմ, RBS ընկերություն: Դուք կարող եք զանգահարել Ansible-ին մատակարարի միջոցով ռեսուրս ստեղծելիս: Ansible-ն ունի նաև թեմա, որը կոչվում է դինամիկ գույքագրում: Եվ դուք կարող եք նախ զանգահարել Terraform-ին, ապա զանգահարել Ansible-ին, որը պետությունից ռեսուրսներ կվերցնի և կկատարի այն: Ինչն է ավելի լավ:

Մարդիկ երկուսն էլ օգտագործում են հավասար հաջողությամբ։ Ինձ թվում է, որ Ansible-ում դինամիկ գույքագրումը հարմար բան է, եթե խոսքը autoscaling խմբի մասին չէ։ Քանի որ autoscaling խմբում մենք արդեն ունենք մեր սեփական գործիքակազմը, որը կոչվում է launch_configuration։ launch_configuration-ում մենք գրանցում ենք այն ամենը, ինչ պետք է գործարկվի, երբ ստեղծում ենք նոր ռեսուրս: Հետևաբար, Amazon-ի հետ դինամիկ գույքագրման օգտագործումը և Terraform ts ֆայլը կարդալը, իմ կարծիքով, չափազանցված է: Եվ եթե դուք օգտագործում եք այլ գործիքներ, որտեղ չկա «autoscaling group» հասկացություն, օրինակ՝ դուք օգտագործում եք DigitalOcean կամ որևէ այլ մատակարար, որտեղ չկա autoscaling խումբ, ապա այնտեղ դուք պետք է ձեռքով քաշեք API-ն, գտնեք IP հասցեներ, ստեղծեք գույքագրման դինամիկ ֆայլ, և Ansible-ն արդեն կշրջվի դրա միջով: Այսինքն՝ Amazon-ի համար կա launch_configuration, իսկ մնացած ամեն ինչի համար՝ դինամիկ գույքագրում։

Source: www.habr.com