Թվում է, թե Terraform-ի մշակողները առաջարկում են բավականին հարմար լավագույն փորձ AWS ենթակառուցվածքի հետ աշխատելու համար: Պարզապես մի նրբերանգ կա. Ժամանակի ընթացքում միջավայրերի թիվը մեծանում է, որոնցից յուրաքանչյուրն ունի իր առանձնահատկությունները: Հավելվածի փաթեթի գրեթե պատճենը հայտնվում է հարևան տարածաշրջանում: Իսկ Terraform կոդը պետք է խնամքով պատճենել և խմբագրել նոր պահանջներին համապատասխան կամ ձյան փաթիլ դարձնել:
Իմ զեկույցը Terraform-ի օրինաչափությունների մասին՝ պայքարելու քաոսի և ձեռքի առօրյայի դեմ մեծ և երկար նախագծերում:
Video:
Ես 40 տարեկան եմ, 20 տարի ՏՏ ոլորտում եմ: Ես աշխատում եմ Ixtens-ում արդեն 12 տարի։ Մենք զբաղվում ենք էլեկտրոնային առևտրի վրա հիմնված զարգացմամբ: Եվ ես զբաղվում եմ DevOps-ի պրակտիկայով արդեն 5 տարի։
Իմ պատմությունը կլինի իմ փորձի մասին մի նախագծում մի ընկերությունում, որի անունը չեմ ասի, որը թաքնվում է չբացահայտման համաձայնագրի հետևում:
Սլայդի վրա նշված թվերը նշված են նախագծի մասշտաբը հասկանալու համար: Եվ այն ամենը, ինչ ես կասեմ հաջորդիվ, կապված է Amazon-ի հետ։
Ես միացել եմ այս նախագծին 4 տարի առաջ։ Իսկ ենթակառուցվածքների վերամշակումն ընթանում էր ամբողջ թափով, քանի որ նախագիծն աճել էր: Իսկ այն նախշերը, որոնք օգտագործվում էին, արդեն հարմար չէին։ Եվ հաշվի առնելով նախագծի ողջ ծրագրված աճը, անհրաժեշտ էր նոր բան մտածել:
Շնորհակալություն Մատվեյին, ով երեկ պատմեց մեզ, թե ինչ է տեղի ունեցել Dodo Pizza-ում։ Ահա թե ինչ է տեղի ունեցել այստեղ 4 տարի առաջ.
Մշակողները եկան ու սկսեցին ենթակառուցվածքի ծածկագիրը կազմել։
Առավել ակնհայտ պատճառները, թե ինչու դա պահանջվեց, շուկայավարման ժամանակն էր: Անհրաժեշտ էր ապահովել, որ DevOps-ի թիմը թողարկման ընթացքում խոչընդոտ չլինի: Եվ ի թիվս այլ բաների, Terraform-ը և Puppet-ը օգտագործվել են հենց առաջին մակարդակում։
Terraform-ը HashiCorp-ի բաց կոդով նախագիծ է: Իսկ նրանց համար, ովքեր նույնիսկ չգիտեն, թե ինչ է սա, հաջորդ մի քանի սլայդները:
Ենթակառուցվածքը որպես ծածկագիր նշանակում է, որ մենք կարող ենք նկարագրել մեր ենթակառուցվածքը և խնդրել որոշ ռոբոտների համոզվել, որ մենք ստանում ենք մեր նկարագրած ռեսուրսները:
Օրինակ, մեզ անհրաժեշտ է վիրտուալ մեքենա: Մենք կնկարագրենք և կավելացնենք մի քանի պահանջվող պարամետր:
Դրանից հետո մենք կկարգավորենք մուտքը դեպի Amazon վահանակում: Եվ մենք կխնդրենք Terraform պլանը: Terraform պլանը կասի. «Լավ, մենք կարող ենք անել այս բաները ձեր ռեսուրսի համար»: Եվ կավելացվի առնվազն մեկ ռեսուրս։ Իսկ փոփոխություններ չեն սպասվում։
Երբ դուք գոհ եք ամեն ինչից, կարող եք խնդրել Terraform-ին դիմել, և Terraform-ը ձեզ համար կստեղծի օրինակ, և դուք կստանաք վիրտուալ մեքենա ձեր ամպում:
Հետագայում մեր նախագիծը զարգանում է: Մենք այնտեղ ավելացնում ենք որոշ փոփոխություններ։ Մենք խնդրում ենք ավելի շատ օրինակներ, մենք ավելացնում ենք 53 գրառում:
Եվ մենք կրկնում ենք. Խնդրում եմ պլանավորել: Տեսնում ենք, թե ինչ փոփոխություններ են նախատեսվում։ Մենք դիմում ենք. Եվ ահա թե ինչպես են աճում մեր ենթակառուցվածքները։
Terraform-ը օգտագործում է մի բան, որը կոչվում է պետական ֆայլեր: Այսինքն, բոլոր փոփոխությունները, որոնք գնում են Amazon, պահվում են մի ֆայլում, որտեղ ձեր նկարագրած յուրաքանչյուր ռեսուրսի համար կան համապատասխան ռեսուրսներ, որոնք ստեղծվել են Amazon-ում: Այսպիսով, երբ ռեսուրսի նկարագրությունը փոխվում է, Terraform-ը հստակ գիտի, թե ինչ է պետք փոխել Amazon-ում:
Այս պետական ֆայլերը սկզբնապես պարզապես ֆայլեր էին: Եվ մենք դրանք պահեցինք Git-ում, ինչը չափազանց անհարմար էր։ Ինչ-որ մեկը միշտ մոռանում էր փոփոխություններ կատարել, և շատ կոնֆլիկտներ էին ծագում:
Այժմ հնարավոր է օգտագործել backend-ը, այսինքն՝ Terraform-ը նշված է, թե որ դույլով և որ բանալիով պետք է պահպանվի պետական ֆայլը։ Եվ Terraform-ն ինքը կհոգա այս պետական ֆայլը ստանալու, ամբողջ կախարդանքն անելու և վերջնական արդյունքը հետ դնելու համար։
Մեր ենթակառուցվածքն աճում է։ Ահա մեր կոդը: Եվ հիմա մենք պարզապես չենք ցանկանում ստեղծել վիրտուալ մեքենա, մենք ցանկանում ենք ունենալ թեստային միջավայր:
Terraform-ը թույլ է տալիս ստեղծել այնպիսի բան, ինչպիսին է մոդուլը, այսինքն՝ նկարագրել նույնը ինչ-որ թղթապանակում։
Եվ, օրինակ, թեստավորման ժամանակ զանգահարեք այս մոդուլը և ստացեք նույն բանը, ինչ եթե մենք կատարած լինեինք Terraform application-ը հենց մոդուլում: Փորձարկման համար կլինի այս կոդը.
Արտադրության համար մենք կարող ենք որոշ փոփոխություններ ուղարկել այնտեղ, քանի որ թեստավորման ժամանակ մեզ մեծ ատյաններ պետք չեն, արտադրության մեջ մեծ օրինակները պարզապես օգտակար են։
Եվ հետո կվերադառնամ նախագծին։ Բարդ խնդիր էր, նախատեսված ենթակառուցվածքը շատ մեծ էր։ Եվ անհրաժեշտ էր ինչ-որ կերպ տեղադրել ամբողջ ծածկագիրը, որպեսզի այն հարմար լինի բոլորի համար՝ և՛ այս կոդի վրա սպասարկում կատարողների, և՛ փոփոխություններ կատարողների համար։ Եվ նախատեսվում էր, որ ցանկացած ծրագրավորող կարող է գնալ և շտկել ենթակառուցվածքը, ինչպես անհրաժեշտ է հարթակի իր մասի համար:
Սա գրացուցակի ծառ է, որը առաջարկվում է հենց HashiCorp-ի կողմից, եթե դուք ունեք մեծ նախագիծ, և իմաստ ունի ամբողջ ենթակառուցվածքը բաժանել որոշ փոքր մասերի և նկարագրել յուրաքանչյուր կտոր առանձին թղթապանակում:
Ունենալով ռեսուրսների ընդարձակ գրադարան, կարող եք մոտավորապես նույն բանը զանգահարել թեստավորման և արտադրության մեջ:
Մեր դեպքում սա լիովին հարմար չէր, քանի որ ծրագրավորողների կամ թեստավորման համար փորձնական փաթեթը պետք է ինչ-որ կերպ ավելի պարզ ստանար: Բայց ես չէի ուզում անցնել թղթապանակների միջով և կիրառել դրանք անհրաժեշտ հաջորդականությամբ, և անհանգստանալ, որ տվյալների բազան կբարձրանա, և այնուհետև կբարձրանա այս տվյալների բազան օգտագործող օրինակը: Հետևաբար, բոլոր փորձարկումները գործարկվել են մեկ թղթապանակից: Այնտեղ նույն մոդուլները կանչվեցին, բայց ամեն ինչ արվեց մեկ վազքով։
Terraform-ը հոգում է բոլոր կախվածությունները: Եվ այն միշտ ստեղծում է ռեսուրսներ հաջորդականությամբ, որպեսզի կարողանաք ստանալ IP հասցե, օրինակ, նոր ստեղծված օրինակից և ստանալ այս IP հասցեն route53 գրառումում։
Բացի այդ, հարթակը շատ մեծ է: Իսկ թեստային փաթեթ գործարկելը, թեկուզ մեկ ժամով, թեկուզ 8 ժամով, բավականին թանկ գործ է:
Եվ մենք ավտոմատացրել ենք այս հարցը: Եվ Ջենկինսի աշխատանքը թույլ տվեց մեզ վարել բուրգը: Դրանում անհրաժեշտ էր գործարկել ձգման հարցումը այն փոփոխություններով, որոնք մշակողը ցանկանում է փորձարկել, նշել բոլոր անհրաժեշտ տարբերակները, բաղադրիչները և չափերը: Եթե նա ցանկանում է կատարողականության թեստավորում, ապա նա կարող է ավելի շատ օրինակներ վերցնել: Եթե նա պարզապես պետք է ստուգի, որ ինչ-որ ձև է բացվում, ապա նա կարող է սկսել նվազագույն աշխատավարձից: Եվ նաև նշեք՝ կլաստերի կարիք կա, թե ոչ և այլն։
Եվ հետո Ջենկինսը հրեց shell-սկրիպտը, որը մի փոքր փոփոխեց Terraform թղթապանակի կոդը: Ես հեռացրեցի ավելորդ ֆայլերը և ավելացրեցի անհրաժեշտ ֆայլերը: Եվ հետո Terraform-ի մեկ գործարկումով կույտը բարձրացվեց:
Եվ հետո կային այլ քայլեր, որոնց մեջ ես չեմ ուզում գնալ:
Հաշվի առնելով այն հանգամանքը, որ թեստավորման համար մեզ անհրաժեշտ էին մի փոքր ավելի շատ տարբերակներ, քան արտադրության մեջ, մենք ստիպված էինք մոդուլների պատճեններ պատրաստել, որպեսզի այդ պատճեններում կարողանանք ավելացնել այն հնարավորությունները, որոնք անհրաժեշտ էին միայն փորձարկման համար:
Եվ այնպես ստացվեց, որ փորձարկման ժամանակ ես մի տեսակ ուզում եմ փորձարկել այն փոփոխությունները, որոնք ի վերջո կմտնեն արտադրություն: Բայց իրականում մի բան փորձարկվեց, և արտադրության մեջ օգտագործվեց մի փոքր այլ բան։ Եվ մի փոքր ընդմիջում եղավ այն օրինաչափության մեջ, որ արտադրության մեջ բոլոր փոփոխությունները կիրառվում էին շահագործման թիմի կողմից: Եվ երբեմն պարզվում էր, որ այդ փոփոխությունները, որոնք պետք է փորձարկումից անցնեին արտադրություն, մնում էին մեկ այլ տարբերակում։
Բացի այդ, նման խնդիր կար, որ ավելացվեց նոր ծառայություն, որը մի փոքր տարբերվում էր արդեն գոյություն ունեցողներից։ Եվ գոյություն ունեցող մոդուլը փոփոխելու փոխարեն մենք պետք է պատճենեինք դրա պատճենը և ավելացնեինք անհրաժեշտ փոփոխությունները։
Ըստ էության, Terraform-ը իրական լեզու չէ: Սա հռչակագիր է։ Եթե պետք է ինչ-որ բան հայտարարագրել, ուրեմն հայտարարում ենք։ Եվ ամեն ինչ աշխատում է:
Ինչ-որ պահի, երբ քննարկվում էր իմ ձգման խնդրանքը, գործընկերներիցս մեկն ասաց, որ կարիք չկա ձյան փաթիլներ ստեղծել։ Ես զարմացա, թե ինչ նկատի ուներ: Գիտական փաստ կա, որ աշխարհում երկու միանման ձյան փաթիլներ չկան, դրանք բոլորը մի փոքր տարբեր են: Եվ հենց որ լսեցի սա, ես անմիջապես զգացի Terraform կոդի ամբողջ ծանրությունը։ Քանի որ երբ անհրաժեշտ էր տարբերակից տարբերակ տեղափոխվել, Terraform-ը պահանջում էր ընդհատվող շղթայի փոփոխություններ, այսինքն՝ կոդը այլևս համատեղելի չէր հաջորդ տարբերակի հետ: Եվ մենք պետք է կատարեինք ձգման հարցում, որն ընդգրկում էր ենթակառուցվածքի ֆայլերի գրեթե կեսը, որպեսզի ենթակառուցվածքը հասցնենք Terraform-ի հաջորդ տարբերակին:
Եվ այսպիսի ձյան փաթիլի հայտնվելուց հետո ամբողջ Terraform ծածկագիրը, որը մենք վերածել էինք մի մեծ, մեծ ձյան կույտի։
Արտաքին ծրագրավորողի համար, ով գտնվում է գործողության սահմաններից դուրս, դա նրա համար մեծ նշանակություն չունի, քանի որ նա դիմել է ձգման հարցում, նրա ռեսուրսը սկսվել է: Եվ դա բոլորն է, դա այլևս նրա մտահոգությունը չէ: Եվ DevOps թիմը, ով համոզվում է, որ ամեն ինչ կարգին է, պարտավոր է կատարել այս բոլոր փոփոխությունները: Եվ այս փոփոխությունների արժեքը շատ ու շատ ավելացավ յուրաքանչյուր լրացուցիչ ձյան փաթիլի հետ:
Կա մի պատմություն այն մասին, թե ինչպես է սեմինարի ուսանողը գրատախտակի վրա կավիճով գծում երկու կատարյալ շրջան: Ու ուսուցիչը զարմանում է, թե ինչպես է նրան հաջողվել այդքան սահուն նկարել առանց կողմնացույցի։ Ուսանողը պատասխանում է. «Շատ պարզ, երկու տարի բանակում մսաղաց սարքելով եմ անցկացրել»:
Եվ չորս տարի, որ ես ներգրավված եմ այս նախագծում, շուրջ երկու տարի է, ինչ զբաղվում եմ Terraform-ով: Եվ, իհարկե, ես ունեմ որոշ հնարքներ, խորհուրդներ, թե ինչպես պարզեցնել Terraform կոդը, աշխատել դրա հետ ծրագրավորման լեզվի նման և նվազեցնել ծրագրավորողների բեռը, ովքեր պետք է թարմացնեն այս կոդը:
Առաջին բանը, որով ես կցանկանայի սկսել, Symlinks-ն է: Terraform-ն ունի շատ կրկնվող կոդ: Օրինակ, մատակարարին զանգը գրեթե բոլոր կետերում, որտեղ մենք ստեղծում ենք ենթակառուցվածքի մի հատված, նույնն է: Եվ տրամաբանական է այն դնել առանձին թղթապանակում: Եվ որտեղ էլ որ մատակարարից պահանջվի այս ֆայլին Symlinks ստեղծել:
Օրինակ, արտադրության մեջ դուք օգտագործում եք ստանձնել դերը, որը թույլ է տալիս մուտքի իրավունքներ ձեռք բերել Amazon-ի որոշ արտաքին հաշվում: Եվ մեկ ֆայլ փոխելով, ռեսուրսների ծառի բոլոր մնացածները կունենան պահանջվող իրավունքները, որպեսզի Terraform-ը իմանա, թե Amazon-ի որ հատվածին է հասանելի:
Որտե՞ղ են ձախողվում Symlinks-ը: Ինչպես ասացի, Terraform-ն ունի պետական ֆայլեր։ Եվ նրանք շատ, շատ թույն են: Բայց բանն այն է, որ Terraform-ը սկզբնավորում է հետին պլանը: Եվ նա չի կարող օգտագործել որևէ փոփոխական այս պարամետրերում, դրանք միշտ պետք է գրվեն տեքստով:
Եվ արդյունքում, երբ ինչ-որ մեկը պատրաստում է նոր ռեսուրս, նա պատճենում է կոդի մի մասը այլ թղթապանակներից: Եվ նա կարող է սխալվել բանալին կամ դույլի հետ: Օրինակ, նա ավազատուփից պատրաստում է ավազատուփ բան, հետո պատրաստում է արտադրության մեջ։ Եվ այսպես, կարող է ստացվել, որ արտադրության մեջ գտնվող դույլը կօգտագործվի ավազատուփից։ Իհարկե, արագ կգտնեն։ Դա հնարավոր կլինի ինչ-որ կերպ շտկել, բայց, այնուամենայնիվ, դա ժամանակի և որոշ չափով ռեսուրսների կորուստ է։
Ի՞նչ կարող ենք անել հետո: Նախքան Terraform-ի հետ աշխատելը, դուք պետք է նախաստորագրեք այն: Նախաստորագրման ժամանակ Terraform-ը ներբեռնում է բոլոր պլագինները: Ինչ-որ պահի նրանք բաժանվեցին մոնոլիտից դեպի ավելի միկրոծառայության ճարտարապետություն: Եվ դուք միշտ պետք է կատարեք Terraform init-ը, որպեսզի այն վեր քաշի բոլոր մոդուլները, բոլոր պլագինները:
Եվ դուք կարող եք օգտագործել shell script, որը, առաջին հերթին, կարող է ստանալ բոլոր փոփոխականները: Կեղևի սցենարը որևէ կերպ սահմանափակված չէ: Եվ, երկրորդ, ուղիները. Եթե մենք միշտ օգտագործենք այն ուղին, որը գտնվում է պահեստում, որպես պետական ֆայլի բանալի, ապա, համապատասխանաբար, այստեղ սխալը կվերացվի:
Որտեղ կարող եմ ստանալ տվյալները: JSON ֆայլ: Terraform-ը թույլ է տալիս ենթակառուցվածք գրել ոչ միայն hcl-ով (HashiCorp Configuration Language), այլ նաև JSON-ով։
JSON-ը հեշտ է կարդալ shell script-ից: Համապատասխանաբար, դուք կարող եք մի տեղ տեղադրել կոնֆիգուրացիայի ֆայլը դույլով: Եվ օգտագործեք այս դույլը և՛ Terraform կոդում, և՛ shell script-ում սկզբնավորման համար:
Ինչու՞ է կարևոր Terraform-ի համար դույլ ունենալը: Որովհետև գոյություն ունի հեռավոր վիճակի ֆայլեր: Այսինքն, երբ ես բարձրացնում եմ ինչ-որ ռեսուրս, որպեսզի Amazon-ին ասեմ. «Խնդրում եմ բարձրացնել օրինակը», ես պետք է նշեմ շատ պահանջվող պարամետրեր:
Եվ այս նույնացուցիչները պահվում են այլ թղթապանակում: Եվ ես կարող եմ գնալ և ասել. «Terraform, խնդրում եմ, վազիր հենց այդ ռեսուրսի պետական ֆայլը և ստացիր ինձ այս նույնացուցիչները»: Եվ այսպիսով որոշակի միավորում է առաջանում տարբեր շրջանների կամ միջավայրերի միջև։
Միշտ չէ, որ հնարավոր է օգտագործել հեռավոր պետական ֆայլը: Օրինակ, դուք ձեռքով ստեղծել եք VPC: Իսկ Terraform կոդը, որը ստեղծում է VPC-ն, ստեղծում է այնպիսի տարբեր VPC-ներ, որ շատ երկար ժամանակ կպահանջվի, և դուք ստիպված կլինեք հարմարեցնել մեկը մյուսին, այնպես որ կարող եք օգտագործել հետևյալ հնարքը.
Այսինքն՝ պատրաստեք մի մոդուլ, որը կարծես թե ստեղծում է VPC և, ինչպես որ ասես, ձեզ նույնացուցիչներ է տալիս, բայց իրականում կա պարզապես կոշտ կոդավորված արժեքներով ֆայլ, որը կարող է օգտագործվել նույն օրինակը ստեղծելու համար:
Միշտ չէ, որ անհրաժեշտ է պահպանել պետական ֆայլը ամպի մեջ: Օրինակ, մոդուլները փորձարկելիս կարող եք օգտագործել backend-ի սկզբնավորումը, որտեղ ֆայլը պարզապես կպահվի սկավառակի վրա փորձարկման պահին:
Հիմա մի փոքր փորձարկման մասին: Ի՞նչ կարող եք փորձարկել Terraform-ում: Հավանաբար շատ բան հնարավոր է, բայց ես կխոսեմ այս 4 բաների մասին։
HashiCorp-ը հասկանում է, թե ինչպես պետք է ֆորմատավորվի Terraform կոդը: Իսկ Terraform fmt-ը թույլ է տալիս ֆորմատավորել ձեր խմբագրած կոդը՝ ըստ այս համոզմունքի։ Համապատասխանաբար, թեստերը պետք է անպայման ստուգեն՝ արդյոք ֆորմատավորումը համապատասխանում է HashiCorp-ի կտակածին, որպեսզի անհրաժեշտություն չլինի փոխել փակագծերի տեղը և այլն։
Հաջորդը Terraform վավերացումն է: Դա ավելին է, քան ստուգել շարահյուսությունը - ala, արդյոք բոլոր փակագծերը զուգակցված են: Ի՞նչն է այստեղ կարևոր: Մեր ենթակառուցվածքը շատ ընդարձակ է։ Դրանում կան շատ տարբեր հայրիկներ: Եվ յուրաքանչյուրում դուք պետք է գործարկեք Terraform validate-ը:
Համապատասխանաբար, թեստավորումն արագացնելու համար մենք զուգահեռաբար իրականացնում ենք մի քանի գործընթացներ՝ օգտագործելով զուգահեռ:
Զուգահեռելը շատ թույն բան է, օգտագործիր։
Բայց ամեն անգամ, երբ Terraform-ը նախաստորագրում է, այն գնում է HashiCorp և հարցնում. «Որո՞նք են plugin-ի վերջին տարբերակները: Եվ այն փլագինը, որը ես ունեմ քեշում, դա ճի՞շտ է, թե՞ սխալ»: Եվ սա դանդաղում էր ամեն քայլափոխի։
Եթե դուք ասեք Terraform-ին, թե որտեղ են պլագինները, ապա Terraform-ը կասի. «Լավ, սա հավանաբար վերջին բանն է, որ կա: Ես ոչ մի տեղ չեմ գնա, ես անմիջապես կսկսեմ վավերացնել ձեր Terraform ծածկագիրը»:
Թղթապանակը անհրաժեշտ պլագիններով լրացնելու համար մենք ունենք շատ պարզ Terraform կոդ, որը պարզապես պետք է սկզբնավորել: Այստեղ, իհարկե, դուք պետք է նշեք բոլոր մատակարարներին, որոնք ինչ-որ կերպ մասնակցում են ձեր ծածկագրին, հակառակ դեպքում Terraform-ը կասի. «Ես չգիտեմ որոշակի մատակարար, քանի որ այն քեշում չէ»:
Հաջորդը Terraform պլանն է: Ինչպես ասացի, զարգացումը ցիկլային է։ Մենք փոփոխություններ ենք կատարում կոդի մեջ։ Եվ հետո պետք է պարզել, թե ինչ փոփոխություններ են նախատեսվում ենթակառուցվածքի համար։
Եվ երբ ենթակառուցվածքը շատ, շատ մեծ է, դուք կարող եք փոխել մեկ մոդուլ, շտկել որոշ թեստային միջավայր կամ որոշակի տարածաշրջան և կոտրել հարևաններից մեկը: Ուստի Terraform պլանը պետք է կազմվի ամբողջ ենթակառուցվածքի համար և ցույց տա, թե ինչ փոփոխություններ են նախատեսվում։
Դուք կարող եք դա անել խելացիորեն: Օրինակ, մենք գրել ենք Python սցենար, որը լուծում է կախվածությունները: Եվ կախված նրանից, թե ինչ է փոխվել՝ Terraform մոդուլ կամ պարզապես կոնկրետ բաղադրիչ, այն պլանավորում է բոլոր կախյալ թղթապանակների համար:
Terraform պլանները պետք է կազմվեն ըստ պահանջի: Համենայն դեպս մենք այդպես ենք անում:
Իհարկե, լավ է թեստեր անել յուրաքանչյուր փոփոխության, յուրաքանչյուր պարտավորության համար, բայց պլանները բավականին թանկ բան են: Եվ ձգողական խնդրանքի մեջ մենք ասում ենք. «Խնդրում եմ, տվեք ինձ ծրագրերը»: Ռոբոտը սկսում է. Եվ ուղարկում է մեկնաբանություն կամ կցում է բոլոր պլանները, որոնք ակնկալվում են ձեր փոփոխություններից:
Պլանը բավականին թանկ բան է։ Դա ժամանակ է պահանջում, քանի որ Terraform-ը գնում է Amazon և հարցնում. «Այս օրինակը դեռ գոյություն ունի՞: Արդյո՞ք այս ավտոսանդղակը ճիշտ նույն պարամետրերն ունի»: Եվ դա արագացնելու համար կարող եք օգտագործել այնպիսի պարամետր, ինչպիսին է refresh=false: Սա նշանակում է, որ Terraform-ը կներբեռնի վիճակը S3-ից: Եվ նա կհավատա, որ պետությունը ճշգրտորեն կհամապատասխանի այն, ինչ կա Amazon-ում:
Terraform-ի նման պլանը շատ ավելի արագ է ընթանում, բայց վիճակը պետք է համապատասխանի ձեր ենթակառուցվածքին, այսինքն՝ ինչ-որ տեղ, երբևէ պետք է սկսվի Terraform-ի թարմացումը։ Terraform refresh-ը հենց դա է անում. վիճակը համապատասխանում է իրական ենթակառուցվածքում եղածին:
Եվ մենք պետք է խոսենք անվտանգության մասին: Այստեղից մենք պետք է սկսեինք: Այնտեղ, որտեղ դուք աշխատում եք Terraform-ը և Terraform-ը աշխատում է ձեր ենթակառուցվածքի վրա, այնտեղ խոցելիություն կա: Այսինքն, դուք ըստ էության կատարում եք կոդը: Եվ եթե ձգման հարցումը պարունակում է ինչ-որ վնասակար կոդ, ապա այն կարող է իրականացվել չափազանց մեծ մուտք ունեցող ենթակառուցվածքի վրա: Ուստի զգույշ եղեք, թե որտեղ եք գործարկում Terraform պլանը:
Հաջորդ բանը, որի մասին կցանկանայի խոսել, օգտատերերի տվյալների փորձարկումն է:
Ի՞նչ է օգտագործողի տվյալները: Ամազոնում, երբ մենք ստեղծում ենք օրինակ, կարող ենք ուղարկել որոշակի նամակ՝ մետա տվյալների օրինակով։ Երբ օրինակը սկսվում է, սովորաբար ամպային init-ը միշտ առկա է այս օրինակներում: Cloud init-ը կարդում է այս նամակը և ասում. «Լավ, այսօր ես բեռի հավասարակշռողն եմ»: Եվ այս ուխտերի համաձայն նա կատարում է որոշ գործողություններ։
Բայց, ցավոք, երբ մենք դարձնում ենք Terraform պլանը և կիրառել Terraform-ը, օգտվողի տվյալները նման են թվերի նման զանգվածի: Այսինքն՝ նա ուղղակի ձեզ ուղարկում է հաշը։ Եվ այն ամենը, ինչ դուք կարող եք տեսնել պլանում, այն է, թե արդյոք փոփոխություններ կլինեն, թե արդյոք հեշը կմնա նույնը:
Եվ եթե դուք ուշադրություն չդարձնեք սրան, ապա կոտրված տեքստային ֆայլը կարող է հայտնվել Amazon-ում՝ իրական ենթակառուցվածքում:
Որպես այլընտրանք, կատարման ժամանակ կարող եք նշել ոչ թե ամբողջ ենթակառուցվածքը, այլ միայն կաղապարը։ Եվ ծածկագրում ասեք. «Խնդրում եմ ցուցադրել այս ձևանմուշը իմ էկրանին»: Եվ արդյունքում դուք կարող եք տպագիր ստանալ, թե ինչպիսի տեսք կունենան ձեր տվյալները Amazon-ում:
Մեկ այլ տարբերակ է օգտագործել մոդուլը օգտատերերի տվյալներ ստեղծելու համար: Դուք կկիրառեք այս մոդուլը: Դուք ստանում եք ֆայլը սկավառակի վրա: Համեմատեք այն տեղեկատուի հետ։ Եվ այսպես, եթե ինչ-որ տղա որոշի մի փոքր ուղղել օգտվողի տվյալները, ապա ձեր թեստերը կասեն.
Հաջորդ բանը, որի մասին ես կցանկանայի խոսել, դա Automate Terraform-ի կիրառումն է:
Իհարկե, բավականին սարսափելի է Terraform-ը կիրառել ավտոմատ ռեժիմով, քանի որ ով գիտի, թե ինչ փոփոխություններ են տեղի ունեցել այնտեղ և որքան կործանարար կարող են դրանք լինել կենդանի ենթակառուցվածքի համար:
Փորձարկման միջավայրի համար այս ամենը նորմալ է: Այսինքն, աշխատանքը, որը ստեղծում է թեստային միջավայր, այն է, ինչ անհրաժեշտ է բոլոր ծրագրավորողներին: Եվ այնպիսի արտահայտություն, ինչպիսին է «ամեն ինչ ինձ մոտ աշխատեց», զվարճալի մեմ չէ, այլ ապացույց այն բանի, որ մարդը շփոթվել է, բարձրացրել է ստեկը և մի քանի թեստեր է անցկացրել այս դարակի վրա: Եվ նա համոզվեց, որ այնտեղ ամեն ինչ լավ է և ասաց.
Արտադրության մեջ, ավազատուփում և այլ միջավայրերում, որոնք առավել կարևոր են բիզնեսում, դուք կարող եք մասամբ օգտագործել որոշ ռեսուրսներ բավականին ապահով կերպով, քանի որ դա չի հանգեցնում որևէ մեկի մահվան: Դրանք են՝ ավտոմասշտաբային խմբերը, անվտանգության խմբերը, դերերը, երթուղին53, և այնտեղ ցանկը կարող է բավականին մեծ լինել: Բայց հետևեք, թե ինչ է կատարվում, կարդացեք ավտոմատացված հավելվածների հաշվետվությունները:
Այնտեղ, որտեղ կիրառելը վտանգավոր կամ սարսափելի է, օրինակ, եթե դրանք որոշակի կայուն ռեսուրսներ են տվյալների բազայից, ապա ստացեք հաղորդումներ, որ ենթակառուցվածքի որոշ հատվածում չկիրառված փոփոխություններ կան: Իսկ ինժեները, հսկողության տակ, սկսում է գործեր դիմել կամ դա անում է իր կոնսոլից։
Amazon-ն ունի այնպիսի բան, ինչպիսին է Terminate պաշտպանությունը: Եվ դա կարող է որոշ դեպքերում պաշտպանել փոփոխություններից, որոնք ձեզ համար պարտադիր չեն: Այսինքն՝ Terraform-ը գնաց Ամազոն և ասաց. Իսկ Amazon-ն ասում է. «Կներեք, ոչ այսօր: Մենք ունենք Terminate պաշտպանություն»:
Իսկ թխվածքի կարագը կոդի օպտիմալացումն է: Երբ մենք աշխատում ենք Terraform կոդով, մենք պետք է շատ մեծ թվով պարամետրեր փոխանցենք մոդուլին։ Սրանք այն պարամետրերն են, որոնք անհրաժեշտ են ինչ-որ ռեսուրս ստեղծելու համար։ Իսկ կոդը վերածվում է պարամետրերի մեծ ցուցակների, որոնք պետք է փոխանցվեն մոդուլից մոդուլ, մոդուլից մոդուլ, հատկապես, եթե մոդուլները տեղադրված են:
Եվ դա շատ դժվար է կարդալ: Սա վերանայելը շատ դժվար է։ Եվ շատ հաճախ պարզվում է, որ որոշ պարամետրեր վերանայվում են, և դրանք հենց այնպես չեն, ինչ անհրաժեշտ է։ Եվ սա ավելի ուշ շտկելու համար ժամանակ և գումար է պահանջում:
Հետևաբար, ես առաջարկում եմ օգտագործել այնպիսի բան, ինչպիսին է բարդ պարամետրը, որը ներառում է արժեքների որոշակի ծառ: Այսինքն, ձեզ անհրաժեշտ է ինչ-որ թղթապանակ, որտեղ դուք ունեք բոլոր արժեքները, որոնք կցանկանայիք ունենալ ինչ-որ միջավայրում:
Եվ զանգահարելով այս մոդուլը, դուք կարող եք ստանալ ծառ, որը ստեղծվում է մեկ ընդհանուր մոդուլում, այսինքն՝ ընդհանուր մոդուլում, որը նույնն է աշխատում ամբողջ ենթակառուցվածքի համար։
Այս մոդուլում դուք կարող եք կատարել որոշ հաշվարկներ՝ օգտագործելով Terraform-ի նման վերջին հնարավորությունը՝ որպես տեղացիներ: Եվ հետո, մեկ ելքով, տվեք որոշ բարդ պարամետր, որը կարող է ներառել զանգվածի հեշեր և այլն:
Այստեղ ավարտվեցին իմ բոլոր լավագույն գտածոները: Եվ ես կցանկանայի մի պատմություն պատմել Կոլումբոսի մասին: Երբ նա փող էր փնտրում Հնդկաստանը բացահայտելու իր արշավախմբի համար (ինչպես նա կարծում էր այն ժամանակ), ոչ ոք չհավատաց նրան, և նրանք կարծում էին, որ դա անհնար է: Հետո նա ասաց. «Զգույշ եղիր, որ ձուն չընկնի»։ Բոլոր բանկիրները, շատ հարուստ և հավանաբար խելացի մարդիկ, փորձում էին ինչ-որ կերպ տեղավորել ձուն, և այն շարունակում էր ընկնել։ Հետո Կոլումբոսը վերցրեց ձուն և մի փոքր սեղմեց այն։ Կեղևը ճմրթվեց, իսկ ձուն անշարժ մնաց։ Նրանք ասացին. «Օ՜, դա շատ հեշտ է»: Եվ Կոլումբոսը պատասխանեց. «Այո, դա չափազանց պարզ է: Եվ երբ ես բացեմ Հնդկաստանը, բոլորը կօգտվեն այս առևտրային ճանապարհից»:
Եվ այն, ինչ ես ձեզ ասացի, հավանաբար, բավականին պարզ և չնչին բաներ են: Եվ երբ դուք սովորում եք դրանց մասին և սկսում եք դրանք օգտագործել, ամեն ինչ կարգին է: Այսպիսով, օգտվեք: Իսկ եթե դրանք ձեզ համար լրիվ նորմալ բաներ են, ապա գոնե գիտեք, թե ինչպես տեղադրել ձուն, որպեսզի այն չընկնի։
Եկեք ամփոփենք.
- Փորձեք խուսափել ձյան փաթիլներից: Եվ որքան քիչ ձյան փաթիլներ, այնքան ավելի քիչ ռեսուրսներ կպահանջվեն ձեր մեծ ենթակառուցվածքում փոփոխություններ կատարելու համար:
- Անընդհատ փոփոխություններ. Այսինքն, երբ կոդի մեջ որոշ փոփոխություններ են տեղի ունենում, դուք պետք է հնարավորինս արագ ձեր ենթակառուցվածքը համապատասխանեցնեք այս փոփոխություններին: Չպետք է լինի այնպիսի իրավիճակ, երբ ինչ-որ մեկը երկու-երեք ամիս հետո գա Elasticsearch-ին նայելու, Terraform պլան կազմի, և կան մի շարք փոփոխություններ, որոնք նա չէր սպասում: Իսկ ամեն ինչ կարգի բերելու համար շատ ժամանակ է պահանջվում։
- Փորձարկումներ և ավտոմատացում: Որքան ավելի շատ ձեր ծածկագիրը ծածկված է թեստերով և գործառույթներով, այնքան ավելի վստահ եք, որ ամեն ինչ ճիշտ եք անում: Իսկ ավտոմատ առաքումը բազմապատիկ կբարձրացնի ձեր վստահությունը:
- Փորձարկման և արտադրական միջավայրերի կոդը պետք է լինի գրեթե նույնը: Գործնականում, քանի որ արտադրությունը դեռ մի փոքր այլ է, և դեռ կլինեն որոշ նրբերանգներ, որոնք դուրս կգան թեստային միջավայրից: Բայց այնուամենայնիվ, գումարած կամ մինուս, դա կարելի է ապահովել։
- Եվ եթե դուք ունեք շատ Terraform կոդ, և շատ ժամանակ է պահանջվում այս ծածկագիրը թարմացնելու համար, ապա երբեք ուշ չէ վերամշակել և այն լավ վիճակում բերել:
- Անփոփոխ ենթակառուցվածք. AMI առաքում ըստ ժամանակացույցի:
- Երթուղու կառուցվածքը53, երբ դուք ունեք բազմաթիվ մուտքեր և ցանկանում եք, որ դրանք լինեն հետևողական կարգով:
- API-ի տոկոսադրույքի սահմանափակումների դեմ պայքար: Սա այն դեպքն է, երբ Amazon-ն ասում է. «Դա այն է, ես այլևս որևէ հարցում չեմ կարող ընդունել, խնդրում եմ սպասեք»: Իսկ գրասենյակի կեսը սպասում է, մինչև կգործարկի իր ենթակառուցվածքը:
- Spot դեպքեր. Amazon-ը էժան իրադարձություն չէ, և կետերը թույլ են տալիս բավականին շատ խնայել: Եվ այնտեղ կարելի է մի ամբողջ զեկույց պատմել դրա մասին։
- Անվտանգության և IAM դերերը:
- Փնտրելով կորցրած ռեսուրսներ, երբ դուք ունեք անհայտ ծագման դեպքեր Amazone-ում, նրանք փող են ուտում: Նույնիսկ եթե դեպքերն արժեն ամսական 100-150 դոլար, դա տարեկան ավելի քան 1 դոլար է: Նման ռեսուրսներ գտնելը շահութաբեր բիզնես է։
- Եվ վերապահված դեպքեր:
Ինձ համար այսքանն է: Terraform-ը շատ թույն է, դուք օգտագործում եք այն: Շնորհակալություն!
Հարցեր
Շնորհակալություն զեկույցի համար: Ձեր պետական ֆայլը գտնվում է S3-ում, բայց ինչպե՞ս եք լուծում այն խնդիրը, որ մի քանի հոգի կարող են վերցնել այս պետական ֆայլը և փորձել ընդլայնել:
Նախ, մենք չենք շտապում։ Երկրորդ, կան դրոշներ, որոնցում հայտնում ենք, որ աշխատում ենք ինչ-որ կոդի վրա։ Այսինքն, չնայած այն հանգամանքին, որ ենթակառուցվածքը շատ մեծ է, սա չի նշանակում, որ ինչ-որ մեկը անընդհատ ինչ-որ բան է օգտագործում։ Եվ երբ ակտիվ փուլ կար, սա խնդիր էր, մենք պահում էինք պետական ֆայլերը Git-ում: Սա կարևոր էր, այլապես ինչ-որ մեկը պետական ֆայլ կկազմի, և մենք պետք է դրանք ձեռքով հավաքեինք, որպեսզի ամեն ինչ շարունակվեր։ Հիմա նման խնդիր չկա։ Ընդհանուր առմամբ, Terraform-ը լուծեց այս խնդիրը։ Իսկ եթե ինչ-որ բան անընդհատ փոխվում է, ապա կարող եք օգտագործել կողպեքներ, որոնք կանխում են ձեր ասածը։
Դուք օգտագործում եք բաց կոդով կամ ձեռնարկություն:
Ոչ մի ձեռնարկություն, այսինքն՝ այն ամենը, ինչ կարող եք գնալ և անվճար ներբեռնել:
Իմ անունը Ստանիսլավ է։ Ես ուզում էի մի փոքրիկ հավելում անել. Դուք խոսեցիք Amazon-ի մի ֆունկցիայի մասին, որը թույլ է տալիս օրինակը դարձնել անհասանելի: Սա նաև հենց Terraform-ում է, Life Second բլոկում կարող եք նշել փոփոխությունների արգելք կամ ոչնչացման արգելք:
Ժամանակը սահմանափակ էր. Լավ փաստարկ.
Նաև երկու բան էի ուզում հարցնել. Նախ, դուք խոսեցիք թեստավորման մասին: Դուք օգտագործե՞լ եք որևէ փորձարկման գործիք: Ես լսել եմ Test Kitchen հավելվածի մասին: Երևի ավելին կա։ Եվ ես կցանկանայի նաև հարցնել տեղական արժեքների մասին: Ինչպե՞ս են դրանք սկզբունքորեն տարբերվում մուտքային փոփոխականներից: Իսկ ինչո՞ւ ես չեմ կարող ինչ-որ բան պարամետրիզացնել միայն Local Values-ի միջոցով: Ես փորձեցի պարզել այս թեման, բայց ինչ-որ կերպ ինքս չկարողացա պարզել այն:
Մենք կարող ենք ավելի մանրամասն խոսել այս սենյակից դուրս: Մեր փորձարկման գործիքներն ամբողջությամբ ինքնաշեն են: Այնտեղ փորձարկելու ոչինչ չկա: Ընդհանրապես, կան տարբերակներ, երբ ավտոմատացված թեստերը ինչ-որ տեղ ենթակառուցվածք են վերցնում, ստուգում են, որ այն լավ է, այնուհետև ոչնչացնում է ամեն ինչ՝ հայտնելով, որ ձեր ենթակառուցվածքը դեռ լավ վիճակում է: Մենք դա չունենք, քանի որ ամեն օր փորձնական փաթեթները գործարկվում են: Եվ բավական է։ Եվ եթե ինչ-որ բան սկսի կոտրվել, այն կսկսի կոտրվել՝ առանց մենք դա ստուգելու մեկ այլ տեղ:
Տեղական արժեքների վերաբերյալ խոսակցությունը շարունակենք սենյակից դուրս։
Բարեւ Ձեզ! Շնորհակալություն զեկույցի համար: Շատ տեղեկատվական: Դուք ասացիք, որ դուք ունեք շատ նույն տեսակի կոդ՝ ենթակառուցվածքը նկարագրելու համար: Դուք մտածե՞լ եք այս կոդը ստեղծելու մասին:
Հիանալի հարց, շնորհակալություն: Բանն այն է, որ երբ մենք օգտագործում ենք ենթակառուցվածքը որպես կոդ, մենք ենթադրում ենք, որ մենք նայում ենք կոդը և հասկանում, թե ինչ ենթակառուցվածք է թաքնված այդ կոդի հետևում: Եթե կոդ է ստեղծվում, ապա պետք է պատկերացնել, թե ինչ կոդ է ստեղծվելու, որպեսզի հասկանանք, թե ինչպիսի ենթակառուցվածք է լինելու այնտեղ։ Կամ մենք կոդ ենք ստեղծում, կատարում ենք այն, և ըստ էության նույն բանը տեղի է ունենում: Այսպիսով, մենք գնացինք մեր գրած ճանապարհով, ստացանք այն: Plus գեներատորները հայտնվեցին մի փոքր ուշ, երբ մենք սկսեցինք դրանք պատրաստել: Իսկ փոխվելու համար արդեն ուշ էր։
Ինչ-որ բան լսե՞լ եք jsonnet-ի մասին:
Ոչ:
Տեսեք, սա շատ թույն բան է։ Ես տեսնում եմ կոնկրետ դեպք, երբ դուք կարող եք կիրառել այն և ստեղծել տվյալների կառուցվածք:
Գեներատորները լավ են, երբ ունես, ինչպես սափրվելու մեքենայի մասին կատակում: Այսինքն՝ առաջին անգամ դեմքը տարբերվում է, բայց հետո բոլորը նույն դեմքն ունեն։ Գեներատորները շատ լավ են աշխատում։ Բայց, ցավոք, մեր դեմքերը մի փոքր այլ են։ Սա խնդիր է։
Պարզապես նայեք. Շնորհակալություն!
Իմ անունը Մաքսիմ է, ես Սբերբանկից եմ: Դուք մի փոքր խոսեցիք այն մասին, թե ինչպես եք փորձում Terraform-ը հասցնել ծրագրավորման լեզվին համարժեք: Ավելի հեշտ չէ՞ Ansible-ն օգտագործելը:
Սրանք շատ տարբեր բաներ են։ Դուք կարող եք ռեսուրսներ ստեղծել Ansible-ում, իսկ Puppet-ը կարող է ռեսուրսներ ստեղծել Amazon-ում: Բայց Terraform-ը ուղղակիորեն սրված է:
Դուք միայն Amazon ունե՞ք:
Այնպես չէ, որ մենք ունենք միայն Amazon-ը: Մենք գրեթե միայն Amazon-ն ունենք: Բայց հիմնական առանձնահատկությունն այն է, որ Terraform-ը հիշում է: Ansible-ում, եթե ասեք. «Տվեք ինձ 5 օրինակ», ապա այն կբարձրացնի, իսկ հետո կասեք. «Իսկ հիմա ինձ պետք է 3»: Եվ Terraform-ը կասի. «Լավ, ես կսպանեմ 2-ին», իսկ Անսիբլը կասի. «Լավ, ահա 3-ը քեզ համար»: Ընդամենը 8.
Բարեւ Ձեզ! Շնորհակալություն ձեր զեկույցի համար: Շատ հետաքրքիր էր լսել Terraform-ի մասին։ Ես կցանկանայի անմիջապես փոքրիկ մեկնաբանություն անել այն մասին, որ Terraform-ը դեռ չունի կայուն թողարկում, այնպես որ Terraform-ին վերաբերվեք մեծ զգուշությամբ:
Լավ գդալ ընթրիքի համար: Այսինքն, եթե ձեզ լուծում է պետք, ապա երբեմն հետաձգում եք այն, ինչ անկայուն է և այլն, բայց դա աշխատում է, և դա մեզ օգնեց։
Հարցը սա է. Դուք օգտագործում եք Remote backend, դուք օգտագործում եք S 3: Ինչու՞ չեք օգտագործում պաշտոնական backend-ը:
Պաշտոնական?
Terraform Cloud.
Ե՞րբ է նա հայտնվել։
Մոտ 4 ամիս առաջ.
Եթե այն հայտնվեր 4 տարի առաջ, ապա ես հավանաբար կպատասխանեի ձեր հարցին։
Արդեն կա ներկառուցված գործառույթ և կողպեքներ, և դուք կարող եք պահել պետական ֆայլը: Փորձեք այն: Բայց ես էլ չեմ փորձարկել։
Մենք ճանապարհորդում ենք մեծ գնացքով, որը շարժվում է մեծ արագությամբ։ Եվ դուք չեք կարող պարզապես վերցնել մի քանի մեքենա և դեն նետել դրանք:
Դուք խոսեցիք ձյան փաթիլների մասին, ինչո՞ւ չօգտագործեցիք ճյուղը: Ինչո՞ւ այդպես չստացվեց։
Մեր մոտեցումն այն է, որ ամբողջ ենթակառուցվածքը գտնվում է մեկ պահեստում: Terraform, Puppet, բոլոր սցենարները, որոնք ինչ-որ կերպ կապված են սրա հետ, դրանք բոլորը մեկ պահեստում են: Այս կերպ մենք կարող ենք ապահովել, որ աստիճանական փոփոխությունները փորձարկվեն մեկը մյուսի հետևից: Եթե դա լիներ մի փունջ ճյուղեր, ապա նման նախագիծը գրեթե անհնար կլիներ պահպանել։ Անցնում է վեց ամիս, և նրանք այնքան են տարբերվում, որ դա պարզապես պատիժ է։ Սա այն է, ինչից ես ուզում էի փախչել մինչև վերամշակումը:
Ուրեմն չի՞ աշխատում:
Սա ընդհանրապես չի աշխատում:
Ճյուղում ես կտրեցի թղթապանակի սլայդը: Այսինքն, եթե դուք դա անում եք յուրաքանչյուր թեստային կույտի համար, օրինակ՝ A թիմն ունի իր թղթապանակը, թիմը B՝ իր թղթապանակը, ապա սա նույնպես չի աշխատում: Մենք ստեղծեցինք միասնական թեստային միջավայրի կոդը, որը բավական ճկուն էր բոլորին համապատասխանելու համար: Այսինքն՝ մեկ ծածկագիր ենք մատուցել։
Բարեւ Ձեզ! Իմ անունը Յուրա է։ Շնորհակալություն զեկույցի համար: Հարց մոդուլների մասին. Դուք ասում եք, որ օգտագործում եք մոդուլներ: Ինչպե՞ս եք լուծում խնդիրը, եթե փոփոխություններ են կատարվել մեկ մոդուլում, որոնք անհամատեղելի են մեկ այլ անձի փոփոխության հետ: Դուք ինչ-որ կերպ տարբերակում եք մոդուլները կամ փորձում եք wunderwaffle բերել երկու պահանջների բավարարման համար:
Սա ձյան կույտի մեծ խնդիր է։ Սա այն է, ինչից մենք տառապում ենք, երբ ինչ-որ անվնաս փոփոխություն կարող է կոտրել ենթակառուցվածքի մի մասը: Եվ դա նկատելի կլինի միայն որոշ ժամանակ անց։
Այսինքն՝ դեռ չի՞ լուծվել։
Դուք պատրաստում եք ունիվերսալ մոդուլներ: Խուսափեք ձյան փաթիլներից: Եվ ամեն ինչ կստացվի: Զեկույցի երկրորդ կեսն այն մասին է, թե ինչպես խուսափել դրանից:
Բարեւ Ձեզ! Շնորհակալություն զեկույցի համար: Ես կցանկանայի պարզաբանել. Կուլիսների հետևում մի մեծ կույտ կար, որի համար ես եկել էի: Ինչպե՞ս են ինտեգրված տիկնիկային և դերերի բաշխումը:
Օգտագործողի տվյալներ.
Այսինքն՝ դուք ուղղակի թքել եք ֆայլը և ինչ-որ կերպ կատարում եք այն։
Օգտատիրոջ տվյալները նշում են, այսինքն, երբ մենք պատկերի կլոն ենք անում, Դեյմոնը բարձրանում է այնտեղ և, փորձելով պարզել, թե ով է նա, կարդում է նշումը, որ նա բեռի հավասարակշռող է:
Այսինքն՝ սա ինչ-որ առանձին գործընթաց է, որ տրվում է։
Մենք դա չենք հորինել։ Մենք օգտագործում ենք այն:
Բարեւ Ձեզ! Ես ուղղակի հարց ունեմ Օգտատիրոջ տվյալների վերաբերյալ: Դուք ասացիք, որ այնտեղ խնդիրներ կան, որ ինչ-որ մեկը կարող է սխալ տեղ ուղարկել։ Կա՞ արդյոք նույն Git-ում օգտատերերի տվյալները պահելու որևէ միջոց, որպեսզի միշտ պարզ լինի, թե ինչին են վերաբերում User-data-ն:
Մենք ստեղծում ենք Օգտատիրոջ տվյալները կաղապարից: Այսինքն՝ այնտեղ օգտագործվում են որոշակի թվով փոփոխականներ։ Եվ Terraform-ը առաջացնում է վերջնական արդյունքը: Հետևաբար, դուք չեք կարող պարզապես նայել ձևանմուշին և ասել, թե ինչ կլինի, քանի որ բոլոր խնդիրները կապված են այն բանի հետ, որ մշակողը կարծում է, որ նա փոխանցում է տող այս փոփոխականում, բայց այնտեղ օգտագործվում է զանգված: Իսկ նա՝ բամ, ես՝ այսինչ, այսինչ, այսինչ, հաջորդ տող, և ամեն ինչ կոտրվեց։ Եթե սա նոր ռեսուրս է, և մարդը վերցնում է այն և տեսնում, որ ինչ-որ բան չի աշխատում, ապա այն արագ լուծվում է: Եվ եթե այս autoscale խումբը թարմացվում է, ապա ինչ-որ պահի ավտոսանդղակի խմբում ատյանները սկսում են փոխարինվել: Եվ պայթյուն, ինչ-որ բան չի ստացվում: Ցավեցնում է.
Ստացվում է, որ միակ լուծումը փորձարկումն է.
Այո, տեսնում եք խնդիրը, այնտեղ ավելացնում եք թեստային քայլեր։ Այսինքն՝ ելքը կարող է նաև փորձարկվել։ Միգուցե դա այնքան էլ հարմար չէ, բայց դուք կարող եք նաև որոշ նշաններ դնել. ստուգեք, որ Օգտատիրոջ տվյալները ամրացված են այստեղ:
Իմ անունը Թիմուր է։ Շատ հաճելի է, որ կան զեկույցներ այն մասին, թե ինչպես ճիշտ կազմակերպել Terraform-ը:
Ես նույնիսկ չեմ սկսել:
Կարծում եմ, որ միգուցե հաջորդ համաժողովում լինի։ Ես մի պարզ հարց ունեմ. Ինչու՞ եք կոշտ կոդավորում արժեքը առանձին մոդուլում, քան tfvars օգտագործումը, այսինքն ինչու է արժեքներով մոդուլն ավելի լավ, քան tfvars:
Այսինքն՝ գրե՞մ այստեղ (սլայդ՝ Production/environment/settings.tf): domain = variable, domain vpcnetwork, variable vpcnetwork and stvars – կարո՞ղ եմ նույն բանը ստանալ:
Դա հենց այն է, ինչ մենք անում ենք: Օրինակ, մենք վերաբերում ենք պարամետրերի աղբյուրի մոդուլին:
Ըստ էության, սա այդպիսի տֆվարներ է։ Tfvars-ը շատ հարմար է թեստավորման միջավայրում։ Մեծ ատյանների համար տֆվարներ ունեմ, փոքրերի համար։ Եվ ես մեկ ֆայլ գցեցի թղթապանակի մեջ: Եվ ես ստացա այն, ինչ ուզում էի: Երբ մենք կրճատում ենք ենթակառուցվածքները, մենք ցանկանում ենք, որ ամեն ինչ հնարավոր լինի նայել և անմիջապես հասկանալ: Եվ այսպես, ստացվում է, որ պետք է այստեղ նայել, հետո նայել տֆվարներին։
Հնարավո՞ր է ամեն ինչ ունենալ մեկ տեղում:
Այո, tfvars-ն այն է, երբ ունես մեկ կոդ։ Եվ այն օգտագործվում է մի քանի տարբեր վայրերում՝ տարբեր նրբերանգներով: Հետո թֆվարներ կշպրտեիք ու ձեր նրբությունները կհասկանայիք։ Եվ մենք ենթակառուցվածքն ենք որպես ծածկագիր իր մաքուր ձևով: Նայեցի ու հասկացա.
Բարեւ Ձեզ! Դուք բախվե՞լ եք իրավիճակների, երբ ամպային մատակարարը խանգարում է ձեր ստեղծած Terraform-ին: Ենթադրենք, մենք խմբագրում ենք մետատվյալները: Կան ssh ստեղներ: Իսկ Google-ն անընդհատ այնտեղ է դնում իր մետատվյալներն ու բանալիները: Իսկ Terraform-ը միշտ գրում է, որ փոփոխություններ ունի։ Յուրաքանչյուր վազքից հետո, նույնիսկ եթե ոչինչ չի փոխվում, նա միշտ ասում է, որ հիմա թարմացնելու է այս դաշտը։
Բանալիներով, բայց այո, ենթակառուցվածքի մի մասը տուժում է այս բանից, այսինքն՝ Terraform-ը ոչինչ չի կարող փոխել։ Մենք էլ մեր ձեռքերով ոչինչ չենք կարող փոխել. Մենք դեռ կապրենք դրանով:
Այսինքն՝ դուք հանդիպել եք նման բանի, բայց ոչինչ չեք մտածել, ինչպե՞ս է նա դա անում և ինքն է անում։
Unfortunatelyավոք, այո:
Բարեւ Ձեզ! Ես Ստարկով Ստանիսլավն եմ։ Փոստ. ru Խումբ. Ինչպե՞ս եք լուծում...-ի վրա պիտակ ստեղծելու խնդիրը, ինչպե՞ս եք այն ներս փոխանցում: Ինչպես հասկացա, User - data-ի միջոցով հյուրընկալողի անունը նշելու համար միացնե՞լ Puppet-ը: Եվ հարցի երկրորդ մասը. Ինչպե՞ս եք լուծում այս հարցը SG-ում, այսինքն, երբ դուք ստեղծում եք SG, հարյուրավոր նույն տիպի օրինակներ, ո՞րն է դրանց ճիշտ անունը:
Այն դեպքերը, որոնք մեզ համար շատ կարևոր են, մենք դրանք գեղեցիկ անվանում ենք։ Նրանք, որոնք պետք չեն, կա նշում, որ սա ավտոսանդղակի խումբ է: Եվ տեսականորեն դուք կարող եք մեխել այն և ստանալ նորը:
Ինչ վերաբերում է պիտակի հետ կապված խնդրին, ապա նման խնդիր չկա, բայց կա այդպիսի խնդիր։ Եվ մենք օգտագործում ենք պիտակներ շատ, շատ, քանի որ ենթակառուցվածքը մեծ է և թանկ: Եվ մենք պետք է նայենք, թե ուր են գնում գումարները, ուստի պիտակները թույլ են տալիս մեզ բաժանել այն, ինչ ուր է գնացել: Եվ, համապատասխանաբար, այստեղ ծախսվում է մի բանի որոնումը, որը նշանակում է մեծ գումար։
Էլ ինչի՞ մասին էր հարցը։
Երբ Ս.Գ.-ն հարյուրավոր ատյաններ է ստեղծում, դրանք պետք է ինչ-որ կերպ տարբերել?
Ոչ, մի՛ արեք: Յուրաքանչյուր դեպքի դեպքում կա մի գործակալ, որը հայտնում է, որ ես խնդիր ունեմ: Եթե գործակալը հաղորդում է, ապա գործակալը գիտի նրա մասին և, առնվազն, նրա IP հասցեն գոյություն ունի: Դուք արդեն կարող եք փախչել: Երկրորդ, մենք օգտագործում ենք Consul for Discovery, որտեղ Kubernetes-ը չկա: Իսկ Consul-ը ցույց է տալիս նաև ատյանի IP հասցեն։
Այսինքն՝ կենտրոնանում եք կոնկրետ IP-ի վրա, այլ ոչ թե հոսթի անվան վրա։
Անհնար է նավարկել հյուրընկալողի անունով, այսինքն՝ դրանք շատ են: Կան օրինակների նույնացուցիչներ՝ AE և այլն: Դուք կարող եք գտնել այն ինչ-որ տեղ, կարող եք այն նետել որոնման մեջ:
Բարեւ Ձեզ! Ես հասկացա, որ Terraform-ը լավ բան է՝ հարմարեցված ամպերի համար:
Ոչ միայն.
Սա հենց այն հարցն է, որը հետաքրքրում է ինձ։ Եթե որոշեք ձեր բոլոր ատյաններով զանգվածաբար տեղափոխվել, ասենք, Bare Metal։ Խնդիրներ կառաջանա՞ն։ Թե՞ դուք դեռ պետք է օգտագործեք այլ ապրանքներ, օրինակ, նույն Ansible-ը, որը նշված էր այստեղ:
Ansible-ը մի փոքր այլ բանի մասին է: Այսինքն, Ansible-ն արդեն աշխատում է, երբ օրինակը սկսվել է: Իսկ Terraform-ն աշխատում է նախքան օրինակի մեկնարկը: Անցում Bare Metal - ոչ:
Հիմա ոչ, բայց բիզնեսը կգա ու կասի՝ արի։
Անցում մեկ այլ ամպի – այո, բայց այստեղ մի փոքր այլ հնարք կա: Դուք պետք է գրեք Terraform կոդը այնպես, որ կարողանաք ավելի քիչ ջանքեր գործադրել այլ ամպի վրա:
Ի սկզբանե խնդիր դրվեց, որ մեր ամբողջ ենթակառուցվածքը ագնոստիկ լինի, այսինքն՝ ցանկացած ամպ պետք է հարմար լինի, բայց ինչ-որ պահի բիզնեսը հրաժարվեց և ասաց. «Լավ, հաջորդ N տարում մենք ոչ մի տեղ չենք գնա, կարող ենք օգտվել ծառայություններից։ Amazon-ից»
Terraform-ը թույլ է տալիս ստեղծել Front-End աշխատատեղեր, կարգավորել PagerDuty-ն, տվյալների փաստաթուղթը և այլն: Այն ունի շատ պոչեր: Նա կարող է գործնականում վերահսկել ամբողջ աշխարհը:
Շնորհակալություն զեկույցի համար: Ես նաև օգտագործում եմ Terraform-ը արդեն 4 տարի: Terraform-ին, ենթակառուցվածքին, դեկլարատիվ նկարագրությանը սահուն անցման փուլում մենք բախվեցինք մի իրավիճակի, երբ ինչ-որ մեկը ձեռքով ինչ-որ բան էր անում, իսկ դուք փորձում էիք պլան կազմել։ Եվ ես այնտեղ ինչ-որ սխալ ստացա: Ինչպե՞ս եք վերաբերվում նման խնդիրներին: Ինչպե՞ս եք գտնում կորցրած ռեսուրսները, որոնք նշված են:
Հիմնականում մեր ձեռքերով ու աչքերով, եթե հաշվետվության մեջ ինչ-որ տարօրինակ բան ենք տեսնում, ապա վերլուծում ենք այնտեղ կատարվողը, կամ ուղղակի սպանում ենք։ Ընդհանրապես, ձգման հարցումները սովորական բան են:
Եթե սխալ կա, դուք հետ եք վերադառնում: Փորձե՞լ եք դա անել:
Ոչ, սա մարդու որոշումն է այն պահին, երբ նա խնդիր է տեսնում։
Source: www.habr.com