Mnoho ľudí pozná a používa Terraform vo svojej každodennej práci, ale najlepšie postupy pre to ešte neboli vytvorené. Každý tím si musí vymyslieť svoje vlastné prístupy a metódy.
Vaša infraštruktúra takmer určite začína jednoducho: niekoľko zdrojov + niekoľko vývojárov. Postupom času sa rozrastá všetkými možnými smermi. Nájdete spôsoby, ako zoskupiť zdroje do modulov Terraform, usporiadať kód do priečinkov a čo ešte sa môže pokaziť? (slávne posledné slová)
Čas plynie a vy máte pocit, že vaša infraštruktúra je vaším novým miláčikom, ale prečo? Máte obavy z nevysvetliteľných zmien v infraštruktúre, bojíte sa dotknúť sa infraštruktúry a kódu - v dôsledku toho odďaľujete novú funkcionalitu alebo znižujete kvalitu...
Po troch rokoch spravovania zbierky komunitných modulov Terraform pre AWS na Github a dlhodobej údržby Terraformu vo výrobe je Anton Babenko pripravený podeliť sa o svoje skúsenosti: ako napísať moduly TF tak, aby to v budúcnosti nebolelo.
Na konci prednášky budú účastníci lepšie oboznámení s princípmi riadenia zdrojov v Terraforme, osvedčenými postupmi spojenými s modulmi v Terraforme a niektorými princípmi nepretržitej integrácie spojenými s riadením infraštruktúry.
disclaimer: Beriem na vedomie, že táto správa je z novembra 2018 – už uplynuli 2 roky. Verzia Terraform 0.11, o ktorej sa hovorí v správe, už nie je podporovaná. Za posledné 2 roky vyšli 2 nové vydania, ktoré obsahujú množstvo noviniek, vylepšení a zmien. Venujte tomu pozornosť a skontrolujte dokumentáciu.
odkazy:
- +
- — kód a dokumentácia automatického formátovania
- — generátor modulov Terraform (WIP)
- — Generátor kódu Terraform z vizuálnych diagramov (WIP)
- www.terraform-best-practices.com
- (Nové príspevky sú na mojej osobnej stránke www.antonbabenko.com/)
- @antonbabenko - Twitter a veľa rôznych Slackov
Volám sa Anton Babenko. Niektorí z vás pravdepodobne použili kód, ktorý som napísal. Teraz o tom budem hovoriť s väčšou istotou ako kedykoľvek predtým, pretože mám prístup k štatistikám.
Pracujem na Terraforme a od roku 2015 som aktívnym účastníkom a prispievateľom do veľkého množstva open source projektov súvisiacich s Terraformom a Amazonom.
Odvtedy som napísal dosť kódu na to, aby som to dal zaujímavým spôsobom. A pokúsim sa vám o tom teraz povedať.
Budem hovoriť o zložitosti a špecifikách práce s Terraformom. Ale to v skutočnosti nie je predmetom HighLoad. A teraz pochopíte prečo.
Postupom času som začal písať moduly Terraform. Používatelia písali otázky, ja som ich prepisoval. Potom som napísal rôzne nástroje na formátovanie kódu pomocou háku pred potvrdením atď.
Vzniklo veľa zaujímavých projektov. Mám rád generovanie kódu, pretože mám rád, že počítač robí stále viac práce za mňa a programátora, takže momentálne pracujem na generátore kódu Terraform z vizuálnych diagramov. Možno ich niektorí z vás videli. Sú to krásne krabice so šípkami. A myslím si, že je skvelé, ak môžete kliknúť na tlačidlo „Exportovať“ a získať to všetko ako kód.
Som z Ukrajiny. Dlhé roky žijem v Nórsku.
Informácie pre túto správu boli tiež zozbierané od ľudí, ktorí poznajú moje meno a nájdu ma na sociálnych sieťach. Skoro vždy mám rovnakú prezývku.
Ako som už spomenul, som hlavným správcom modulov Terraform AWS, čo je jedno z najväčších úložísk na GitHub, kde hosťujeme moduly pre najbežnejšie úlohy: VPC, Autoscaling, RDS.
A to, čo ste teraz počuli, je to najzákladnejšie. Ak pochybujete, že rozumiete tomu, čo je Terraform, potom je lepšie stráviť čas niekde inde. Bude tu veľa odborných výrazov. A neváhal som vyhlásiť úroveň správy za najvyššiu. To znamená, že môžem hovoriť pomocou všetkých možných výrazov bez veľkého vysvetľovania.
Terraform sa objavil v roku 2014 ako nástroj, ktorý vám umožnil písať, plánovať a spravovať infraštruktúru ako kód. Kľúčovým konceptom je „infraštruktúra ako kód“.
Všetka dokumentácia, ako som povedal, je napísaná . Dúfam, že väčšina ľudí vie o tejto stránke a prečítala si dokumentáciu. Ak áno, tak ste na správnom mieste.
Takto vyzerá bežný konfiguračný súbor Terraform, kde si najprv zadefinujeme nejaké premenné.
V tomto prípade definujeme „aws_region“.
Potom popíšeme, aké zdroje chceme vytvoriť.
Spúšťame niektoré príkazy, najmä „terraform init“, aby sme načítali závislosti a poskytovateľov.
A spustíme príkaz „terraform apply“, aby sme skontrolovali, či sa zadaná konfigurácia zhoduje s prostriedkami, ktoré sme vytvorili. Keďže sme predtým nič nevytvorili, Terraform nás vyzýva, aby sme tieto zdroje vytvorili.
Toto potvrdzujeme. Takto vytvoríme vedierko nazývané morský slimák.
Existuje tiež niekoľko podobných nástrojov. Mnohí z vás, ktorí používate Amazon, poznáte AWS CloudFormation alebo Google Cloud Deployment Manager alebo Azure Resource Manager. Každý z nich má svoju vlastnú implementáciu určitého druhu na riadenie zdrojov v rámci každého z týchto verejných poskytovateľov cloudu. Terraform je obzvlášť užitočný, pretože vám umožňuje spravovať viac ako 100 poskytovateľov. (Viac informácií )
Ciele, ktoré Terraform sleduje od samého začiatku:
- Terraform poskytuje jediný pohľad na zdroje.
- Umožňuje vám podporovať všetky moderné platformy.
- A Terraform bol od samého začiatku navrhnutý ako nástroj, ktorý vám umožňuje bezpečne a predvídateľne meniť infraštruktúru.
V roku 2014 slovo „predvídateľný“ znelo v tomto kontexte veľmi nezvyčajne.
Terraform je univerzálny nástroj. Ak máte API, môžete ovládať úplne všetko:
- Na správu všetkého, čo chcete, môžete využiť viac ako 120 poskytovateľov.
- Terraform môžete použiť napríklad na popis prístupu k úložiskám GitHub.
- V Jira môžete dokonca vytvárať a zatvárať chyby.
- Môžete spravovať metriky New Relic.
- Ak naozaj chcete, môžete dokonca vytvárať súbory v schránke.
To všetko sa dosahuje pomocou poskytovateľov Terraform, ktorí majú otvorené API, ktoré možno opísať v Go.
Povedzme, že sme začali používať Terraform, prečítali si nejakú dokumentáciu na stránke, pozreli nejaké video a začali písať main.tf, ako som ukázal na predchádzajúcich snímkach.
A všetko je skvelé, máte súbor, ktorý vytvára VPC.
Ak chcete vytvoriť VPC, zadajte približne týchto 12 riadkov. Popíšte, v ktorej oblasti chcete vytvoriť, ktorý cidr_block adries IP použiť. To je všetko.
Prirodzene, projekt sa bude postupne rozrastať.
A pridáte tam kopu nových vecí: zdroje, zdroje údajov, integrujete sa s novými poskytovateľmi, zrazu budete chcieť použiť Terraform na správu používateľov vo svojom účte GitHub atď. Možno budete chcieť použiť iné Poskytovatelia DNS, krížte všetko. Terraform to uľahčuje.
Pozrime sa na nasledujúci príklad.
Postupne pridávate internet_gateway, pretože chcete, aby zdroje z vášho VPC mali prístup na internet. To je dobrý nápad.
Výsledkom je tento main.tf:
Toto je horná časť main.tf.
Toto je spodná časť main.tf.
Potom pridáte podsieť. V čase, keď chcete pridať brány NAT, trasy, smerovacie tabuľky a kopu ďalších podsietí, nebudete mať 38 liniek, ale približne 200-300 liniek.
To znamená, že váš súbor main.tf postupne rastie. A dosť často ľudia dávajú všetko do jedného súboru. 10-20 Kb sa objaví v main.tf. Predstavte si, že 10-20 Kb je textový obsah. A všetko so všetkým súvisí. S tým je postupne ťažké pracovať. 10-20 Kb je dobrý používateľský prípad, niekedy aj viac. A ľudia si nie vždy myslia, že je to zlé.
Rovnako ako v bežnom programovaní, teda nie infraštruktúra ako kód, sme zvyknutí používať veľa rôznych tried, balíkov, modulov, zoskupení. Terraform vám umožňuje robiť takmer to isté.
- Kód rastie.
- Rastú aj závislosti medzi zdrojmi.
A máme veľkú, veľkú potrebu. Chápeme, že takto už ďalej žiť nemôžeme. Náš kód sa stáva obrovským. 10-20 Kb, samozrejme, nie je príliš veľké, ale hovoríme len o sieťovom zásobníku, t. j. pridali ste iba sieťové zdroje. Nehovoríme o Application Load Balancer, nasadzovaní ES cluster, Kubernetes atď., kde sa dá ľahko vložiť 100 Kb. Ak si toto všetko zapíšete, veľmi skoro zistíte, že Terraform poskytuje moduly Terraform.
Moduly Terraform sú samostatnou konfiguráciou Terraform, ktorá je spravovaná ako skupina. To je všetko, čo potrebujete vedieť o moduloch Terraform. Vôbec nie sú chytrí, neumožňujú robiť žiadne zložité spojenia v závislosti od niečoho. To všetko padá na plecia vývojárov. To znamená, že toto je len nejaký druh konfigurácie Terraform, ktorý ste už napísali. A môžete to jednoducho nazvať ako skupina.
Snažíme sa teda pochopiť, ako optimalizujeme našich 10-20-30 Kb kódu. Postupne si uvedomujeme, že niektoré moduly musíme využiť.
Prvý typ modulov, s ktorými sa stretnete, sú moduly zdrojov. Nerozumejú tomu, o čom je vaša infraštruktúra, o čom je vaše podnikanie, kde a aké sú podmienky. Toto sú presne moduly, ktoré spolu s open source komunitou spravujem a ktoré predkladáme ako úplne počiatočné stavebné kamene pre vašu infraštruktúru.
Príklad modulu zdrojov.
Keď voláme zdrojový modul, určíme, z ktorej cesty máme načítať jeho obsah.
Označíme verziu, ktorú chceme stiahnuť.
Odovzdáme tam kopu argumentov. To je všetko. To je všetko, čo potrebujeme vedieť, keď používame tento modul.
Veľa ľudí si myslí, že ak použijú najnovšiu verziu, všetko bude stabilné. Ale nie. Infraštruktúra musí byť verzovaná, musíme jasne odpovedať, na akú verziu bol ten či onen komponent nasadený.
Tu je kód, ktorý sa nachádza v tomto module. Modul bezpečnostnej skupiny. Tu zvitok prejde na 640. riadok. Vytvorenie bezpečnostného zdroja v Amazone vo všetkých možných konfiguráciách je veľmi netriviálna úloha. Nestačí jednoducho vytvoriť bezpečnostnú skupinu a povedať jej, aké pravidlá jej má odovzdať. Bolo by to veľmi jednoduché. V Amazone existuje milión rôznych obmedzení. Napríklad, ak používate Koncový bod VPC, zoznam prefixov, rôzne API a snaží sa toto všetko skombinovať so všetkým ostatným, potom vám to Terraform neumožňuje. A neumožňuje to ani Amazon API. Preto musíme všetku túto hroznú logiku skryť do modulu a poskytnúť používateľovi kód, ktorý vyzerá presne takto.
Používateľ nemusí vedieť, ako sa vo vnútri vyrába.
Druhý typ modulov, ktorý pozostáva zo zdrojových modulov, už rieši problémy, ktoré sú pre váš biznis vhodnejšie. Často je to miesto, ktoré je rozšírením pre Terraform a nastavuje určité pevné hodnoty pre štítky, pre firemné štandardy. Môžete tam pridať aj funkcie, ktoré vám Terraform momentálne neumožňuje. Toto je práve teraz. Teraz verzia 0.11, ktorá sa čoskoro stane minulosťou. Ale predsa len, preprocesory, jsonnet, cookiecutter a kopa ďalších vecí sú tým pomocným mechanizmom, ktorý treba použiť na plnohodnotnú prácu.
Ďalej ukážem niekoľko príkladov tohto.
Modul infraštruktúry sa volá presne rovnakým spôsobom.
Je uvedený zdroj, z ktorého sa má obsah stiahnuť.
Do tohto modulu sa odovzdáva množstvo hodnôt.
Ďalej sa v tomto module volá množstvo modulov prostriedkov na vytvorenie VPC alebo aplikácie Load Balancer, alebo na vytvorenie bezpečnostnej skupiny alebo pre klaster Elastic Container Service.
Existujú dva typy modulov. Toto je dôležité pochopiť, pretože väčšina informácií, ktoré som zoskupil v tejto správe, nie je zapísaná v dokumentácii.
A dokumentácia v Terraforme je práve teraz dosť problematická, pretože len hovorí, že existujú tieto funkcie, môžete ich použiť. Nehovorí však, ako tieto funkcie používať, prečo je lepšie ich používať. Preto veľké množstvo ľudí píše niečo, s čím nemôžu žiť.
Ďalej sa pozrime na to, ako tieto moduly napísať. Potom uvidíme, ako ich volať a ako pracovať s kódom.
Register Terraform -
Tip #0 je nepísať moduly zdrojov. Väčšina z týchto modulov je už pre vás napísaná. Ako som povedal, sú open source, neobsahujú žiadnu vašu obchodnú logiku, nemajú napevno zakódované hodnoty IP adries, hesiel atď. Modul je veľmi flexibilný. A s najväčšou pravdepodobnosťou to už bolo napísané. Existuje veľa modulov pre zdroje od Amazonu. Okolo 650. A väčšina z nich je kvalitných.
V tomto príklade za vami niekto prišiel a povedal: „Chcem vedieť spravovať databázu. Vytvorte modul, aby som mohol vytvoriť databázu." Osoba nepozná podrobnosti o implementácii Amazonu ani Terraformu. Jednoducho povie: "Chcem spravovať MSSQL." To znamená, že to zavolá náš modul, odovzdá tam typ motora a uvedie časové pásmo.
A človek by nemal vedieť, že v tomto module vytvoríme dva rôzne zdroje: jeden pre MSSQL, druhý pre všetko ostatné, len preto, že v Terraforme 0.11 nemôžete zadať hodnoty časového pásma ako voliteľné.
A pri výstupe z tohto modulu bude môcť osoba jednoducho dostať adresu. Nebude vedieť, z ktorej databázy, z akého zdroja to všetko interne vytvárame. Toto je veľmi dôležitý prvok utajovania. A to platí nielen pre tie moduly, ktoré sú verejné v open source, ale aj pre tie moduly, ktoré budete písať vo svojich projektoch a tímoch.
Toto je druhý argument, ktorý je dosť dôležitý, ak Terraform už nejaký čas používate. Máte úložisko, do ktorého vložíte všetky svoje moduly Terraform pre vašu spoločnosť. A je celkom normálne, že časom tento projekt narastie do veľkosti jedného až dvoch megabajtov. Toto je fajn.
Problém je však v tom, ako Terraform tieto moduly nazýva. Napríklad, ak zavoláte modul na vytvorenie každého jednotlivého používateľa, Terraform najprv načíta celé úložisko a potom prejde do priečinka, kde sa nachádza daný modul. Takto si stiahnete zakaždým jeden megabajt. Ak spravujete 100 alebo 200 používateľov, stiahnete 100 alebo 200 megabajtov a potom prejdete do tohto priečinka. Takže prirodzene nechcete sťahovať veľa vecí zakaždým, keď stlačíte "Terraform init".
Existujú dve riešenia tohto problému. Prvým je použitie relatívnych ciest. Týmto spôsobom v kóde uvediete, že priečinok je lokálny (./). A predtým, ako čokoľvek spustíte, lokálne vytvoríte klon Git tohto úložiska. Takto to urobíte raz.
Existuje, samozrejme, veľa nevýhod. Nemôžete napríklad použiť vytváranie verzií. A s tým je niekedy ťažké žiť.
Druhé riešenie. Ak máte veľa submodulov a už máte nejaký zabehnutý pipeline, tak je tu projekt MBT, ktorý vám umožňuje zbierať veľa rôznych balíčkov z monorepozitára a nahrávať ich do S3. Toto je veľmi dobrý spôsob. Súbor iam-user-1.0.0.zip bude teda vážiť iba 1 Kb, pretože kód na vytvorenie tohto zdroja je veľmi malý. A bude to fungovať oveľa rýchlejšie.
Povedzme si, čo sa v moduloch nedá použiť.
Prečo je toto zlo v moduloch? Najhoršie je predpokladať užívateľa. Predpokladajme, že používateľ je možnosť overenia poskytovateľa, ktorú môžu používať rôzni ľudia. Napríklad všetci asimilujeme rolu. To znamená, že Terraform prevezme túto úlohu. A potom s touto úlohou bude vykonávať ďalšie akcie.
A zlé je, že ak sa Vasya rád pripája k Amazonu jedným spôsobom, napríklad pomocou predvolenej premennej prostredia, a Peťa rád používa svoj zdieľaný kľúč, ktorý má na tajnom mieste, potom nemôžete zadať oboje v Terraform. A aby nezažili utrpenie, nie je potrebné tento blok označovať v module. Toto musí byť uvedené na vyššej úrovni. To znamená, že navrchu máme modul zdrojov, modul infraštruktúry a zloženie. A to by malo byť uvedené niekde vyššie.
Druhé zlo je proviant. Tu zlo nie je také triviálne, pretože ak napíšete kód a funguje vám, potom si možno myslíte, že ak to funguje, tak prečo to meniť.
Zlo je v tom, že nie vždy kontrolujete, kedy bude tento provízor spustený. A po druhé, nemáte kontrolu nad tým, čo znamená aws ec2, t.j. teraz hovoríme o Linuxe alebo Windowse. Nemôžete teda napísať niečo, čo bude fungovať rovnako na rôznych operačných systémoch alebo v rôznych používateľských prípadoch.
Najbežnejším príkladom, ktorý je uvedený aj v oficiálnej dokumentácii, je, že ak napíšete aws_instance a uvediete veľa argumentov, potom nie je nič zlé, ak tam zadáte poskytovateľa „local-exec“ a spustíte svoj ansible- playbook .
V skutočnosti áno, nie je na tom nič zlé. Ale doslova čoskoro si uvedomíte, že táto vec local-exec neexistuje, napríklad v launch_configuration.
A keď použijete launch_configuration a chcete vytvoriť skupinu automatického škálovania z jednej inštancie, potom v launch_configuration neexistuje pojem „provisioner“. Existuje pojem „údaje používateľa“.
Preto je univerzálnejším riešením použitie používateľských údajov. A spustí sa buď na samotnej inštancii, keď je inštancia zapnutá, alebo v rovnakých používateľských údajoch, keď skupina automatického škálovania použije túto launch_configuration.
Ak stále chcete spustiť provizórium, pretože je to lepiaci komponent, keď sa vytvorí jeden zdroj, v tom momente musíte spustiť svoj provizor, váš príkaz. Takýchto situácií je veľa.
A najsprávnejší zdroj na to sa nazýva null_resource. Null_resource je fiktívny zdroj, ktorý sa v skutočnosti nikdy nevytvorí. Ničoho sa nedotýka, žiadne API, žiadne automatické škálovanie. Ale umožňuje vám ovládať, kedy spustiť príkaz. V tomto prípade sa príkaz spustí počas vytvárania.
Odkaz
Existuje niekoľko znakov. Nebudem sa veľmi podrobne zaoberať všetkými znakmi. Je o tom článok. Ak ste však pracovali s Terraformom alebo používali moduly iných ľudí, často ste si všimli, že mnoho modulov, ako väčšina kódu v otvorenom zdroji, je napísaných ľuďmi pre ich vlastné potreby. Napísal to muž a vyriešil svoj problém. Nalepil som to na GitHub, nech to žije. Bude žiť, ale ak tam nebude dokumentácia a príklady, nikto to nebude používať. A ak neexistuje žiadna funkcia, ktorá by vám umožnila vyriešiť o niečo viac, ako je jej špecifická úloha, nikto ju nebude používať. Existuje mnoho spôsobov, ako stratiť používateľov.
Ak chcete niečo napísať, aby to ľudia používali, potom odporúčam riadiť sa týmito znakmi.
Sú to:
- Dokumentácia a príklady.
- Plná funkčnosť.
- Rozumné predvolené hodnoty.
- Čistý kód.
- Testy.
Testy sú iná situácia, pretože sa píšu dosť ťažko. Viac verím v dokumentáciu a príklady.
Takže sme sa pozreli na to, ako písať moduly. Existujú dva argumenty. Prvou, ktorá je najdôležitejšia, je nepísať, ak môžete, pretože tieto úlohy už urobila kopa ľudí pred vami. A po druhé, ak sa stále rozhodnete, skúste nepoužívať poskytovateľov v moduloch a provizóriách.
Toto je sivá časť dokumentácie. Možno si teraz pomyslíte: „Niečo nie je jasné. Nie som presvedčený." Ale uvidíme o šesť mesiacov.
Teraz si povedzme, ako tieto moduly volať.
Chápeme, že náš kód sa časom rozrastá. Už nemáme jeden súbor, už máme 20 súborov. Všetky sú v jednom priečinku. Alebo možno päť priečinkov. Možno ich začíname nejako rozoberať podľa regiónov, podľa niektorých komponentov. Potom pochopíme, že teraz máme nejaké základy synchronizácie a orchestrácie. To znamená, že musíme pochopiť, čo by sme mali robiť, ak sme zmenili sieťové zdroje, čo by sme mali robiť so zvyškom našich zdrojov, ako spôsobiť tieto závislosti atď.
Existujú dva extrémy. Prvý extrém je všetko v jednom. Máme jeden hlavný súbor. Toto bol zatiaľ oficiálny osvedčený postup na webovej stránke Terraform.
Teraz je však napísaný ako zastaraný a odstránený. Po čase si komunita Terraform uvedomila, že to zďaleka nie je najlepší postup, pretože ľudia začali projekt využívať rôznymi spôsobmi. A sú tu problémy. Napríklad, keď uvádzame všetky závislosti na jednom mieste. Sú situácie, keď klikneme na „Plán Terraform“ a kým Terraform neaktualizuje stavy všetkých zdrojov, môže uplynúť veľa času.
Veľa času je napríklad 5 minút. Pre niektorých je to veľa času. Videl som prípady, keď to trvalo 15 minút. AWS API sa 15 minút snažilo zistiť, čo sa deje so stavom každého zdroja. Toto je veľmi veľká oblasť.
A, prirodzene, súvisiaci problém sa objaví, keď chcete niečo zmeniť na jednom mieste, potom počkáte 15 minút, a to vám poskytne plátno s niekoľkými zmenami. Odpľuli ste si, napísali „Áno“ a niečo sa pokazilo. Toto je veľmi reálny príklad. Terraform sa vás nesnaží chrániť pred problémami. To znamená, píšte, čo chcete. Budú problémy - vaše problémy. Zatiaľ čo Terraform 0.11 sa vám žiadnym spôsobom nesnaží pomôcť. V 0.12 sú určité zaujímavé miesta, ktoré vám umožňujú povedať: „Vasya, toto naozaj chceš, môžeš prísť k rozumu?“
Druhým spôsobom je zmenšiť túto oblasť, to znamená, že hovory z jedného miesta môžu byť menej prepojené z iného miesta.
Jediným problémom je, že musíte napísať viac kódu, t.j. musíte opísať premenné vo veľkom počte súborov a aktualizovať to. Niektorým sa to nepáči. To je pre mňa normálne. A niektorí ľudia si myslia: "Prečo to písať na rôzne miesta, dám to všetko na jedno miesto." Je to možné, ale toto je druhý extrém.
Kto to všetko žije na jednom mieste? Jeden, dvaja, traja ľudia, teda niekto to používa.
A kto volá jeden konkrétny komponent, jeden blok alebo jeden modul infraštruktúry? Päť až sedem ľudí. Toto je super.
Najčastejšia odpoveď je niekde uprostred. Ak je projekt veľký, často sa dostanete do situácie, že žiadne riešenie nie je vhodné a nie všetko funguje, takže skončíte so zmesou. Na tom nie je nič zlé, pokiaľ chápete, že oboje má výhody.
Ak sa niečo zmenilo v zásobníku VPC a chceli ste tieto zmeny použiť na EC2, t. j. chceli ste aktualizovať skupinu automatického škálovania, pretože ste mali novú podsieť, potom tento druh orchestrácie závislostí nazývam. Existuje niekoľko riešení: kto čo používa?
Môžem navrhnúť, aké riešenia existujú. Na kúzlo môžete použiť Terraform alebo na použitie Terraform môžete použiť makefiles. A uvidíte, či sa tam niečo zmenilo, môžete to spustiť tu.
Ako sa vám páči toto rozhodnutie? Verí niekto, že je to skvelé riešenie? Vidím úsmev, zrejme sa vkradli pochybnosti.
Samozrejme, toto doma neskúšajte. Terraform nebol nikdy navrhnutý tak, aby bol spustený z Terraformu.
Pri jednej správe mi povedali: "Nie, toto nebude fungovať." Ide o to, že by to nemalo fungovať. Hoci to vyzerá tak pôsobivo, keď môžete spustiť Terraform z Terraform a potom Terraform, nemali by ste to robiť. Terraform by mal vždy štartovať veľmi ľahko.
Ak potrebujete organizáciu hovorov, keď sa niečo zmenilo na jednom mieste, potom je tu Terragrunt.
Terragrunt je pomôcka, doplnok k Terraformu, ktorý vám umožňuje koordinovať a organizovať volania modulov infraštruktúry.
Typický konfiguračný súbor Terraform vyzerá takto.
Zadáte, ktorý konkrétny modul chcete volať.
Aké závislosti má modul?
A aké argumenty tento modul akceptuje. To je všetko, čo by ste mali vedieť o Terragrunt.
Dokumentácia existuje a na GitHub je 1 700 hviezdičiek. Ale vo väčšine prípadov je to to, čo potrebujete vedieť. A to je veľmi jednoduché implementovať vo firmách, ktoré s Terraformom len začínajú pracovať.
Takže orchestrácia je Terragrunt. Sú aj iné možnosti.
Teraz si povedzme, ako pracovať s kódom.
Ak potrebujete do kódu pridať nové funkcie, vo väčšine prípadov je to jednoduché. Píšete nový zdroj, všetko je jednoduché.
Ak máte nejaký zdroj, ktorý ste si vopred vytvorili, napríklad ste sa o Terraforme dozvedeli po otvorení účtu AWS a chcete využiť zdroje, ktoré už máte, potom by bolo vhodné rozšíriť váš modul týmto spôsobom, aby podporuje využívanie existujúcich zdrojov.
A podporilo vytváranie nových zdrojov pomocou blokového zdroja.
Na výstupe vždy vrátime ID výstupu v závislosti od toho, čo bolo použité.
Druhým veľmi podstatným problémom v Terraforme 0.11 je práca so zoznamami.
Problém je, že ak máme takýto zoznam používateľov.
A keď týchto používateľov vytvoríme pomocou blokového zdroja, všetko pôjde dobre. Prejdeme si celý zoznam a pre každý vytvoríme súbor. Všetko je v poriadku. A potom by sa mal odtiaľto odstrániť napríklad používateľ3, ktorý je v strede, potom sa znova vytvoria všetky zdroje, ktoré boli vytvorené po ňom, pretože sa zmení index.
Práca so zoznamami v stavovom prostredí. Čo je stavové prostredie? Toto je situácia, keď sa pri vytvorení tohto zdroja vytvorí nová hodnota. Napríklad prístupový kľúč AWS alebo tajný kľúč AWS, t. j. keď vytvoríme používateľa, dostaneme nový prístupový alebo tajný kľúč. A zakaždým, keď odstránime používateľa, tento používateľ bude mať nový kľúč. Ale to nie je feng shui, pretože používateľ sa s nami nebude chcieť kamarátiť, ak mu vytvoríme nového používateľa zakaždým, keď niekto opustí tím.
Toto je riešenie. Toto je kód napísaný v Jsonnete. Jsonnet je jazyk šablón od spoločnosti Google.
Tento príkaz vám umožňuje prijať túto šablónu a ako výstup vráti súbor json, ktorý je vytvorený podľa vašej šablóny.
Šablóna vyzerá takto.
Terraform vám umožňuje pracovať s HCL aj Json rovnakým spôsobom, takže ak máte schopnosť generovať Json, môžete to vložiť do Terraformu. Súbor s príponou .tf.json sa úspešne stiahne.
A potom s tým pracujeme ako obvykle: terraform init, terramorm apply. A vytvoríme dvoch používateľov.
Teraz sa nebojíme, ak niekto z tímu odíde. Len upravíme súbor json. Vasja Pupkin odišiel, Peťa Pjatochkin zostal. Petya Pyatochkin nedostane nový kľúč.
Integrácia Terraformu s inými nástrojmi nie je v skutočnosti úlohou Terraformu. Terraform bol vytvorený ako platforma na vytváranie zdrojov a to je všetko. A všetko, čo sa objaví neskôr, nie je záležitosťou Terraformu. A netreba to tam pliesť. Existuje Ansible, ktorý robí všetko, čo potrebujete.
Ale nastanú situácie, keď chceme rozšíriť Terraform a zavolať nejaký príkaz potom, čo sa niečo dokončí.
Prvý spôsob. Vytvoríme výstup, kde napíšeme tento príkaz.
A potom zavoláme tento príkaz z výstupu shell terraform a špecifikujeme hodnotu, ktorú chceme. Príkaz sa teda vykoná so všetkými nahradenými hodnotami. Je to veľmi pohodlné.
Druhý spôsob. Toto je použitie null_resource v závislosti od zmien v našej infraštruktúre. Môžeme zavolať to isté local-exe, akonáhle sa zmení ID nejakého prostriedku.
Prirodzene, na papieri je to všetko hladké, pretože Amazon, rovnako ako všetci ostatní verejní poskytovatelia, má veľa vlastných okrajových prípadov.
Najbežnejším okrajovým prípadom je, že keď si otvoríte účet AWS, záleží na tom, ktoré regióny používate; je tam táto funkcia povolená; možno ste ho otvorili po decembri 2013; možno používate predvolené nastavenie vo VPC atď. Existuje veľa obmedzení. A Amazon ich rozhádzal po celej dokumentácii.
Je pár vecí, ktorým sa odporúčam vyhnúť.
Ak chcete začať, vyhnite sa všetkým neutajeným argumentom v pláne Terraform alebo CLI Terraform. To všetko je možné vložiť do súboru tfvars alebo do premennej prostredia.
Ale nemusíte si zapamätať celý tento magický príkaz. Teraformný plán – var a ideme. Prvá premenná je var, druhá premenná je var, tretia, štvrtá. Najdôležitejším princípom infraštruktúry ako kódu, ktorý používam najčastejšie, je, že už pri pohľade na kód by som mal jasne pochopiť, čo je tam nasadené, v akom stave a s akými hodnotami. A tak nemusím čítať dokumentáciu ani sa pýtať Vasyu, aké parametre použil na vytvorenie nášho klastra. Stačí mi otvoriť súbor s príponou tfvars, ktorý často zodpovedá prostrediu a pozrieť si tam všetko.
Taktiež nepoužívajte cieľové argumenty na zmenšenie rozsahu. Na tento účel je oveľa jednoduchšie použiť malé moduly infraštruktúry.
Taktiež nie je potrebné obmedzovať a zvyšovať paralelizmus. Ak mám 150 zdrojov a chcem zvýšiť paralelizmus Amazonu z predvolených 10 na 100, s najväčšou pravdepodobnosťou sa niečo pokazí. Alebo to teraz môže ísť dobre, ale keď Amazon povie, že robíte príliš veľa hovorov, budete mať problémy.
Terraform sa väčšinu týchto problémov pokúsi reštartovať, no nedosiahnete takmer nič. Parallelizmus=1 je dôležitá vec, ktorú treba použiť, ak narazíte na nejakú chybu v AWS API alebo vo vnútri poskytovateľa Terraform. Potom musíte zadať: paralelizmus=1 a počkať, kým Terraform dokončí jedno volanie, potom druhé a potom tretie. Spustí ich jeden po druhom.
Ľudia sa ma často pýtajú: „Prečo si myslím, že pracovné priestory Terraform sú zlé? Verím, že princípom infraštruktúry ako kódu je vidieť, aká infraštruktúra bola vytvorená a s akými hodnotami.
Pracovné priestory neboli vytvorené používateľmi. To neznamená, že používatelia napísali v problémoch GitHub, že nemôžeme žiť bez pracovných priestorov Terraform. Nie takto nie. Terraform Enterprise je komerčné riešenie. Terraform od HashiCorp sa rozhodol, že potrebujeme pracovné priestory, a tak sme to zaradili. Zdá sa mi oveľa jednoduchšie dať to do samostatného priečinka. Potom tam bude trochu viac súborov, ale bude to prehľadnejšie.
Ako pracovať s kódom? V skutočnosti je jedinou bolesťou práca so zoznamami. A vezmite si Terraform jednoduchšie. Toto nie je vec, ktorá vám urobí všetko skvelé. Netreba tam pchať všetko, čo je napísané v dokumentácii.
Téma správy bola napísaná „pre budúcnosť“. Poviem o tom veľmi krátko. Pre budúcnosť to znamená, že čoskoro vyjde 0.12.
0.12 je kopa nových vecí. Ak pochádzate z bežného programovania, tak vám chýbajú najrôznejšie dynamické bloky, cykly, správne a podmienené porovnávacie operácie, kde sa ľavá a pravá strana nepočítajú súčasne, ale v závislosti od situácie. Veľmi ti chýba, tak 0.12 to vyrieši za teba.
Ale! Ak píšete čoraz jednoduchšie, používate hotové moduly a riešenia tretích strán, nebudete musieť čakať a dúfať, že príde 0.12 a všetko za vás opraví.
Ďakujeme za správu! Hovorili ste o infraštruktúre ako o kóde a doslova ste povedali jedno slovo o testoch. Sú potrebné testy v moduloch? Čia je to zodpovednosť? Musím to napísať sám alebo je to zodpovednosť modulov?
Ďalší ročník bude nabitý správami, že sme sa rozhodli všetko otestovať. Čo testovať je najväčšia otázka. Existuje veľa závislostí, veľa obmedzení od rôznych poskytovateľov. Keď sa vy a ja rozprávame a vy poviete: „Potrebujem testy,“ potom sa pýtam: „Čo budete testovať? Hovoríte, že budete testovať vo svojom regióne. Potom hovorím, že toto v mojom regióne nefunguje. To znamená, že sa na tom ani nezhodneme. Nehovoriac o tom, že je tu množstvo technických problémov. Teda ako napísať tieto testy tak, aby boli adekvátne.
Aktívne skúmam túto tému, teda ako automaticky generovať testy na základe infraštruktúry, ktorú ste napísali. To znamená, že ak ste napísali tento kód, potom ho musím spustiť, na základe toho môžem vytvárať testy.
je jednou z najčastejšie spomínaných knižníc, ktorá umožňuje písať integračné testy pre Terraform. Toto je jedna z komunálnych služieb. Preferujem typ DSL, napríklad rspec.
Anton, vďaka za správu! Volám sa Valery. Dovoľte mi položiť malú filozofickú otázku. Podmienečne existuje poskytovanie, existuje nasadenie. Provisioning vytvára moju infraštruktúru, pri nasadzovaní ju napĺňame niečím užitočným, napríklad servermi, aplikáciami atď. A v mojej hlave je, že Terraform je skôr na poskytovanie a Ansible je skôr na nasadzovanie, pretože Ansible je aj na fyzickú infraštruktúru umožňuje nainštalovať nginx, Postgres. Zároveň sa však zdá, že Ansible umožňuje poskytovanie napríklad zdrojov Amazonu alebo Google. Ale Terraform vám tiež umožňuje nasadiť nejaký softvér pomocou jeho modulov. Existuje z vášho pohľadu nejaká hranica, ktorá vedie medzi Terraform a Ansible, kde a čo je lepšie použiť? Alebo si napríklad myslíte, že Ansible je už odpad, mali by ste skúsiť použiť Terraform na všetko?
Dobrá otázka, Valery. Verím, že Terraform sa od roku 2014 z hľadiska účelu nezmenil. Bol vytvorený pre infraštruktúru a zomrel pre infraštruktúru. Stále sme mali a budeme potrebovať konfiguračný manažment Ansible. Problémom je, že v rámci launch_configuration sú používateľské dáta. A tam vytiahnete Ansible, atď. Toto je štandardné rozlíšenie, ktoré mám najradšej.
Ak hovoríme o krásnej infraštruktúre, potom existujú nástroje ako Packer, ktoré zhromažďujú tento obrázok. A potom Terraform použije zdroj údajov na nájdenie tohto obrazu a aktualizáciu jeho launch_configuration. To znamená, že týmto spôsobom sa postupuje tak, že najprv vytiahneme Tracker a potom Terraform. A ak dôjde k zostaveniu, dôjde k novej zmene.
Ahoj! Ďakujeme za správu! Volám sa Misha, spoločnosť RBS. Pri vytváraní zdroja môžete zavolať Ansible cez Provider. Ansible má tiež tému s názvom dynamický inventár. A môžete najprv zavolať Terraform a potom zavolať Ansible, ktorá vezme zdroje od štátu a vykoná to. čo je lepšie?
Ľudia používajú oboje s rovnakým úspechom. Zdá sa mi, že dynamický inventár v Ansible je výhodná vec, ak nehovoríme o skupine automatického škálovania. Pretože v skupine autoscaling už máme vlastný toolkit, ktorý sa volá launch_configuration. V launch_configuration zaznamenávame všetko, čo je potrebné spustiť, keď vytvoríme nový zdroj. Preto je v prípade Amazonu používanie dynamického inventára a čítanie súboru Terraform ts podľa môjho názoru prehnané. A ak používate iné nástroje, kde neexistuje koncept „skupiny automatického škálovania“, napríklad používate DigitalOcean alebo iného poskytovateľa, kde neexistuje skupina automatického škálovania, potom tam budete musieť manuálne stiahnuť rozhranie API, nájsť adresy IP, vytvoriť súbor dynamického inventára a Ansible ním už bude blúdiť. To znamená, že pre Amazon existuje launch_configuration a pre všetko ostatné je dynamický inventár.
Zdroj: hab.com