Daugelis žmonių žino ir naudoja „Terraform“ savo kasdieniame darbe, tačiau geriausios jos praktikos dar nėra suformuotos. Kiekviena komanda turi sugalvoti savo metodus ir metodus.
Beveik neabejotinai jūsų infrastruktūra prasideda paprastai: keli ištekliai + keli kūrėjai. Laikui bėgant jis auga visomis kryptimis. Ar randate būdų, kaip grupuoti išteklius į Terraform modulius, suskirstyti kodą į aplankus ir kas dar gali suklysti? (Įžymūs Paskutiniai žodžiai)
Laikas bėga ir jaučiate, kad jūsų infrastruktūra yra jūsų naujas augintinis, bet kodėl? Jaudinatės dėl nepaaiškinamų infrastruktūros pokyčių, bijote prisiliesti prie infrastruktūros ir kodo – dėl to vėluojate naujo funkcionalumo ar pabloginate kokybę...
Trejus metus valdęs „Terraform“ bendruomenės modulių, skirtų AWS „Github“, kolekciją ir ilgalaikę „Terraform“ priežiūrą gamyboje, Antonas Babenko yra pasirengęs pasidalinti savo patirtimi: kaip parašyti TF modulius, kad ateityje tai nepakenktų.
Pokalbio pabaigoje dalyviai bus geriau susipažinę su Terraform išteklių valdymo principais, geriausia praktika, susijusia su Terraform moduliais, ir kai kuriais nuolatinio integravimo principais, susijusiais su infrastruktūros valdymu.
Dėmesio: Atkreipiu dėmesį, kad ši ataskaita yra 2018 m. lapkričio mėn. – jau praėjo 2 metai. Ataskaitoje aptarta Terraform 0.11 versija nebepalaikoma. Per pastaruosius 2 metus buvo išleisti 2 nauji leidimai, kuriuose yra daug naujovių, patobulinimų ir pakeitimų. Atkreipkite dėmesį į tai ir patikrinkite dokumentus.
Nuorodos:
- +
- — automatinio formatavimo kodas ir dokumentacija
- - Terraform modulių generatorius (WIP)
- - Terraform kodo generatorius iš vaizdinių diagramų (WIP)
- www.terraform-best-practices.com
- (Nauji įrašai yra mano asmeninėje svetainėje www.antonbabenko.com/)
- @antonbabenko – „Twitter“ ir daugybė įvairių kelnių
Mano vardas Antonas Babenko. Kai kurie iš jūsų tikriausiai naudojo kodą, kurį parašiau. Dabar apie tai kalbėsiu drąsiau nei bet kada anksčiau, nes turiu prieigą prie statistikos.
Dirbu „Terraform“ ir nuo 2015 m. esu aktyvus daugelio atvirojo kodo projektų, susijusių su „Terraform“ ir „Amazon“, dalyvis ir bendradarbis.
Nuo tada parašiau pakankamai kodo, kad galėčiau jį įdomiai pateikti. Ir aš pabandysiu jums apie tai papasakoti dabar.
Pakalbėsiu apie darbo su Terraform subtilybes ir specifiką. Tačiau tai tikrai nėra „HighLoad“ tema. Ir dabar jūs suprasite, kodėl.
Laikui bėgant pradėjau rašyti Terraform modulius. Vartotojai rašė klausimus, aš juos perrašiau. Tada parašiau įvairias programas, kad suformatuotų kodą, naudodamas išankstinį įsipareigojimą ir pan.
Buvo daug įdomių projektų. Man patinka kodų generavimas, nes man patinka, kad kompiuteris atlieka vis daugiau darbų už mane ir programuotoją, todėl šiuo metu dirbu su Terraform kodų generatoriumi iš vaizdinių diagramų. Galbūt kai kurie iš jūsų juos matėte. Tai gražios dėžutės su rodyklėmis. Ir manau, kad puiku, jei galite spustelėti mygtuką „Eksportuoti“ ir gauti visa tai kaip kodą.
Aš esu iš Ukrainos. Daug metų gyvenu Norvegijoje.
Taip pat informacija šiai ataskaitai buvo surinkta iš žmonių, kurie žino mano vardą ir suranda mane socialiniuose tinkluose. Beveik visada turiu tą patį slapyvardį.
Kaip jau minėjau, esu pagrindinis „Terraform AWS“ modulių, kuris yra viena didžiausių „GitHub“ saugyklų, prižiūrėtojas, kuriame talpiname modulius dažniausiai atliekamoms užduotims: VPC, Autoscaling, RDS.
Ir tai, ką girdėjote dabar, yra paprasčiausia. Jei abejojate, ar suprantate, kas yra Terraform, geriau praleiskite laiką kitur. Čia bus daug techninių terminų. Ir aš nedvejodamas paskelbiau, kad ataskaitos lygis yra aukščiausias. Tai reiškia, kad galiu kalbėti vartodamas visus įmanomus terminus be didelių paaiškinimų.
„Terraform“ pasirodė 2014 m. kaip įrankis, leidžiantis rašyti, planuoti ir valdyti infrastruktūrą kaip kodą. Pagrindinė sąvoka čia yra „infrastruktūra kaip kodas“.
Visi dokumentai, kaip sakiau, yra surašyti . Tikiuosi, kad dauguma žmonių žino apie šią svetainę ir perskaitė dokumentus. Jei taip, vadinasi, esate tinkamoje vietoje.
Taip atrodo įprastas Terraform konfigūracijos failas, kuriame pirmiausia apibrėžiame kai kuriuos kintamuosius.
Šiuo atveju apibrėžiame „aws_region“.
Tada aprašome, kokius išteklius norime sukurti.
Vykdome kai kurias komandas, ypač „terraform init“, kad įkeltume priklausomybes ir teikėjus.
Ir paleidžiame komandą „terraform apply“, kad patikrintume, ar nurodyta konfigūracija atitinka mūsų sukurtus išteklius. Kadangi anksčiau nieko nekūrėme, „Terraform“ ragina sukurti šiuos išteklius.
Mes tai patvirtiname. Taip sukuriame kibirą, vadinamą jūrų sraigėmis.
Taip pat yra keletas panašių komunalinių paslaugų. Daugelis iš jūsų, kurie naudojasi „Amazon“, žino „AWS CloudFormation“, „Google Cloud Deployment Manager“ arba „Azure Resource Manager“. Kiekvienas iš jų turi tam tikrą diegimą, skirtą valdyti išteklius kiekviename iš šių viešųjų debesų paslaugų teikėjų. „Terraform“ ypač naudinga, nes leidžia valdyti daugiau nei 100 teikėjų. (Daugiau informacijos )
Tikslai, kurių Terraform siekė nuo pat pradžių:
- „Terraform“ suteikia bendrą išteklių vaizdą.
- Leidžia palaikyti visas šiuolaikines platformas.
- O Terraform nuo pat pradžių buvo sukurta kaip priemonė, leidžianti saugiai ir nuspėjamai keisti infrastruktūrą.
2014 metais žodis „nuspėjamas“ šiame kontekste skambėjo labai neįprastai.
Terraform yra universalus įrankis. Jei turite API, galite valdyti absoliučiai viską:
- Galite naudoti daugiau nei 120 teikėjų, kad galėtumėte valdyti viską, ko norite.
- Pavyzdžiui, galite naudoti „Terraform“, kad apibūdintumėte prieigą prie „GitHub“ saugyklų.
- Jūs netgi galite sukurti ir uždaryti klaidas „Jira“.
- Galite tvarkyti naujų relikvijų metriką.
- Jei tikrai norite, netgi galite kurti failus „dropbox“.
Visa tai pasiekiama naudojant „Terraform“ tiekėjus, turinčius atvirą API, kurią galima aprašyti „Go“.
Tarkime, pradėjome naudoti „Terraform“, perskaitėme svetainės dokumentaciją, pažiūrėjome vaizdo įrašą ir pradėjome rašyti main.tf, kaip parodžiau ankstesnėse skaidrėse.
Ir viskas puiku, turite failą, kuris sukuria VPC.
Jei norite sukurti VPC, nurodykite maždaug šias 12 eilučių. Aprašykite, kuriame regione norite sukurti, kurį IP adresų cidr_block naudoti. Tai viskas.
Natūralu, kad projektas palaipsniui augs.
Ten pridėsite daug naujų dalykų: išteklių, duomenų šaltinių, integruositės su naujais teikėjais, staiga norėsite naudoti „Terraform“ naudotojams tvarkyti „GitHub“ paskyroje ir pan. Galbūt norėsite naudoti kitus DNS teikėjai kerta viską. „Terraform“ tai palengvina.
Pažvelkime į šį pavyzdį.
Palaipsniui pridedate internet_gateway, nes norite, kad jūsų VPC ištekliai turėtų prieigą prie interneto. Tai gera idėja.
Rezultatas yra pagrindinis.tf:
Tai yra viršutinė main.tf dalis.
Tai yra apatinė main.tf dalis.
Tada pridedate potinklį. Tuo metu, kai norėsite pridėti NAT šliuzus, maršrutus, maršruto parinkimo lenteles ir daugybę kitų potinklių, turėsite ne 38 eilutes, o maždaug 200–300 eilučių.
Tai yra, jūsų main.tf failas palaipsniui auga. Ir gana dažnai žmonės viską deda į vieną failą. 10-20 Kb pasirodo main.tf. Įsivaizduokite, kad 10–20 Kb yra tekstinis turinys. Ir viskas su viskuo susiję. Su tuo pamažu tampa sunku dirbti. 10-20 Kb yra geras vartotojo atvejis, kartais daugiau. Ir žmonės ne visada mano, kad tai yra blogai.
Kaip ir įprastame programavime, t.y. ne infrastruktūrą kaip kodą, mes įpratę naudoti daugybę skirtingų klasių, paketų, modulių, grupuočių. „Terraform“ leidžia daryti beveik tą patį.
- Kodas auga.
- Priklausomybės tarp išteklių taip pat auga.
Ir mes turime didelį, didelį poreikį. Suprantame, kad nebegalime taip gyventi. Mūsų kodas tampa didžiulis. 10-20 Kb, žinoma, nėra labai didelis, bet mes kalbame tik apie tinklo krūvą, t.y. jūs tik pridėjote tinklo resursus. Mes nekalbame apie „Application Load Balancer“, diegimo ES klasterį, „Kubernetes“ ir tt, kur galima lengvai įtraukti 100 Kb. Jei visa tai užsirašysite, labai greitai sužinosite, kad Terraform teikia Terraform modulius.
„Terraform“ moduliai yra atskira „Terraform“ konfigūracija, valdoma kaip grupė. Tai viskas, ką reikia žinoti apie Terraform modulius. Jie visai nėra protingi, neleidžia užmegzti sudėtingų ryšių, priklausomai nuo kažko. Visa tai krenta ant kūrėjų pečių. Tai yra, tai tik tam tikra „Terraform“ konfigūracija, kurią jau parašėte. Ir jūs galite tai tiesiog vadinti grupe.
Taigi mes bandome suprasti, kaip optimizuosime savo 10-20-30 Kb kodą. Pamažu suprantame, kad reikia naudoti kai kuriuos modulius.
Pirmojo tipo moduliai, su kuriais susiduriate, yra išteklių moduliai. Jie nesupranta, kas yra jūsų infrastruktūra, kas yra jūsų verslas, kur ir kokios sąlygos. Tai yra būtent tie moduliai, kuriuos administruoju aš kartu su atvirojo kodo bendruomene ir kuriuos pateikiame kaip pagrindinius jūsų infrastruktūros elementus.
Išteklių modulio pavyzdys.
Kai iškviečiame išteklių modulį, nurodome, iš kurio kelio turėtume įkelti jo turinį.
Mes nurodome, kurią versiją norime atsisiųsti.
Ten perduodame aibę argumentų. Tai viskas. Tai viskas, ką turime žinoti, kai naudojame šį modulį.
Daugelis žmonių mano, kad jei naudos naujausią versiją, viskas bus stabili. Bet ne. Infrastruktūra turi būti sutvarkyta; turime aiškiai atsakyti, kuriai versijai buvo įdiegtas tas ar kitas komponentas.
Štai kodas, esantis šio modulio viduje. Apsaugos grupės modulis. Čia slinktis pereina į 640-ąją eilutę. Sukurti „Amazon“ saugos išteklius visomis įmanomomis konfigūracijomis yra labai nebanali užduotis. Neužtenka vien sukurti saugos grupę ir jai nurodyti, kokias taisykles jai perduoti. Būtų labai paprasta. „Amazon“ viduje yra milijonas skirtingų apribojimų. Pavyzdžiui, jei naudojate VPC galutinis taškas, prefiksų sąrašas, įvairios API ir bando visa tai derinti su viskuo kitu, tada Terraform neleidžia to daryti. Ir „Amazon“ API to taip pat neleidžia. Todėl turime paslėpti visą šią baisią logiką modulyje ir suteikti vartotojo kodą, kuris atrodo būtent taip.
Vartotojui nereikia žinoti, kaip jis pagamintas viduje.
Antrojo tipo moduliai, susidedantys iš išteklių modulių, jau sprendžia problemas, kurios labiau pritaikomos jūsų verslui. Dažnai tai yra vieta, kuri yra „Terraform“ plėtinys ir nustato tam tikras griežtas žymų, įmonės standartų vertes. Ten taip pat galite pridėti funkcijų, kurių Terraform šiuo metu neleidžia naudoti. Tai yra dabar. Dabar versija 0.11, kuri netrukus taps praeitimi. Tačiau vis tiek pirminiai procesoriai, jsonnet, cookiecutter ir daugybė kitų dalykų yra pagalbinis mechanizmas, kuris turi būti naudojamas visaverčiam darbui.
Toliau pateiksiu kelis to pavyzdžius.
Infrastruktūros modulis vadinamas lygiai taip pat.
Nurodytas šaltinis, iš kurio galima atsisiųsti turinį.
Į šį modulį perduodama ir perkeliama daugybė verčių.
Toliau šiame modulyje iškviečiama krūva išteklių modulių, kad būtų galima sukurti VPC arba taikomosios programos apkrovos balansavimo priemonę arba sukurti saugos grupę arba Elastic Container Service klasterį.
Yra dviejų tipų moduliai. Tai svarbu suprasti, nes didžioji dalis informacijos, kurią sugrupavau šioje ataskaitoje, nėra parašyta dokumentacijoje.
Ir Terraform dokumentacija šiuo metu yra gana problematiška, nes ji tiesiog sako, kad yra šios funkcijos, galite jomis naudotis. Tačiau ji nesako, kaip naudotis šiomis funkcijomis, kodėl jas geriau naudoti. Todėl labai daug žmonių rašo tai, su kuo negali gyventi.
Toliau pažiūrėkime, kaip parašyti šiuos modulius. Tada pažiūrėsime, kaip jiems paskambinti ir kaip dirbti su kodu.
„Terraform“ registras –
0 patarimas yra nerašyti išteklių modulių. Dauguma šių modulių jau parašyti jums. Kaip sakiau, jie yra atvirojo kodo, juose nėra jokios jūsų verslo logikos, jie neturi užkoduotų IP adresų, slaptažodžių ir tt reikšmių. Modulis yra labai lankstus. Ir greičiausiai tai jau buvo parašyta. Yra daug „Amazon“ išteklių modulių. Apie 650. Ir dauguma jų geros kokybės.
Šiame pavyzdyje kažkas atėjo pas jus ir pasakė: „Noriu turėti galimybę valdyti duomenų bazę. Sukurkite modulį, kad galėčiau sukurti duomenų bazę. Asmuo nežino nei „Amazon“, nei „Terraform“ diegimo detalių. Jis tiesiog sako: „Noriu valdyti MSSQL“. Tai reiškia, kad jis iškvies mūsų modulį, perduos variklio tipą ir nurodys laiko juostą.
Ir žmogus neturėtų žinoti, kad šiame modulyje sukursime du skirtingus išteklius: vieną MSSQL, antrą – viskam kitam, tik todėl, kad Terraform 0.11 negalite nurodyti laiko juostos reikšmių kaip neprivalomų.
O išėjęs iš šio modulio žmogus galės tiesiog gauti adresą. Jis nežinos, iš kokios duomenų bazės, iš kokio resurso mes visa tai kuriame viduje. Tai labai svarbus slėpimo elementas. Ir tai taikoma ne tik tiems moduliams, kurie yra vieši atvirojo kodo, bet ir tiems moduliams, kuriuos rašysite savo projektuose ir komandose.
Tai antrasis argumentas, kuris yra gana svarbus, jei kurį laiką naudojote Terraform. Turite saugyklą, kurioje įdėjote visus savo įmonės Terraform modulius. Ir visai normalu, kad laikui bėgant šis projektas išaugs iki vieno ar dviejų megabaitų. Tai yra gerai.
Tačiau problema yra ta, kaip Terraform vadina šiuos modulius. Pavyzdžiui, jei iškviečiate modulį, kad sukurtumėte kiekvieną atskirą vartotoją, Terraform pirmiausia įkels visą saugyklą ir pereis į aplanką, kuriame yra tas konkretus modulis. Tokiu būdu kiekvieną kartą atsisiųsite po vieną megabaitą. Jei valdote 100 ar 200 vartotojų, atsisiųsite 100 arba 200 megabaitų ir eisite į tą aplanką. Natūralu, kad kiekvieną kartą paspaudus „Terraform init“ nenorite atsisiųsti daugybės dalykų.
Yra du šios problemos sprendimai. Pirmasis yra santykinių kelių naudojimas. Tokiu būdu kode nurodote, kad aplankas yra vietinis (./). Ir prieš ką nors paleisdami, atlikite šios saugyklos Git kloną vietoje. Tokiu būdu tai padarysite vieną kartą.
Žinoma, yra daug minusų. Pavyzdžiui, negalite naudoti versijų kūrimo. Ir su tuo kartais sunku gyventi.
Antras sprendimas. Jei turite daug submodulių ir jau turite tam tikrą konvejerį, tada yra MBT projektas, leidžiantis surinkti daugybę skirtingų paketų iš monorepozitorijos ir įkelti juos į S3. Tai labai geras būdas. Taigi iam-user-1.0.0.zip failas svers tik 1 Kb, nes kodas šiam ištekliui sukurti yra labai mažas. Ir tai veiks daug greičiau.
Pakalbėkime apie tai, ko negalima naudoti moduliuose.
Kodėl tai yra blogybė moduliuose? Blogiausia yra manyti, kad vartotojas. Tarkime, kad vartotojas yra teikėjo autentifikavimo parinktis, kurią gali naudoti skirtingi žmonės. Pavyzdžiui, mes visi įsisavinsime vaidmenį. Tai reiškia, kad Terraform imsis šio vaidmens. Ir tada su šiuo vaidmeniu jis atliks kitus veiksmus.
O blogybė ta, kad jei Vasya mėgsta prisijungti prie „Amazon“ vienu būdu, pavyzdžiui, naudojant numatytąjį aplinkos kintamąjį, o Petya mėgsta naudoti savo bendrinamą raktą, kurį jis turi slaptoje vietoje, tada jūs negalite nurodyti abiejų Terraforma. O kad jie nepatirtų kančios, modulyje šio bloko nurodyti nereikia. Tai turi būti nurodyta aukštesniu lygiu. Tai yra, mes turime išteklių modulį, infrastruktūros modulį ir kompoziciją viršuje. Ir tai turėtų būti nurodyta kažkur aukščiau.
Antroji blogybė yra aprūpinimas. Čia tas blogis nėra toks menkas, nes jei parašai kodą ir jis tau tinka, tai gali pagalvoti, kad jei veikia, tai kam jį keisti.
Blogis yra tai, kad jūs ne visada kontroliuojate, kada bus paleistas šis paslaugų teikėjas. Antra, jūs nekontroliuojate, ką reiškia aws ec2, t. y. ar dabar kalbame apie Linux ar Windows. Taigi jūs negalite parašyti to, kas vienodai veiktų skirtingose operacinėse sistemose arba skirtinguose naudotojų atveju.
Dažniausias pavyzdys, kuris taip pat nurodomas oficialioje dokumentacijoje, yra tas, kad jei rašote aws_instance ir nurodote krūvą argumentų, tai nieko blogo, jei ten nurodysite numatytoją „local-exec“ ir paleisite savo ansible- žaidimų knyga.
Tiesą sakant, taip, tame nėra nieko blogo. Bet pažodžiui netrukus suprasite, kad šio vietinio vykdymo dalyko nėra, pavyzdžiui, launch_configuration.
Ir kai naudojate launch_configuration ir norite sukurti automatinio mastelio keitimo grupę iš vieno egzemplioriaus, tada launch_configuration nėra sąvokos "teikėjas". Yra sąvoka „vartotojo duomenys“.
Todėl universalesnis sprendimas – naudoti vartotojo duomenis. Ir jis bus paleistas pačiame egzemplioriuje, kai jis įjungtas, arba tuose pačiuose vartotojo duomenyse, kai automatinio mastelio keitimo grupė naudos šią launch_configuration.
Jei vis tiek norite paleisti aprūpinimo priemonę, nes tai yra klijavimo komponentas, kai sukuriamas vienas resursas, tuo metu reikia paleisti savo aprūpinimo priemonę, savo komandą. Tokių situacijų yra labai daug.
Ir tam tinkamiausias šaltinis vadinamas null_resource. Null_resource yra netikras išteklius, kuris niekada nėra sukurtas. Tai nieko neliečia, jokio API, jokio automatinio mastelio keitimo. Tačiau tai leidžia valdyti, kada paleisti komandą. Tokiu atveju komanda vykdoma kuriant.
Nuoroda
Yra keletas ženklų. Labai detaliai nenagrinėsiu visų ženklų. Apie tai yra straipsnis. Bet jei dirbote su Terraform ar naudojote kitų žmonių modulius, tuomet dažnai pastebėjote, kad daugelis modulių, kaip ir dauguma atvirojo kodo kodo, yra parašyti žmonių savo poreikiams. Vyras parašė ir išsprendė savo problemą. Įdėjau jį į „GitHub“, leisk jam gyventi. Jis gyvuos, bet jei ten nebus dokumentacijos ir pavyzdžių, tai niekas nesinaudos. Ir jei nėra funkcionalumo, leidžiančio išspręsti šiek tiek daugiau nei jo konkreti užduotis, tada niekas ir nesinaudos. Yra tiek daug būdų, kaip prarasti vartotojus.
Jei norite ką nors parašyti, kad žmonės tuo naudotųsi, rekomenduoju vadovautis šiais ženklais.
Jie yra:
- Dokumentacija ir pavyzdžiai.
- Pilnas funkcionalumas.
- Pagrįsti nutylėjimai.
- Švarus kodas.
- Testai.
Testai yra kitokia situacija, nes juos gana sunku rašyti. Labiau tikiu dokumentacija ir pavyzdžiais.
Taigi, mes pažiūrėjome, kaip rašyti modulius. Yra du argumentai. Pirmas, kuris yra pats svarbiausias dalykas – nerašykite, jei galite, nes krūva žmonių jau atliko šias užduotis anksčiau nei jūs. Ir, antra, jei vis tiek nuspręsite, stenkitės nenaudoti teikėjų moduliuose ir paslaugų teikėjuose.
Tai yra pilkoji dokumentacijos dalis. Galbūt dabar galvojate: „Kažkas neaišku. Nesu įsitikinęs“. Bet pamatysime po šešių mėnesių.
Dabar pakalbėkime apie tai, kaip vadinti šiuos modulius.
Suprantame, kad mūsų kodas laikui bėgant auga. Nebeturime vieno failo, jau turime 20 failų. Jie visi yra viename aplanke. O gal penkiuose aplankuose. Galbūt pradedame juos kažkaip skaidyti pagal regionus, pagal kai kuriuos komponentus. Tada suprantame, kad dabar turime tam tikrus sinchronizacijos ir orkestravimo pradmenis. Tai reiškia, kad turime suprasti, ką turėtume daryti, jei pakeistume tinklo išteklius, ką turėtume daryti su likusiais ištekliais, kaip sukelti šias priklausomybes ir pan.
Yra du kraštutinumai. Pirmasis kraštutinumas yra viskas viename. Turime vieną pagrindinį failą. Šiuo metu tai buvo oficiali geriausia praktika Terraform svetainėje.
Bet dabar jis parašytas kaip pasenęs ir pašalintas. Laikui bėgant „Terraform“ bendruomenė suprato, kad tai toli gražu nėra geriausia praktika, nes žmonės projektą pradėjo naudoti įvairiais būdais. Ir yra problemų. Pavyzdžiui, kai išvardijame visas priklausomybes vienoje vietoje. Būna situacijų, kai paspaudžiame „Terraform planas“ ir kol Terraform neatnaujins visų išteklių būsenų, gali praeiti nemažai laiko.
Daug laiko yra, pavyzdžiui, 5 minutės. Kai kuriems tai yra daug laiko. Esu matęs atvejų, kai užtrukdavo 15 min. AWS API praleido 15 minučių, bandydama išsiaiškinti, kas vyksta su kiekvieno šaltinio būsena. Tai labai didelis plotas.
Natūralu, kad su tuo susijusi problema atsiras, kai norėsite ką nors pakeisti vienoje vietoje, tada palauksite 15 minučių ir jums bus pateikta kai kurių pakeitimų drobė. Spjovėte, parašėte „Taip“ ir kažkas nutiko. Tai labai tikras pavyzdys. „Terraform“ nesistengia apsaugoti jūsų nuo problemų. Tai yra, rašykite ką norite. Bus problemų – jūsų problemos. Nors Terraform 0.11 niekaip nesistengia jums padėti. 0.12 yra tam tikrų įdomių vietų, kurios leidžia pasakyti: „Vasya, tu tikrai to nori, ar gali susiprotėti?
Antras būdas – sumažinti šią sritį, tai yra, skambučiai iš vienos vietos gali būti mažiau sujungti iš kitos vietos.
Vienintelė problema ta, kad reikia parašyti daugiau kodo, t.y. reikia aprašyti kintamuosius daugelyje failų ir tai atnaujinti. Kai kuriems žmonėms tai nepatinka. Man tai normalu. Ir kai kurie žmonės galvoja: „Kam tai rašyti skirtingose vietose, aš viską sudėsiu į vieną vietą“. Tai įmanoma, bet tai yra antrasis kraštutinumas.
Kas visa tai gyvena vienoje vietoje? Vienas, du, trys žmonės, tai yra, kažkas naudojasi.
O kas iškviečia vieną konkretų komponentą, vieną bloką ar vieną infrastruktūros modulį? Nuo penkių iki septynių žmonių. Tai šaunu.
Dažniausias atsakymas yra kažkur viduryje. Jei projektas didelis, tuomet dažnai susidursite su situacija, kai netinka joks sprendimas ir ne viskas pavyksta, todėl baigsite mišinį. Čia nėra nieko blogo, jei tik suprantate, kad abu turi pranašumų.
Jei kas nors pasikeitė dėklo VPC ir norėjote pritaikyti šiuos pakeitimus EC2, t. y. norėjote atnaujinti automatinio mastelio keitimo grupę, nes turėjote naują potinklį, tada aš vadinu tokį priklausomybės orkestravimą. Yra keletas sprendimų: kas ką naudoja?
Galiu pasiūlyti kokių sprendimų yra. Norėdami atlikti magiją, galite naudoti „Terraform“ arba „Terraform“ galite naudoti makefiles. Ir pažiūrėkite, ar ten kažkas pasikeitė, galite jį paleisti čia.
Kaip jums šis sprendimas? Ar kas nors mano, kad tai puikus sprendimas? Matau šypseną, matyt, įsivėlė abejonės.
Žinoma, nebandykite to namuose. Terraform niekada nebuvo sukurtas paleisti iš Terraform.
Viename pranešime jie man pasakė: „Ne, tai neveiks“. Esmė ta, kad tai neturėtų veikti. Nors atrodo taip įspūdingai, kai galite paleisti „Terraform“ iš „Terraform“, o tada „Terraform“, neturėtumėte to daryti. Terraform visada turėtų prasidėti labai lengvai.
Jei jums reikia skambučių orkestravimo, kai kažkas pasikeitė vienoje vietoje, tada yra „Terragrunt“.
„Terragrunt“ yra įrankis, „Terraform“ priedas, leidžiantis koordinuoti ir organizuoti skambučius į infrastruktūros modulius.
Įprastas Terraform konfigūracijos failas atrodo taip.
Jūs nurodote, į kurį konkretų modulį norite skambinti.
Kokias priklausomybes turi modulis?
Ir kokius argumentus priima šis modulis. Tai viskas, ką reikia žinoti apie „Terragrunt“.
Dokumentacija yra, o „GitHub“ yra 1 žvaigždučių. Tačiau daugeliu atvejų tai yra tai, ką reikia žinoti. Ir tai labai lengva įdiegti įmonėse, kurios tik pradeda dirbti su Terraform.
Taigi orkestruotė yra „Terragrunt“. Yra ir kitų variantų.
Dabar pakalbėkime apie tai, kaip dirbti su kodu.
Jei prie kodo reikia pridėti naujų funkcijų, daugeliu atvejų tai paprasta. Rašote naują šaltinį, viskas paprasta.
Jei turite kokių nors išteklių, kuriuos sukūrėte iš anksto, pavyzdžiui, sužinojote apie Terraform atidarę AWS paskyrą ir norite naudoti jau turimus išteklius, tuomet būtų tikslinga išplėsti savo modulį tokiu būdu, kad ji palaiko esamų išteklių naudojimą.
Ir palaikė naujų išteklių kūrimą naudojant blokinius išteklius.
Išvestyje visada grąžiname išvesties ID, priklausomai nuo to, kas buvo naudojama.
Antroji labai svarbi „Terraform 0.11“ problema yra darbas su sąrašais.
Sunkumas yra tas, kad jei turime tokį vartotojų sąrašą.
Ir kai mes sukuriame šiuos vartotojus naudodami blokinius išteklius, viskas vyksta gerai. Peržiūrime visą sąrašą, sukurdami failą kiekvienam. Viskas gerai. Ir tada, pavyzdžiui, vartotojas3, kuris yra viduryje, turėtų būti pašalintas iš čia, tada visi resursai, kurie buvo sukurti po jo, bus atkurti, nes indeksas pasikeis.
Darbas su sąrašais būsenos aplinkoje. Kas yra valstybinė aplinka? Tai situacija, kai sukuriama nauja vertė, kai sukuriamas šis išteklius. Pavyzdžiui, AWS prieigos raktas arba AWS slaptasis raktas, t. y. kai sukuriame vartotoją, gauname naują prieigos arba slaptąjį raktą. Ir kiekvieną kartą, kai ištrinsime vartotoją, šis vartotojas turės naują raktą. Bet tai nėra feng shui, nes vartotojas nenorės su mumis draugauti, jei kaskart, kai kas nors išeis iš komandos, sukursime jam naują vartotoją.
Tai yra sprendimas. Tai kodas, parašytas Jsonnet. „Jsonnet“ yra „Google“ šablonų kalba.
Ši komanda leidžia priimti šį šabloną ir kaip išvestį grąžina json failą, sukurtą pagal jūsų šabloną.
Šablonas atrodo taip.
„Terraform“ leidžia dirbti tiek su HCL, tiek su „Json“ vienodai, taigi, jei turite galimybę generuoti Json, galite jį perkelti į „Terraform“. Failas su plėtiniu .tf.json bus sėkmingai atsisiųstas.
Ir tada mes dirbame su juo kaip įprasta: taikome terraform init, terramorm. Ir sukuriame du vartotojus.
Dabar nebijome, jei kas nors paliks komandą. Mes tiesiog redaguosime json failą. Vasya Pupkin išėjo, Petya Pyatochkin liko. Petya Pyatochkin negaus naujo rakto.
„Terraform“ integravimas su kitais įrankiais iš tikrųjų nėra „Terraform“ darbas. „Terraform“ buvo sukurta kaip resursų kūrimo platforma ir viskas. Ir viskas, kas atsiranda vėliau, nėra „Terraform“ rūpestis. Ir nereikia jo ten pinti. Yra Ansible, kuri daro viską, ko reikia.
Tačiau pasitaiko situacijų, kai norime išplėsti „Terraform“ ir iškviesti komandą po to, kai kažkas bus baigta.
Pirmas būdas. Sukuriame išvestį, kurioje rašome šią komandą.
Tada iškviečiame šią komandą iš apvalkalo terraform išvesties ir nurodome norimą reikšmę. Taigi komanda vykdoma su visomis pakeistomis reikšmėmis. Tai labai patogu.
Antras būdas. Tai yra null_resource naudojimas, atsižvelgiant į mūsų infrastruktūros pokyčius. Galime iškviesti tą patį vietinį exe, kai tik pasikeičia kai kurių išteklių ID.
Natūralu, kad popieriuje viskas sklandžiai, nes „Amazon“, kaip ir visi kiti viešieji paslaugų teikėjai, turi daugybę savų dėklų.
Labiausiai paplitęs atvejis yra tas, kad kai atidarote AWS paskyrą, svarbu, kuriuos regionus naudojate; ar ši funkcija ten įjungta; galbūt atidarėte ją po 2013 m. gruodžio mėn.; galbūt jūs naudojate numatytąjį VPC ir tt Yra daug apribojimų. Ir „Amazon“ juos išsklaidė po visą dokumentaciją.
Yra keletas dalykų, kurių rekomenduoju vengti.
Norėdami pradėti, venkite visų neslapčių argumentų Terraform plane arba Terraform CLI. Visa tai galima įdėti į tfvars failą arba į aplinkos kintamąjį.
Bet jums nereikia įsiminti visos šios stebuklingos komandos. Terraform planas – var ir pirmyn. Pirmasis kintamasis yra var, antrasis kintamasis yra var, trečias, ketvirtas. Svarbiausias infrastruktūros, kaip kodo, principas, kurį naudoju dažniausiai, yra tas, kad vien pažiūrėjęs į kodą turėčiau aiškiai suprasti, kas ten yra įdiegta, kokios būklės ir su kokiomis vertybėmis. Taigi man nereikia skaityti dokumentų ar klausti Vasios, kokius parametrus jis naudojo kurdamas mūsų klasterį. Man tereikia atsidaryti failą su plėtiniu tfvars, kuris dažnai atitinka aplinką, ir viską ten pažiūrėti.
Be to, nenaudokite tikslinių argumentų, kad sumažintumėte apimtį. Tam daug lengviau naudoti mažus infrastruktūros modulius.
Be to, nereikia apriboti ir didinti lygiagretumo. Jei turiu 150 išteklių ir noriu padidinti Amazon lygiagretumą nuo numatytųjų 10 iki 100, greičiausiai kažkas nutiks. Arba dabar viskas gerai, bet kai „Amazon“ pasakys, kad skambinate per daug, turėsite problemų.
„Terraform“ bandys iš naujo paleisti daugumą šių problemų, bet jūs beveik nieko nepasieksite. Parallelism=1 yra svarbus dalykas, kurį reikia naudoti, jei AWS API arba „Terraform“ teikėjo viduje aptinkate klaidą. Tada reikia nurodyti: paralelizmas=1 ir palaukti, kol Terraform užbaigs vieną skambutį, tada antrą, tada trečią. Jis paleis juos po vieną.
Žmonės dažnai manęs klausia: „Kodėl aš manau, kad Terraform darbo vietos yra blogis? Manau, kad infrastruktūros kaip kodo principas yra pamatyti, kokia infrastruktūra sukurta ir su kokiomis vertybėmis.
Darbo sritis nesukūrė vartotojai. Tai nereiškia, kad vartotojai „GitHub“ problemose parašė, kad negalime gyventi be „Terraform“ darbo vietų. Ne ne taip. Terraform Enterprise yra komercinis sprendimas. „Terraform“ iš „HashiCorp“ nusprendė, kad mums reikia darbo vietų, todėl jį išsiuntėme. Manau, kad daug lengviau jį sudėti į atskirą aplanką. Tada bus šiek tiek daugiau failų, bet bus aiškiau.
Kaip dirbti su kodu? Tiesą sakant, darbas su sąrašais yra vienintelis skausmas. Ir paimkite Terraform lengviau. Tai nėra tas dalykas, kuris jums viską puikiai padarys. Nereikia ten kišti visko, kas parašyta dokumentacijoje.
Pranešimo tema buvo parašyta „ateičiai“. Pakalbėsiu apie tai labai trumpai. Ateityje tai reiškia, kad netrukus bus išleista 0.12 versija.
0.12 yra daugybė naujų dalykų. Jei ateinate iš įprasto programavimo, tai pasigendate visokių dinaminių blokų, ciklų, teisingų ir sąlyginių palyginimų operacijų, kur kairioji ir dešinė pusės skaičiuojamos ne vienu metu, o priklausomai nuo situacijos. Jūs to labai pasiilgote, todėl 0.12 tai išspręs už jus.
Bet! Jei rašysite mažiau ir paprasčiau, naudodami paruoštus modulius ir trečiųjų šalių sprendimus, tada jums nereikės laukti ir tikėtis, kad ateis 0.12 ir viską sutvarkys už jus.
Ačiū už pranešimą! Jūs kalbėjote apie infrastruktūrą kaip kodą ir pažodžiui pasakėte vieną žodį apie bandymus. Ar moduliuose reikia testų? Kieno tai atsakomybė? Ar turiu tai parašyti pačiam, ar tai modulių atsakomybė?
Kiti metai bus užpildyti pranešimais, kad nusprendėme viską išbandyti. Ką išbandyti – didžiausias klausimas. Yra daug priklausomybių, daugybė skirtingų tiekėjų apribojimų. Kai mes su mumis kalbamės ir sakote: „Man reikia testų“, aš klausiu: „Ką tikrinsi? Sakote, kad testuosite savo regione. Tada sakau, kad mano regione tai neveikia. Tai yra, mes net negalėsime dėl to susitarti. Jau nekalbant apie tai, kad yra daug techninių problemų. Tai yra, kaip parašyti šiuos testus, kad jie būtų tinkami.
Aktyviai tyrinėju šią temą, t. y. kaip automatiškai generuoti testus pagal jūsų parašytą infrastruktūrą. Tai yra, jei parašėte šį kodą, aš turiu jį paleisti, pagal tai galiu sukurti testus.
yra viena iš dažniausiai minimų bibliotekų, leidžiančių rašyti Terraform integracijos testus. Tai viena iš komunalinių paslaugų. Man labiau patinka DSL tipas, pavyzdžiui, rspec.
Antanai, ačiū už pranešimą! Mano vardas Valerijus. Leiskite užduoti nedidelį filosofinį klausimą. Sąlygiškai yra aprūpinimas, yra diegimas. Aprūpinimas sukuria mano infrastruktūrą, diegdami ją užpildome kažkuo naudingu, pavyzdžiui, serveriais, programomis ir tt Ir man atrodo, kad „Terraform“ labiau skirtas aprūpinimui, o „Ansible“ labiau skirtas diegimui, nes „Ansible“ taip pat yra skirtas fizinei infrastruktūrai. leidžia įdiegti nginx, Postgres. Tačiau tuo pat metu atrodo, kad „Ansible“ leidžia aprūpinti, pavyzdžiui, „Amazon“ ar „Google“ išteklius. Tačiau „Terraform“ taip pat leidžia įdiegti tam tikrą programinę įrangą naudojant jos modulius. Jūsų požiūriu, ar tarp Terraform ir Ansible yra kažkokia riba, kur ir ką geriau naudoti? Ar, pavyzdžiui, manote, kad „Ansible“ jau yra šiukšlės, viskam reiktų pabandyti naudoti „Terraform“?
Geras klausimas, Valerij. Manau, kad Terraform pagal paskirtį nepasikeitė nuo 2014 m. Jis buvo sukurtas infrastruktūrai ir mirė dėl infrastruktūros. Mes vis dar turėjome ir turėsime konfigūracijos valdymo Ansible poreikį. Iššūkis yra tas, kad launch_configuration viduje yra vartotojo duomenų. Ir ten traukiate Ansible ir tt Tai yra standartinis skirtumas, kuris man labiausiai patinka.
Jei kalbame apie gražią infrastruktūrą, tai yra komunalinių paslaugų, tokių kaip „Packer“, kurios renka šį vaizdą. Tada Terraform naudoja duomenų šaltinį, kad surastų šį vaizdą ir atnaujintų jo launch_configuration. Tai yra, tokiu būdu dujotiekis yra toks, kad pirmiausia traukiame Tracker, tada traukiame Terraform. Ir jei įvyksta statyba, įvyksta naujas pokytis.
Sveiki! Ačiū už pranešimą! Mano vardas Misha, RBS įmonė. Kurdami išteklius galite paskambinti Ansible per aprūpinimo priemonę. Ansible taip pat turi temą, vadinamą dinamine inventorizacija. Ir pirmiausia galite paskambinti „Terraform“, o tada paskambinti „Ansible“, kuri paims iš valstybės išteklius ir vykdys. Kas geriau?
Žmonės vienodai sėkmingai naudoja abu. Man atrodo, kad dinaminis inventorius Ansible yra patogus dalykas, jei nekalbame apie automatinio skalavimo grupę. Kadangi automatinio mastelio keitimo grupėje mes jau turime savo įrankių rinkinį, kuris vadinamas launch_configuration. Lauryn_configuration įrašome viską, ką reikia paleisti, kai sukuriame naują šaltinį. Todėl, mano nuomone, naudojant „Amazon“ dinaminio inventoriaus naudojimas ir „Terraform ts“ failo skaitymas yra perdėtas. Ir jei naudojate kitus įrankius, kuriuose nėra „automatinės skalės grupės“ sąvokos, pavyzdžiui, naudojate „DigitalOcean“ ar kitą tiekėją, kur nėra automatinio skalavimo grupės, tada ten turėsite rankiniu būdu ištraukti API, rasti IP adresus, sukurti dinaminis inventoriaus failas , o Ansible jau vaikščios po jį. Tai reiškia, kad „Amazon“ yra launch_configuration, o visa kita – dinamiškas inventorius.
Šaltinis: www.habr.com