Mnoho lidí zná a používá Terraform ve své každodenní práci, ale osvědčené postupy pro něj ještě nebyly vytvořeny. Každý tým si musí vymyslet vlastní přístupy a metody.
Vaše infrastruktura téměř jistě začíná jednoduše: pár zdrojů + pár vývojářů. Postupem času se rozrůstá všemi možnými směry. Najdete způsoby, jak seskupit zdroje do modulů Terraform, uspořádat kód do složek a co dalšího se může pokazit? (slavná poslední slova)
Čas plyne a vy máte pocit, že vaše infrastruktura je vaším novým mazlíčkem, ale proč? Máte obavy z nevysvětlitelných změn v infrastruktuře, bojíte se na infrastrukturu a kód sáhnout - v důsledku toho oddalujete novou funkcionalitu nebo snižujete kvalitu...
Po třech letech správy kolekce komunitních modulů Terraform pro AWS na Githubu a dlouhodobé údržbě Terraformu ve výrobě je Anton Babenko připraven podělit se o své zkušenosti: jak napsat moduly TF, aby to v budoucnu nebolelo.
Na konci přednášky budou účastníci blíže obeznámeni s principy řízení zdrojů v Terraformu, osvědčenými postupy spojenými s moduly v Terraformu a některými principy průběžné integrace souvisejícími se správou infrastruktury.
Disclaimer: Podotýkám, že tato zpráva je z listopadu 2018 — již uplynuly 2 roky. Verze Terraform 0.11 popsaná ve zprávě již není podporována. Za poslední 2 roky vyšly 2 nové verze, které obsahují spoustu inovací, vylepšení a změn. Věnujte tomu prosím pozornost a zkontrolujte dokumentaci.
Odkazy:
- +
- — kód a dokumentace automatického formátování
- — generátor modulů Terraform (WIP)
- — Generátor kódu Terraform z vizuálních diagramů (WIP)
- www.terraform-best-practices.com
- (Nové příspěvky jsou na mých osobních stránkách www.antonbabenko.com/)
- @antonbabenko - Twitter a spousta různých Slacků
Jmenuji se Anton Babenko. Někteří z vás pravděpodobně použili kód, který jsem napsal. Nyní o tom budu mluvit s větší jistotou než kdy jindy, protože mám přístup ke statistikám.
Pracuji na Terraformu a od roku 2015 jsem aktivním účastníkem a přispěvatelem velkého počtu open source projektů souvisejících s Terraformem a Amazonem.
Od té doby jsem napsal dost kódu, abych to dal zajímavým způsobem. A o tom se vám teď pokusím vyprávět.
Budu mluvit o spletitosti a specifikách práce s Terraformem. Ale to ve skutečnosti není předmětem HighLoad. A teď pochopíte proč.
Postupem času jsem začal psát moduly Terraform. Uživatelé psali dotazy, já je přepisoval. Pak jsem napsal různé nástroje pro formátování kódu pomocí háčku před potvrzením atd.
Vzniklo mnoho zajímavých projektů. Mám rád generování kódu, protože mám rád, když počítač dělá stále více práce za mě a programátora, takže momentálně pracuji na generátoru kódu Terraform z vizuálních diagramů. Možná je někteří z vás viděli. Jsou to krásné krabičky se šipkami. A myslím, že je skvělé, když můžete kliknout na tlačítko „Exportovat“ a získat vše jako kód.
Jsem z Ukrajiny. V Norsku žiji mnoho let.
Také informace pro tuto zprávu byly shromážděny od lidí, kteří znají mé jméno a našli mě na sociálních sítích. Skoro pořád mám stejnou přezdívku.
Jak jsem již zmínil, jsem hlavním správcem modulů Terraform AWS, což je jedno z největších úložišť na GitHubu, kde hostujeme moduly pro nejběžnější úkoly: VPC, Autoscaling, RDS.
A to, co jste teď slyšeli, je to nejzákladnější. Pokud pochybujete, že rozumíte tomu, co je Terraform, pak je lepší trávit čas někde jinde. Odborných výrazů zde bude spousta. A neváhal jsem prohlásit úroveň zprávy za nejvyšší. To znamená, že mohu mluvit všemi možnými termíny bez velkého vysvětlování.
Terraform se objevil v roce 2014 jako nástroj, který vám umožnil psát, plánovat a spravovat infrastrukturu jako kód. Klíčovým konceptem je zde „infrastruktura jako kód“.
Veškerá dokumentace, jak jsem řekl, je zapsána . Doufám, že většina lidí o tomto webu ví a přečetla si dokumentaci. Pokud ano, pak jste na správném místě.
Takto vypadá běžný konfigurační soubor Terraform, kde nejprve definujeme nějaké proměnné.
V tomto případě definujeme "aws_region".
Poté popíšeme, jaké zdroje chceme vytvořit.
Spouštíme některé příkazy, zejména „terraform init“, abychom nahráli závislosti a poskytovatele.
A spustíme příkaz „terraform apply“, abychom zkontrolovali, zda zadaná konfigurace odpovídá zdrojům, které jsme vytvořili. Protože jsme dosud nic nevytvořili, Terraform nás vyzve k vytvoření těchto zdrojů.
Toto potvrzujeme. Tak vytvoříme kbelík zvaný mořský šnek.
Existuje také několik podobných nástrojů. Mnoho z vás, kteří používáte Amazon, zná AWS CloudFormation nebo Google Cloud Deployment Manager nebo Azure Resource Manager. Každý z nich má svou vlastní implementaci určitého druhu pro správu zdrojů v rámci každého z těchto poskytovatelů veřejného cloudu. Terraform je zvláště užitečný, protože vám umožňuje spravovat více než 100 poskytovatelů. (Více informací )
Cíle, které Terraform sledoval od samého začátku:
- Terraform poskytuje jediný pohled na zdroje.
- Umožňuje vám podporovat všechny moderní platformy.
- A Terraform byl od samého začátku navržen jako nástroj, který vám umožní bezpečně a předvídatelně měnit infrastrukturu.
V roce 2014 znělo slovo „předvídatelný“ v této souvislosti velmi neobvykle.
Terraform je univerzální nástroj. Pokud máte API, můžete ovládat naprosto vše:
- Ke správě všeho, co chcete, můžete využít více než 120 poskytovatelů.
- Terraform můžete použít například k popisu přístupu k úložištím GitHub.
- V Jira můžete dokonce vytvářet a zavírat chyby.
- Můžete spravovat metriky New Relic.
- Pokud opravdu chcete, můžete dokonce vytvářet soubory ve schránce.
Toho všeho je dosaženo pomocí poskytovatelů Terraform, kteří mají otevřené API, které lze popsat v Go.
Řekněme, že jsme začali používat Terraform, přečetli jsme si nějakou dokumentaci na webu, zhlédli nějaké video a začali psát main.tf, jak jsem ukázal na předchozích snímcích.
A vše je skvělé, máte soubor, který vytváří VPC.
Pokud chcete vytvořit VPC, pak určíte přibližně těchto 12 řádků. Popište, ve které oblasti chcete vytvořit, který cidr_block IP adres použít. To je vše.
Projekt se samozřejmě bude postupně rozrůstat.
A budete tam přidávat spoustu nových věcí: zdroje, zdroje dat, integrujete se s novými poskytovateli, najednou budete chtít používat Terraform ke správě uživatelů ve svém účtu GitHub atd. Možná budete chtít používat různé Poskytovatelé DNS, křížte vše. Terraform to usnadňuje.
Podívejme se na následující příklad.
Postupně přidáváte internet_gateway, protože chcete, aby zdroje z vašeho VPC měly přístup k internetu. To je dobrý nápad.
Výsledkem je tento main.tf:
Toto je horní část main.tf.
Toto je spodní část main.tf.
Poté přidáte podsíť. V době, kdy budete chtít přidat brány NAT, trasy, směrovací tabulky a spoustu dalších podsítí, nebudete mít 38 linek, ale přibližně 200-300 linek.
To znamená, že váš soubor main.tf postupně roste. A dost často lidé dávají vše do jednoho souboru. 10-20 Kb se objeví v main.tf. Představte si, že 10-20 Kb je textový obsah. A všechno souvisí se vším. S tím je postupně práce obtížnější. 10-20 Kb je dobrý uživatelský případ, někdy i více. A lidé si ne vždy myslí, že je to špatné.
Stejně jako v běžném programování, tedy ne infrastruktura jako kód, jsme zvyklí používat spoustu různých tříd, balíčků, modulů, seskupení. Terraform vám umožňuje dělat téměř totéž.
- Kód roste.
- Rostou také závislosti mezi zdroji.
A máme velkou, velkou potřebu. Chápeme, že takhle už dál žít nemůžeme. Náš kód se stává obrovským. 10-20 Kb samozřejmě není příliš velké, ale mluvíme pouze o síťovém zásobníku, tj. pouze jste přidali síťové zdroje. Nebavíme se o Application Load Balancer, nasazení ES clusteru, Kubernetes atd., kam se dá snadno vplést 100 Kb. Pokud si toto vše zapíšete, velmi brzy zjistíte, že Terraform poskytuje moduly Terraform.
Moduly Terraform jsou samostatná konfigurace Terraform, která je spravována jako skupina. To je vše, co potřebujete vědět o modulech Terraform. Nejsou vůbec chytré, neumožňují dělat nějaká složitá spojení v závislosti na něčem. To vše leží na bedrech vývojářů. To znamená, že toto je jen nějaká konfigurace Terraform, kterou jste již napsali. A můžete to jednoduše nazvat jako skupina.
Snažíme se tedy pochopit, jak optimalizujeme našich 10-20-30 Kb kódu. Postupně zjišťujeme, že některé moduly musíme využívat.
První typ modulů, se kterými se setkáte, jsou zdrojové moduly. Nechápou, o čem je vaše infrastruktura, o čem je vaše podnikání, kde a jaké jsou podmínky. To jsou přesně moduly, které spolu s open source komunitou spravuji a které předkládáme jako úplně počáteční stavební kameny vaší infrastruktury.
Příklad modulu zdrojů.
Když voláme zdrojový modul, určíme, ze které cesty máme načíst jeho obsah.
Označíme verzi, kterou chceme stáhnout.
Předáváme tam spoustu argumentů. To je vše. To je vše, co potřebujeme vědět, když tento modul používáme.
Mnoho lidí si myslí, že pokud budou používat nejnovější verzi, bude vše stabilní. Ale ne. Infrastruktura musí být verzovaná, musíme jasně odpovědět, na jakou verzi byla ta či ona komponenta nasazena.
Zde je kód, který je uvnitř tohoto modulu. Modul bezpečnostní skupiny. Zde svitek přejde na 640. řádek. Vytváření zdroje zabezpečení v Amazonu ve všech možných konfiguracích je velmi netriviální úkol. Nestačí jednoduše vytvořit bezpečnostní skupinu a říct jí, jaká pravidla jí předat. Bylo by to velmi jednoduché. V Amazonu existuje milion různých omezení. Pokud například používáte Koncový bod VPC, seznam prefixů, různá rozhraní API a snaží se to všechno kombinovat se vším ostatním, pak vám to Terraform neumožňuje. A nedovoluje to ani Amazon API. Proto musíme všechnu tuto hroznou logiku skrýt do modulu a dát uživateli kód, který vypadá přesně takto.
Uživatel nemusí vědět, jak se uvnitř vyrábí.
Druhý typ modulů, který se skládá ze zdrojových modulů, již řeší problémy, které jsou více použitelné pro vaše podnikání. Často je to místo, které je rozšířením pro Terraform a nastavuje určité pevné hodnoty pro štítky, pro firemní standardy. Můžete tam přidat i funkce, které vám Terraform aktuálně neumožňuje. Tohle je právě teď. Nyní verze 0.11, která se brzy stane minulostí. Ale přesto jsou preprocesory, jsonnet, cookiecutter a hromada dalších věcí tím pomocným mechanismem, který je nutné použít pro plnohodnotnou práci.
Dále ukážu několik příkladů tohoto.
Modul infrastruktury se nazývá úplně stejným způsobem.
Je uveden zdroj, odkud se má obsah stáhnout.
Do tohoto modulu je předávána a předávána spousta hodnot.
Dále je v tomto modulu volána skupina modulů prostředků k vytvoření VPC nebo Application Load Balancer, nebo k vytvoření skupiny zabezpečení nebo pro cluster Elastic Container Service.
Existují dva typy modulů. To je důležité pochopit, protože většina informací, které jsem seskupil v této zprávě, není zapsána v dokumentaci.
A dokumentace v Terraformu je právě teď docela problematická, protože jen říká, že existují tyto funkce, můžete je použít. Ale neříká, jak tyto funkce používat, proč je lepší je používat. Proto velké množství lidí píše něco, s čím nemohou žít.
Podívejme se dále, jak tyto moduly napsat. Pak uvidíme, jak je volat a jak pracovat s kódem.
Terraform Registry -
Tip #0 je nezapisovat zdrojové moduly. Většina těchto modulů je již pro vás napsána. Jak jsem řekl, jsou open source, neobsahují žádnou vaši obchodní logiku, nemají pevně zakódované hodnoty IP adres, hesel atd. Modul je velmi flexibilní. A nejspíš už to bylo napsáno. Existuje mnoho modulů pro zdroje od Amazonu. Asi 650. A většina z nich je kvalitní.
V tomto příkladu za vámi někdo přišel a řekl: „Chci umět spravovat databázi. Vytvořte modul, abych mohl vytvořit databázi." Osoba nezná podrobnosti implementace Amazon ani Terraform. Jednoduše říká: "Chci spravovat MSSQL." To znamená, že to zavolá náš modul, předá tam typ motoru a uvede časové pásmo.
A člověk by neměl vědět, že uvnitř tohoto modulu vytvoříme dva různé zdroje: jeden pro MSSQL, druhý pro všechno ostatní, pouze proto, že v Terraformu 0.11 nemůžete zadat hodnoty časového pásma jako volitelné.
A na výstupu z tohoto modulu bude člověk moci jednoduše získat adresu. Nebude vědět, z jaké databáze, z jakého zdroje to vše interně vytváříme. Toto je velmi důležitý prvek skrývání. A to platí nejen pro ty moduly, které jsou v open source veřejné, ale i pro ty moduly, které budete psát uvnitř svých projektů a týmů.
Toto je druhý argument, který je docela důležitý, pokud Terraform nějakou dobu používáte. Máte úložiště, do kterého vložíte všechny své moduly Terraform pro vaši společnost. A je zcela normální, že se tento projekt časem rozroste do velikosti jednoho až dvou megabajtů. Tohle je fajn.
Problém je ale v tom, jak Terraform tyto moduly nazývá. Pokud například zavoláte modul pro vytvoření každého jednotlivého uživatele, Terraform nejprve načte celé úložiště a poté přejde do složky, kde se tento konkrétní modul nachází. Tímto způsobem stáhnete pokaždé jeden megabajt. Pokud spravujete 100 nebo 200 uživatelů, stáhnete 100 nebo 200 megabajtů a poté přejdete do této složky. Takže přirozeně nechcete stahovat spoustu věcí pokaždé, když stisknete "Terraform init".
Existují dvě řešení tohoto problému. První je použití relativních cest. Tímto způsobem v kódu označíte, že složka je místní (./). A než něco spustíte, lokálně vytvoříte klon Git tohoto úložiště. Tímto způsobem to uděláte jednou.
Existuje samozřejmě spousta nevýhod. Nemůžete například používat verzování. A s tím je někdy těžké žít.
Druhé řešení. Pokud máte hodně submodulů a už máte nějaký zavedený pipeline, pak je tu projekt MBT, který vám umožní shromáždit mnoho různých balíčků z monorepozitáře a nahrát je do S3. To je velmi dobrý způsob. Soubor iam-user-1.0.0.zip bude tedy vážit pouze 1 Kb, protože kód pro vytvoření tohoto zdroje je velmi malý. A bude to fungovat mnohem rychleji.
Pojďme se bavit o tom, co nelze v modulech použít.
Proč je to zlo v modulech? Nejhorší je předpokládat uživatele. Předpokládejme, že uživatel je možnost ověření poskytovatele, kterou mohou používat různí lidé. Například všichni asimilujeme roli. To znamená, že Terraform převezme tuto roli. A pak s touto rolí bude provádět další akce.
A zlo je v tom, že pokud se Vasya rád připojuje k Amazonu jedním způsobem, například pomocí výchozí proměnné prostředí, a Péťa rád používá svůj sdílený klíč, který má na tajném místě, pak nemůžete v Terraform. A aby neprožívali utrpení, není potřeba tento blok v modulu označovat. To musí být uvedeno na vyšší úrovni. To znamená, že navrch máme modul zdrojů, modul infrastruktury a složení. A to by mělo být uvedeno někde výše.
Druhé zlo je proviant. Tady to zlo není tak triviální, protože když píšete kód a funguje vám to, pak si možná myslíte, že když to funguje, tak proč to měnit.
Zlo je, že ne vždy kontrolujete, kdy bude tento poskytovatel spuštěn. A za druhé, nemáte kontrolu nad tím, co znamená aws ec2, tj. teď mluvíme o Linuxu nebo Windows. Nemůžete tedy napsat něco, co bude fungovat stejně na různých operačních systémech nebo pro různé uživatelské případy.
Nejběžnějším příkladem, který je také uveden v oficiální dokumentaci, je, že když napíšete aws_instance a zadáte spoustu argumentů, pak na tom není nic špatného, když tam zadáte provizor „local-exec“ a spustíte svůj ansible- playbook .
Ve skutečnosti ano, není na tom nic špatného. Ale doslova brzy si uvědomíte, že tato věc local-exec neexistuje, například v launch_configuration.
A když používáte launch_configuration a chcete vytvořit skupinu automatického škálování z jedné instance, pak v launch_configuration neexistuje žádný koncept „provisioner“. Existuje pojem „uživatelská data“.
Proto je univerzálnějším řešením použití uživatelských dat. A bude spuštěn buď na samotné instanci, když je instance zapnutá, nebo ve stejných uživatelských datech, když skupina pro automatické škálování používá tuto konfiguraci launch_configuration.
Pokud přesto chcete zprovozňovač spustit, protože se jedná o lepící komponentu, když je vytvořen jeden prostředek, v tu chvíli je potřeba spustit váš provizor, váš příkaz. Takových situací je spousta.
A nejsprávnější zdroj pro toto se nazývá null_resource. Null_resource je fiktivní prostředek, který se ve skutečnosti nikdy nevytvoří. Nic se nedotýká, žádné API, žádné automatické škálování. Ale umožňuje vám ovládat, kdy spustit příkaz. V tomto případě je příkaz spuštěn během vytváření.
Odkaz
Existuje několik znaků. Nebudu se podrobně zabývat všemi znameními. Je o tom článek. Ale pokud jste pracovali s Terraformem nebo používali moduly jiných lidí, pak jste si často všimli, že mnoho modulů, stejně jako většina kódu v open source, je napsáno lidmi pro jejich vlastní potřeby. Napsal to muž a vyřešil svůj problém. Strčil jsem to do GitHubu, nech to žít. Bude žít, ale pokud tam nebude dokumentace a příklady, tak to nikdo nepoužije. A pokud neexistuje žádná funkce, která by vám umožnila vyřešit trochu víc, než je její konkrétní úkol, nikdo ji také nepoužije. Existuje mnoho způsobů, jak ztratit uživatele.
Pokud chcete něco napsat, aby to lidé používali, pak doporučuji řídit se těmito znaky.
Jsou to:
- Dokumentace a příklady.
- Plná funkčnost.
- Rozumné výchozí hodnoty.
- Čistý kód.
- Testy.
Testy jsou jiná situace, protože se píší docela obtížně. Věřím spíše dokumentaci a příkladům.
Takže jsme se podívali na to, jak psát moduly. Existují dva argumenty. První, která je nejdůležitější, je nepsat, pokud můžete, protože tyto úkoly už před vámi udělala parta lidí. A za druhé, pokud se přesto rozhodnete, zkuste poskytovatele v modulech a provizorech nepoužívat.
Toto je šedá část dokumentace. Možná si teď říkáte: „Něco není jasné. Nepřesvědčený." Ale uvidíme za šest měsíců.
Nyní si povíme, jak tyto moduly nazývat.
Chápeme, že náš kód se postupem času rozrůstá. Již nemáme jeden soubor, máme již 20 souborů. Všechny jsou v jedné složce. Nebo možná v pěti složkách. Možná je začínáme nějak rozdělovat podle regionů, podle nějakých složek. Pak pochopíme, že nyní máme nějaké základy synchronizace a orchestrace. To znamená, že musíme pochopit, co bychom měli dělat, pokud jsme změnili síťové zdroje, co bychom měli dělat se zbytkem našich zdrojů, jak tyto závislosti způsobit atd.
Existují dva extrémy. První extrém je vše v jednom. Máme jeden hlavní soubor. Prozatím to byla oficiální nejlepší praxe na webu Terraform.
Nyní je však napsán jako zastaralý a odstraněný. Postupem času si komunita Terraform uvědomila, že to zdaleka není nejlepší postup, protože lidé začali projekt využívat různými způsoby. A jsou tu problémy. Například když vypíšeme všechny závislosti na jednom místě. Jsou situace, kdy klikneme na „Plán Terraform“ a dokud Terraform neaktualizuje stavy všech zdrojů, může uplynout spousta času.
Spousta času je například 5 minut. Pro některé je to hodně času. Viděl jsem případy, kdy to trvalo 15 minut. AWS API se 15 minut snažilo zjistit, co se děje se stavem každého zdroje. Jedná se o velmi rozsáhlou oblast.
A přirozeně se objeví související problém, když budete chtít něco změnit na jednom místě, pak počkáte 15 minut, a to vám dá plátno nějakých změn. Plivli jste, napsali „Ano“ a něco se pokazilo. Toto je velmi reálný příklad. Terraform se vás nesnaží chránit před problémy. To znamená, pište, co chcete. Budou problémy – vaše problémy. Zatímco Terraform 0.11 se vám nesnaží nijak pomoci. V 0.12 jsou určitá zajímavá místa, která vám umožňují říci: „Vasya, tohle opravdu chceš, můžeš přijít k rozumu?“
Druhým způsobem je zmenšení této oblasti, to znamená, že hovory z jednoho místa mohou být méně spojovány z jiného místa.
Jediný problém je, že musíte napsat více kódu, tj. musíte popsat proměnné ve velkém počtu souborů a aktualizovat to. Někomu se to nelíbí. To je pro mě normální. A někteří lidé si myslí: "Proč to psát na různá místa, dám to všechno na jedno místo." To je možné, ale to je druhý extrém.
Kdo to všechno žije na jednom místě? Jeden, dva, tři lidé, tedy někdo to používá.
A kdo volá jednu konkrétní komponentu, jeden blok nebo jeden modul infrastruktury? Pět až sedm lidí. To je hustý.
Nejčastější odpověď je někde uprostřed. Pokud je projekt velký, pak se často dostanete do situace, kdy žádné řešení není vhodné a ne všechno funguje, takže skončíte se směsí. Na tom není nic špatného, pokud chápete, že obojí má výhody.
Pokud se něco změnilo v zásobníku VPC a chtěli jste tyto změny aplikovat na EC2, tj. chtěli jste aktualizovat skupinu automatického škálování, protože jste měli novou podsíť, pak tento druh orchestrace závislostí nazývám. Existuje několik řešení: kdo co používá?
Mohu navrhnout, jaká řešení existují. K kouzlení můžete použít Terraform nebo k použití Terraformu můžete použít makefiles. A podívejte se, jestli se tam něco změnilo, můžete to spustit zde.
Jak se vám toto rozhodnutí líbí? Věří někdo, že je to skvělé řešení? Vidím úsměv, zřejmě se vloudily pochybnosti.
Doma to samozřejmě nezkoušejte. Terraform nebyl nikdy navržen tak, aby byl spuštěn z Terraformu.
V jedné zprávě mi řekli: "Ne, to nebude fungovat." Jde o to, že by to nemělo fungovat. Ačkoli to vypadá tak působivě, když můžete spustit Terraform z Terraformu a poté Terraform, neměli byste to dělat. Terraform by měl vždy startovat velmi snadno.
Pokud potřebujete orchestraci volání, když se na jednom místě něco změnilo, pak je tu Terragrunt.
Terragrunt je nástroj, doplněk k Terraformu, který vám umožňuje koordinovat a organizovat volání modulů infrastruktury.
Typický konfigurační soubor Terraform vypadá takto.
Určíte, který konkrétní modul chcete volat.
Jaké závislosti má modul?
A jaké argumenty tento modul přijímá. To je vše, co je třeba o Terragruntu vědět.
Dokumentace existuje a na GitHubu je 1 700 hvězdiček. Ale ve většině případů je to to, co potřebujete vědět. A to je velmi snadné implementovat ve firmách, které s Terraformem teprve začínají.
Takže orchestrace je Terragrunt. Jsou i jiné možnosti.
Nyní si povíme, jak s kódem pracovat.
Pokud potřebujete do kódu přidat nové funkce, je to ve většině případů snadné. Píšete nový zdroj, vše je jednoduché.
Pokud máte nějaký zdroj, který jste si předem vytvořili, například jste se o Terraformu dozvěděli po otevření účtu AWS a chcete využívat zdroje, které již máte, pak by bylo vhodné svůj modul tímto způsobem rozšířit, abyste podporuje využití stávajících zdrojů.
A podporoval vytváření nových zdrojů pomocí blokového zdroje.
Na výstupu vždy vracíme ID výstupu v závislosti na tom, co bylo použito.
Druhým velmi podstatným problémem v Terraformu 0.11 je práce se seznamy.
Potíž je v tom, že pokud máme takový seznam uživatelů.
A když tyto uživatele vytvoříme pomocí blokového zdroje, vše půjde dobře. Procházíme celý seznam a pro každý vytvoříme soubor. Vše je v pořádku. A pak by se odsud měl odstranit například uživatel3, který je uprostřed, pak se znovu vytvoří všechny zdroje, které byly vytvořeny po něm, protože se změní index.
Práce se seznamy ve stavovém prostředí. Co je stavové prostředí? Toto je situace, kdy se při vytvoření tohoto zdroje vytvoří nová hodnota. Například přístupový klíč AWS nebo tajný klíč AWS, tj. když vytvoříme uživatele, obdržíme nový přístupový nebo tajný klíč. A pokaždé, když smažeme uživatele, bude mít tento uživatel nový klíč. To ale není feng shui, protože uživatel se s námi nebude chtít kamarádit, když mu vytvoříme nového uživatele pokaždé, když někdo opustí tým.
Toto je řešení. Toto je kód napsaný v Jsonnet. Jsonnet je šablonovací jazyk od společnosti Google.
Tento příkaz vám umožní přijmout tuto šablonu a jako výstup vrátí soubor json, který je vytvořen podle vaší šablony.
Šablona vypadá takto.
Terraform vám umožňuje pracovat s HCL i Json stejným způsobem, takže pokud máte schopnost generovat Json, můžete to vklouznout do Terraformu. Soubor s příponou .tf.json bude úspěšně stažen.
A pak s tím pracujeme jako obvykle: terraform init, terramorm platí. A vytvoříme dva uživatele.
Teď se nebojíme, jestli někdo z týmu odejde. Pouze upravíme soubor json. Vasja Pupkin odešel, Péťa Pjatočkin zůstal. Péťa Pjatočkin nový klíč nedostane.
Integrace Terraformu s jinými nástroji není ve skutečnosti úkolem Terraformu. Terraform byl vytvořen jako platforma pro vytváření zdrojů a to je vše. A všechno, co se objeví později, není starostí Terraformu. A není potřeba to tam plést. Existuje Ansible, který dělá vše, co potřebujete.
Ale nastávají situace, kdy chceme rozšířit Terraform a zavolat nějaký příkaz poté, co se něco dokončí.
První způsob. Vytvoříme výstup, kam zapíšeme tento příkaz.
A pak zavoláme tento příkaz z výstupu shell terraform a určíme hodnotu, kterou chceme. Příkaz se tedy provede se všemi nahrazenými hodnotami. Je to velmi pohodlné.
Druhý způsob. Toto je použití null_resource v závislosti na změnách v naší infrastruktuře. Můžeme volat stejné local-exe, jakmile se změní ID nějakého prostředku.
Na papíře je to samozřejmě vše hladké, protože Amazon, stejně jako všichni ostatní veřejní poskytovatelé, má spoustu vlastních okrajových případů.
Nejběžnější okrajový případ je, že když si otevřete účet AWS, záleží na tom, které regiony používáte; je tam tato funkce povolena; možná jste ji otevřeli po prosinci 2013; možná používáte výchozí ve VPC atd. Existuje mnoho omezení. A Amazon je rozházel po celé dokumentaci.
Je pár věcí, kterým doporučuji se vyhnout.
Chcete-li začít, vyhněte se všem neutajeným argumentům v plánu Terraform nebo Terraform CLI. To vše lze vložit buď do souboru tfvars nebo do proměnné prostředí.
Ale nemusíte se učit nazpaměť celý tento magický příkaz. Plán Terraform – var a jedeme. První proměnná je var, druhá proměnná je var, třetí, čtvrtá. Nejdůležitější princip infrastruktury jako kódu, který používám nejčastěji, je ten, že pouhým pohledem na kód bych měl jasně pochopit, co je tam nasazeno, v jakém stavu a s jakými hodnotami. A tak nemusím číst dokumentaci ani se ptát Vasyi, jaké parametry použil k vytvoření našeho clusteru. Stačí mi otevřít soubor s příponou tfvars, který často odpovídá prostředí, a tam se na vše podívat.
Také nepoužívejte cílové argumenty ke snížení rozsahu. K tomu je mnohem jednodušší použít malé moduly infrastruktury.
Také není potřeba omezovat a zvyšovat paralelismus. Pokud mám 150 zdrojů a chci zvýšit paralelismus Amazonu z výchozích 10 na 100, pak se s největší pravděpodobností něco pokazí. Nebo to teď může jít dobře, ale když Amazon řekne, že voláte příliš mnoho, budete mít potíže.
Terraform se pokusí většinu těchto problémů restartovat, ale nedosáhnete téměř ničeho. Parallelism=1 je důležitá věc, kterou je třeba použít, pokud narazíte na nějakou chybu uvnitř AWS API nebo uvnitř poskytovatele Terraform. A pak musíte zadat: parallelism=1 a počkat, až Terraform dokončí jedno volání, pak druhé a pak třetí. Spustí je jednoho po druhém.
Lidé se mě často ptají: "Proč si myslím, že jsou pracovní prostory Terraform zlé?" Věřím, že principem infrastruktury jako kódu je vidět, jaká infrastruktura byla vytvořena as jakými hodnotami.
Pracovní prostory nevytvářeli uživatelé. To neznamená, že uživatelé napsali do problémů GitHubu, že nemůžeme žít bez pracovních prostorů Terraform. Ne takhle ne. Terraform Enterprise je komerční řešení. Terraform od HashiCorp se rozhodl, že potřebujeme pracovní prostory, a tak jsme to zařadili. Připadá mi mnohem jednodušší dát to do samostatné složky. Pak tam bude trochu více souborů, ale bude to přehlednější.
Jak pracovat s kódem? Ve skutečnosti je práce se seznamy jedinou bolestí. A vezměte Terraform snadněji. Tohle není věc, která za vás udělá všechno skvěle. Není potřeba tam strkat vše, co je napsáno v dokumentaci.
Téma zprávy bylo napsáno „pro budoucnost“. Budu o tom mluvit velmi krátce. Pro budoucnost to znamená, že brzy vyjde 0.12.
0.12 je spousta nových věcí. Pokud pocházíte z běžného programování, pak vám chybí nejrůznější dynamické bloky, smyčky, správné a podmíněné srovnávací operace, kde se levá a pravá strana nepočítá současně, ale podle situace. Hodně ti to chybí, takže 0.12 to vyřeší za tebe.
Ale! Pokud budete psát méně a jednodušeji, s využitím hotových modulů a řešení třetích stran, pak nebudete muset čekat a doufat, že přijde 0.12 a vše za vás opraví.
Díky za zprávu! Mluvil jste o infrastruktuře jako o kódu a doslova jste řekl jedno slovo o testech. Jsou nutné testy v modulech? Čí je to odpovědnost? Musím to napsat sám nebo je to odpovědnost modulů?
Příští rok bude naplněn zprávami, že jsme se rozhodli vše otestovat. Co testovat je největší otázka. Existuje spousta závislostí, spousta omezení od různých poskytovatelů. Když spolu mluvíme a vy řeknete: „Potřebuji testy,“ pak se zeptám: „Co budete testovat? Říkáte, že budete testovat ve svém regionu. Pak říkám, že to v mém regionu nefunguje. To znamená, že se na tom ani neshodneme. Nemluvě o tom, že je tam spousta technických problémů. Tedy jak tyto testy napsat, aby byly adekvátní.
Aktivně zkoumám toto téma, tedy jak automaticky generovat testy na základě infrastruktury, kterou jste napsali. To znamená, že pokud jste napsali tento kód, musím ho spustit, na základě toho mohu vytvářet testy.
je jednou z nejčastěji zmiňovaných knihoven, která umožňuje psát integrační testy pro Terraform. Toto je jedna z utilit. Preferuji typ DSL, například rspec.
Antone, díky za zprávu! Jmenuji se Valery. Dovolte mi malou filozofickou otázku. Podmíněně existuje zajišťování, existuje nasazení. Provisioning vytváří mou infrastrukturu, při nasazení ji naplňujeme něčím užitečným, například servery, aplikacemi atd. A v mé hlavě je, že Terraform je spíše pro poskytování a Ansible je spíše pro nasazení, protože Ansible je také pro fyzickou infrastrukturu umožňuje nainstalovat nginx, Postgres. Zároveň se ale zdá, že Ansible umožňuje zřizování například zdrojů Amazonu nebo Googlu. Terraform ale také umožňuje nasadit nějaký software pomocí svých modulů. Existuje z vašeho pohledu nějaká hranice mezi Terraformem a Ansible, kde a co je lepší použít? Nebo si například myslíte, že Ansible už je smetí, měli byste zkusit použít Terraform na všechno?
Dobrá otázka, Valery. Věřím, že se Terraform od roku 2014 z hlediska účelu nezměnil. Bylo vytvořeno pro infrastrukturu a zemřelo pro infrastrukturu. Stále jsme měli a budeme potřebovat správu konfigurace Ansible. Problém je v tom, že uvnitř launch_configuration jsou uživatelská data. A tam vytáhneš Ansible atd. To je standardní rozlišení, které mám nejraději.
Pokud mluvíme o krásné infrastruktuře, pak existují nástroje jako Packer, které shromažďují tento obrázek. A pak Terraform použije zdroj dat k nalezení tohoto obrazu a aktualizaci jeho launch_configuration. To znamená, že tímto způsobem postup spočívá v tom, že nejprve vytáhneme Tracker a poté Terraform. A pokud dojde k sestavení, dojde k nové změně.
Ahoj! Díky za zprávu! Jmenuji se Misha, společnost RBS. Při vytváření zdroje můžete volat Ansible prostřednictvím zřizovatele. Ansible má také téma zvané dynamický inventář. A můžete nejprve zavolat Terraform a pak zavolat Ansible, která vezme zdroje od státu a provede je. co je lepší?
Lidé používají obojí se stejným úspěchem. Zdá se mi, že dynamický inventář v Ansible je výhodná věc, pokud se nebavíme o autoscaling group. Protože ve skupině autoscaling již máme vlastní sadu nástrojů, která se nazývá launch_configuration. V launch_configuration zaznamenáváme vše, co je potřeba spustit, když vytváříme nový prostředek. Proto je u Amazonu používání dynamického inventáře a čtení souboru Terraform ts podle mého názoru přehnané. A pokud používáte jiné nástroje, kde neexistuje koncept „skupiny automatického škálování“, například používáte DigitalOcean nebo jiného poskytovatele, kde neexistuje skupina pro automatické škálování, pak tam budete muset ručně vytáhnout API, najít IP adresy, vytvořit dynamický soubor inventáře a Ansible se jím již bude procházet. To znamená, že pro Amazon existuje launch_configuration a pro všechno ostatní je dynamický inventář.
Zdroj: www.habr.com