Zdálo by se, že vývojáři Terraform nabízejí docela pohodlné osvědčené postupy pro práci s infrastrukturou AWS. Existuje pouze nuance. Postupem času přibývá prostředí, v každém se objevují funkce. Objeví se téměř kopie zásobníku aplikací v sousední oblasti. A kód Terraform je třeba pečlivě zkopírovat a upravit podle nových požadavků nebo vytvořit sněhovou vločku.
Moje zpráva je o vzorcích v Terraformu pro boj s chaosem a manuální rutinou na velkých a dlouhých projektech.
Video:
Je mi 40 let, v IT se pohybuji 20 let. Ve společnosti Ixtens pracuji 12 let. Zabýváme se vývojem řízeným e-commerce. A praktikám DevOps se věnuji 5 let.
Můj příběh bude o zkušenosti z projektu ve firmě, jejíž jméno neřeknu, skrývající se za mlčenlivost.
Čísla na snímku jsou uvedena pro pochopení rozsahu projektu. A vše, co dále řeknu, souvisí s Amazonem.
Do tohoto projektu jsem se zapojil před 4 lety. A refaktoring infrastruktury byl v plném proudu, protože projekt se rozrostl. A ty vzory, které byly použity, už nesedí. A vzhledem k veškerému plánovanému růstu projektu bylo nutné přijít s něčím novým.
Díky Matveymu, který nám včera řekl, co se stalo v Dodo Pizza. To se nám stalo před 4 lety.
Přišli vývojáři a začali vytvářet kód infrastruktury.
Nejviditelnějším důvodem, proč to bylo požadováno, byl čas uvedení na trh. Bylo nutné se ujistit, že tým DevOps nebyl při rozjezdu úzkým hrdlem. A mimo jiné byly hned na první úrovni použity Terraform a Puppet.
Terraform je open source projekt od HashiCorp. A pro ty, kteří vůbec nevědí, co to je, dalších pár snímků.
Infrastruktura jako kód znamená, že můžeme popsat naši infrastrukturu a požádat některé roboty, aby se ujistili, že dostaneme zdroje, které jsme popsali.
Potřebujeme například virtuální stroj. Popíšeme, doplníme pár požadovaných parametrů.
Poté nakonfigurujeme přístup k Amazonu v konzole. A požádejte o plán Terraform. Plán Terraform bude říkat: "Dobře, pro váš zdroj můžeme tyto věci udělat." A minimálně jeden zdroj bude přidán. A neočekávají se žádné změny.
Poté, co vám bude vše vyhovovat, můžete požádat Terraform aplikovat a Terraform vám vytvoří instanci a získáte virtuální stroj ve vašem cloudu.
Dále se náš projekt rozvíjí. Přidáváme tam nějaké změny. Žádáme o další instance, přidáváme 53 záznamů.
A opakujeme. Prosím plánujte. Vidíme, jaké změny se plánují. Aplikovat. A tak naše infrastruktura roste.
Terraform používá něco jako stavové soubory. To znamená, že ukládá všechny změny, které jdou do Amazonu, do souboru, kde pro každý zdroj, který jste popsali, existují odpovídající zdroje, které byly vytvořeny v Amazonu. Při změně popisu zdroje tedy Terraform přesně ví, co je třeba v Amazonu změnit.
Tyto stavové soubory byly původně pouze soubory. A uložili jsme je v Gitu, což bylo extrémně nepohodlné. Neustále někdo zapomínal provádět změny a docházelo k mnoha konfliktům.
Nyní je možné použít backend, tj. Terraform je označen, do kterého bucketu, jakým klíčem se má soubor stavu uložit. A Terraform sám se postará o získání tohoto stavového souboru, udělá všechna kouzla a vrátí konečný výsledek.
Naše infrastruktura roste. Zde je náš kód. A nyní nechceme pouze vytvořit virtuální stroj, chceme mít testovací prostředí.
Terraform vám umožňuje vytvořit něco jako modul, tedy popsat to samé v nějaké složce.
A například při testování zavolejte tento modul a získáte to samé, jako bychom prováděli aplikaci Terraform v modulu samotném. Zde je kód pro testování.
Pro produkci tam můžeme poslat nějaké změny, protože při testování nepotřebujeme velké instance, v produkci se velké instance budou hodit.
A pak se vrátím k projektu. Byl to náročný úkol, infrastruktura byla plánována velmi rozsáhle. A bylo nutné nějak umístit veškerý kód tak, aby to bylo vhodné pro všechny: pro ty, kteří na tomto kódu provádějí údržbu, i pro ty, kteří provádějí změny. A bylo plánováno, že každý vývojář může jít opravit infrastrukturu podle potřeby pro jeho část platformy.
Toto je adresářový strom, který HashiCorp doporučuje, pokud máte velký projekt a má smysl rozdělit celou infrastrukturu na několik malých částí a popsat každý kus v samostatné složce.
Máte-li rozsáhlou knihovnu zdrojů, můžete při testování a produkci volat zhruba totéž.
V našem případě to nebylo úplně vhodné, protože testovací stack pro vývojáře nebo pro testování bylo potřeba sehnat nějak jednodušeji. A nechtěl jsem procházet složky a aplikovat ve správném pořadí a obávat se, že se základna zvedne a pak se zvedne instance, která používá tuto základnu. Proto bylo veškeré testování spuštěno z jedné složky. Byly tam volány stejné moduly, ale vše prošlo na jeden běh.
Terraform se stará o všechny závislosti. A vždy vytváří zdroje v tomto pořadí, abyste mohli získat IP adresu například z čerstvě vytvořené instance a tuto IP adresu získat v položce route53.
Platforma je navíc velmi velká. A provozovat testovací zásobník, i když na hodinu, i když na 8 hodin, je docela drahá záležitost.
A tento obchod jsme zautomatizovali. A Jenkinsova úloha umožnila běh zásobníku. Bylo nutné v něm spustit pull request se změnami, které chce vývojář otestovat, specifikovat všechny potřebné možnosti, komponenty, velikosti. Pokud chce testování výkonu, může provést více instancí. Pokud si potřebuje jen zkontrolovat, že se otevírá nějaký formulář, mohl by začít na minimální mzdě. A také uveďte, zda je klastr potřeba nebo ne atd.
A pak Jenkins vložil shellový skript, který mírně upravil kód ve složce Terraform. Odstraněny nepotřebné soubory, přidány potřebné soubory. A pak, s jedním spuštěním Terraformu, stack stoupl.
A pak byly další kroky, do kterých nechci jít.
Vzhledem k tomu, že pro testování jsme potřebovali trochu více možností než ve výrobě, museli jsme udělat kopie modulů, abychom do těchto kopií mohli přidat ty funkce, které jsou potřeba pouze při testování.
A stalo se, že při testování to vypadá, že chcete otestovat ty změny, které nakonec půjdou do výroby. Ale ve skutečnosti se jedna věc testovala a při výrobě byla použita trochu jiná. A došlo k malému zlomu ve vzoru, že ve výrobě byly všechny změny aplikovány operačním týmem. A někdy se ukázalo, že ty změny, které měly jít z testování do výroby, zůstaly v jiné verzi.
Navíc se vyskytl takový problém, že přibyla nová služba, která se trochu lišila od nějaké stávající. A místo úpravy existujícího modulu jste museli vytvořit jeho kopii a přidat potřebné změny.
Ve skutečnosti Terraform není skutečný jazyk. Toto je prohlášení. Pokud potřebujeme něco deklarovat, tak to deklarujeme. A všechno to funguje.
V určitém okamžiku, když jsem probíral jeden z mých požadavků na tah, jeden z mých kolegů řekl, že není nutné vyrábět sněhové vločky. Přemýšlel jsem, co tím myslel. Existuje takový vědecký fakt, že na světě neexistují dvě stejné sněhové vločky, všechny jsou mírně, ale odlišné. A jakmile jsem to slyšel, okamžitě jsem ucítil plnou váhu kódu Terraform. Protože když bylo nutné přejít z verze na verzi, Terraform vyžadoval změnu přerušovacího řetězce, tj. kód již nebyl kompatibilní s další verzí. A musel jsem vytvořit požadavek na stažení, který pokrýval téměř polovinu souborů v infrastruktuře, abych infrastrukturu přenesl do další verze Terraformu.
A poté, co se objevila taková sněhová vločka, všechen kód Terraformu, který jsme proměnili ve velkou, velkou hromadu sněhu.
Pro externího vývojáře, který je mimo provoz, je to pro něj jedno, protože udělal požadavek na stažení, jeho zdroj se spustil. A to je vše, není to jeho starost. A tým DevOps, který zajišťuje, že je vše v pořádku, musí provést všechny tyto změny. A náklady na tyto změny se s každou další sněhovou vločkou velmi, velmi zvyšovaly.
Vypráví se příběh o tom, jak student na semináři nakreslí křídou na tabuli dva dokonalé kruhy. A učitel se diví, jak dokázal tak hladce kreslit bez kružítka. Student odpovídá: "Je to velmi jednoduché, dva roky jsem v armádě kroutil mlýnkem na maso."
A ze čtyř let, co jsem na tomto projektu, dělám Terraform asi dva roky. A samozřejmě mám nějaké triky, pár tipů, jak zjednodušit kód Terraform, pracovat s ním jako s programovacím jazykem a snížit zátěž pro vývojáře, kteří musí tento kód udržovat aktuální.
První věcí, kterou bych chtěl začít, jsou Symlinks. Terraform má spoustu opakujícího se kódu. Například volání poskytovatele téměř v každém bodě, kde vytváříme část infrastruktury, je stejné. A je logické dát to do samostatného tatínka. A všude tam, kde je poskytovatel povinen vytvořit na tento soubor symbolické odkazy.
Například používáte převzít roli v produkci, která vám umožňuje získat přístupová práva k nějakému externímu účtu Amazon. A změnou jednoho souboru budou mít všechny zbývající, které jsou ve stromu zdrojů, požadovaná práva, aby Terraform věděl, ke kterému segmentu Amazonu má přistupovat.
Kde symbolické odkazy nefungují? Jak jsem řekl, Terraform má stavové soubory. A jsou velmi, velmi cool. Faktem ale je, že Terraform inicializuje backend hned v prvním. A v těchto parametrech nemůže používat žádné proměnné, vždy je třeba je zapsat textově.
A ve výsledku, když někdo vytvoří nový zdroj, zkopíruje část kódu z jiných složek. A může udělat chybu s klíčem nebo s kbelíkem. Například z pískoviště vyrobí sandboxovou věc a pak ji vyrobí ve výrobě. A tak to může dopadnout tak, že kbelík ve výrobě bude použit z pískoviště. Samozřejmě to rychle najdou. Bude možné to nějak opravit, ale přesto je to ztráta času a do jisté míry i prostředků.
Co můžeme dělat dál? Než začnete pracovat s Terraformem, musíte jej inicializovat. V době inicializace Terraform stáhne všechny pluginy. V určitém okamžiku se zlomili z monolitu na architekturu více mikroslužeb. A vždy musíte provést Terraform init tak, aby stáhl všechny moduly, všechny pluginy.
A můžete použít skript Shell, který za prvé může získat všechny proměnné. Shell skript je neomezený. A za druhé způsob. Pokud vždy použijeme cestu, která je v úložišti jako klíč ke stavovému souboru, pak zde bude chyba vyloučena.
Kde získat data? soubor JSON. Terraform umožňuje psát infrastrukturu nejen v hcl (HashiCorp Configuration Language), ale také v JSON.
JSON je snadno čitelný ze skriptu shellu. V souladu s tím můžete na nějaké místo umístit konfigurační soubor s bucketem. A použijte tento kbelík jak v kódu Terraform, tak ve skriptu shellu pro inicializaci.
Proč je důležité mít kbelík Terraform? Protože existuje něco jako soubory vzdáleného stavu. To znamená, že když zvýším nějaký zdroj, abych řekl Amazonu: „Prosím, zvyšte instanci“, musím zadat mnoho požadovaných parametrů.
A tyto identifikátory jsou uloženy v nějaké jiné složce. A můžu to vzít a říct: "Terraforme, prosím běžte do státního souboru tohoto zdroje a sežeňte mi tyto identifikátory." A tím dochází k jakémusi sjednocení mezi různými regiony či prostředími.
Ne vždy je možné použít vzdálený stavový soubor. Například jste ručně vytvořili VPC. A kód Terraform, který vytváří VPC, vytváří tak odlišné VPC, že to trvá velmi dlouho a musíte si jeden přizpůsobit druhému, takže můžete použít následující trik.
To znamená vytvořit modul, který jakoby vytváří VPC a dává vám identifikátory, ale ve skutečnosti existuje pouze soubor s pevně zakódovanými hodnotami, které lze použít k vytvoření stejné instance.
Ne vždy je nutné ukládat stavový soubor do cloudu. Například při testování modulů můžete využít inicializaci backendu, kdy se soubor v době testování uloží jen na disk.
Nyní něco málo o testování. Co lze v Terraformu testovat? Možná je toho hodně, ale budu mluvit o těchto 4 věcech.
HashiCorp rozumí tomu, jak formátovat kód Terraform. A Terraform fmt vám umožňuje formátovat kód, který upravujete, podle tohoto přesvědčení. V souladu s tím musí testy nutně zkontrolovat, zda formátování odpovídá tomu, co HashiCorp odkázal, abyste nemuseli měnit umístění závorek atd.
Další je Terraform validate. Dělá to trochu víc než jen kontrolu syntaxe - ala, jsou všechny závorky spárované. Co je zde důležité? Máme velmi tenkou infrastrukturu. Má spoustu různých složek. A v každém musíte spustit Terraform validate.
V souladu s tím, abychom urychlili testování, spouštíme několik procesů paralelně pomocí paralelního.
Paralelní je velmi cool věc, použijte ji.
Ale pokaždé, když je Terraform inicializován, přejde do HashiCorp a zeptá se: „Jaké jsou nejnovější pluginy? A plugin co mám v cache - je to ten nebo ne ten? A zpomalovalo se na každém kroku.
Pokud vám Terraform řekne, kde jsou pluginy, Terraform řekne: „Dobře, toto je pravděpodobně ta nejčerstvější věc, která existuje. Nikam nepůjdu, hned začnu ověřovat váš kód Terraform.“
Abychom naplnili složku potřebnými pluginy, máme velmi jednoduchý kód Terraform, který stačí inicializovat. Zde je samozřejmě potřeba specifikovat všechny poskytovatele, kteří se nějak podílejí na vašem kódu, jinak Terraform řekne: "Žádného poskytovatele neznám, protože není v mezipaměti."
Další je plán Terraform. Jak jsem řekl, vývoj je cyklický. Vytváříme kód se změnami. A pak musíte zjistit, jaké změny se plánují pro infrastrukturu.
A když je infrastruktura velmi, velmi velká, můžete změnit jeden modul, opravit nějaké testovací prostředí nebo určitou konkrétní oblast a rozbít sousední. Proto by měl být vytvořen plán Terraform pro celou infrastrukturu a ukázat, jaké změny se plánují.
Můžete to udělat chytrým způsobem. Například jsme napsali skript Python, který řeší závislosti. A v závislosti na tom, co bylo změněno: modul Terraform nebo jen konkrétní komponenta, vytváří plány pro všechny závislé složky.
Terraform plán musí být proveden na vyžádání. Alespoň to tak děláme.
Testy je samozřejmě dobré dělat pro každou změnu, pro každý commit, ale plány jsou docela drahá věc. A v žádosti o stažení říkáme: "Prosím, dejte mi plány." Robot se spustí. A pošle do komentářů nebo k příloze všechny plány, které se od vašich změn očekávají.
Plán je poměrně drahá záležitost. Chce to čas, protože Terraform jde do Amazonu a ptá se: „Existuje tato instance stále? Má toto automatické škálování úplně stejné parametry?“. A abyste to urychlili, můžete použít parametr jako refresh=false. To znamená, že Terraform vyfoukne stav S3. A bude věřit, že stát bude přesně odpovídat tomu, co je v Amazonu.
Takový plán Terraform je mnohem rychlejší, ale stav musí odpovídat vaší infrastruktuře, tj. někde se musí spustit obnova Terraformu. Terraform refresh dělá přesně to, aby stav odpovídal tomu, co je ve skutečné infrastruktuře.
A musím říct o bezpečnosti. Tady to mělo začít. Kde spustíte Terraform a Terraform spolupracuje s vaší infrastrukturou, existuje zranitelnost. To znamená, že v podstatě spouštíte kód. A pokud požadavek na stažení obsahuje nějaký druh škodlivého kódu, pak jej lze spustit na infrastruktuře, která má příliš velký přístup. Buďte proto opatrní, kde spustíte plán Terraform.
Další věc, o které bych chtěl mluvit, je testování uživatelských dat.
Co jsou uživatelská data? V Amazonu, když vytvoříme instanci, můžeme z instance poslat nějaký dopis – meta data. Když je instance spuštěna, obvykle je v těchto instancích vždy přítomen cloud init. Cloud init čte tento dopis a říká: "OK, dnes jsem vyrovnáváním zátěže." A v souladu s těmito předpisy provádí některé akce.
Ale bohužel, když provádíme plán Terraform a aplikujeme Terraform, uživatelská data vypadají jako tato kaše čísel. To znamená, že vám jen pošle hash. A v plánu vidíte jen to, zda dojde k nějakým změnám nebo hash zůstane stejný.
A pokud tomu nebudete věnovat pozornost, pak může jít nějaký přebitý textový soubor do Amazonu, do skutečné infrastruktury.
Alternativně můžete při provádění zadat nikoli celou infrastrukturu, ale pouze šablonu. A v kódu řekněte: "Zobrazte mi prosím tuto šablonu." A ve výsledku si můžete nechat vytisknout, jak budou vaše data na Amazonu vypadat.
Další možností je použít modul pro generování uživatelských dat. Tento modul použijete. Získejte soubor na disk. Porovnejte to s odkazem. A tak, pokud se nějaký jun rozhodne opravit malá uživatelská data, pak vaše testy řeknou: "OK, jsou tu nějaké změny - to je normální."
Další věc, o které bych chtěl mluvit, je aplikace Automate Terraform.
Samozřejmě je dost děsivé používat Terraform v automatickém režimu, protože kdo ví, jaké změny tam přišly a jak škodlivé mohou být pro živou infrastrukturu.
Pro testovací prostředí je to vše v pořádku. To znamená, že práce, která vytváří testovací prostředí, je to, co potřebují všichni vývojáři. A takový výraz jako „vše mi fungovalo“ není vtipný mem, ale důkaz, že se člověk zmátl, zvedl stack, spustil nějaké testy na tomto stacku. A ubezpečil se, že je tam všechno v pořádku a řekl: "OK, kód, který vydávám, byl otestován."
V produkčním prostředí, sandboxu a dalších prostředích, která jsou pro podnikání kritická, je bezpečné částečně využít některé zdroje, protože to nikoho nezemře. Jsou to: skupiny automatického škálování, skupiny zabezpečení, role, route53 a tam může být seznam docela velký. Ale sledujte, co se děje, čtěte zprávy o automatizovaných aplikacích.
Tam, kde je nebezpečné nebo děsivé používat, například pokud se jedná o nějaké trvalé zdroje, z databáze, pak získáte zprávy, že v nějaké části infrastruktury jsou neaplikované změny. A inženýr je již pod dohledem, když spouští úlohy, aby je mohl aplikovat nebo provádět ze své konzole.
Amazon má takovou věc jako Terminate protection. A v některých případech může chránit před změnami, které pro vás nejsou vyžadovány. Terraform tedy šel do Amazonu a říká: „Musím zabít tuto instanci, abych vytvořil další“. A Amazon říká: „Promiň, dnes ne. Máme ochranu ukončit."
A třešničkou na dortu je optimalizace kódu. Když pracujeme s kódem Terraform, musíme modulu předat velmi velké množství parametrů. Toto jsou parametry, které jsou nezbytné pro vytvoření nějakého druhu zdroje. A kód se změní na velké seznamy parametrů, které je třeba předávat z modulu do modulu, z modulu do modulu, zvláště pokud jsou moduly vnořené.
A čte se to velmi špatně. Je velmi těžké to přezkoumat. A velmi často se ukáže, že se některé parametry revidují a nejsou úplně ty potřebné. A oprava později stojí čas a peníze.
Proto vám doporučuji použít něco jako komplexní parametr, který zahrnuje určitý strom hodnot. To znamená, že potřebujete nějakou složku, kde máte všechny hodnoty, které byste chtěli mít v nějakém prostředí.
A voláním tohoto modulu můžete získat strom, který se generuje v jednom společném modulu, tedy ve společném modulu, který funguje stejně pro celou infrastrukturu.
V tomto modulu můžete provádět některé výpočty pomocí tak nové funkce v Terraformu jako místní. A pak v jednom výstupu zadejte nějaký komplexní parametr, který může zahrnovat hashe, pole atd.
Na tomto, všechny nejlepší nálezy, které jsem skončil. A chtěl bych vyprávět příběh o Kolumbovi. Když sháněl peníze na svou výpravu za poznáním Indie (jak si tehdy myslel), nikdo mu nevěřil a věřil, že je to nemožné. Pak řekl: "Ujistěte se, že vejce nespadne." Všichni bankéři, velmi bohatí a pravděpodobně chytří lidé, se snažili vajíčko nějakým způsobem položit a ono to neustále padalo. Pak Kolumbus vejce vzal a trochu ho přitiskl. Skořápka se zmačkala a vejce zůstalo nehybné. Řekli: "Ach, to je příliš snadné!" A Kolumbus odpověděl: „Ano, je to příliš jednoduché. A když otevřu Indii, všichni budou používat tuto obchodní cestu.“
A to, co jsem vám právě řekl, jsou pravděpodobně docela jednoduché a triviální věci. A když se o nich dozvíte a začnete je používat, je to v pořadí věcí. Tak toho využijte. A pokud jsou to pro vás celkem běžné věci, tak alespoň víte, jak dát vajíčko, aby nespadlo.
Abych to shrnul:
- Snažte se vyhnout sněhovým vločkám. A čím méně sněhových vloček, tím méně prostředků budete potřebovat k provedení jakýchkoli změn v celé vaší velké infrastruktuře.
- Neustálá změna. To znamená, že když v kódu dojde k nějakým změnám, musíte svou infrastrukturu co nejdříve uvést do souladu s těmito změnami. Neměla by nastat situace, kdy se někdo přijde za dva tři měsíce podívat na Elasticsearch, udělá plán Terraform a je tam spousta změn, které nečekal. A dát vše do pořádku zabere spoustu času.
- Testy a automatizace. Čím více kódu jste pokryli testy a funkcemi, tím máte větší jistotu, že vše děláte správně. A automatické doručení mnohonásobně zvýší vaši důvěru.
- Kód pro testovací a produkční prostředí by měl být téměř stejný. Prakticky proto, že výroba je přeci jen trochu jiná a stále se najdou nějaké nuance, které budou přesahovat testovací prostředí. Ale přesto se to plus mínus dá poskytnout.
- A pokud máte hodně kódu Terraform a udržování tohoto kódu v aktuálním stavu zabere hodně času, pak není nikdy pozdě na jeho refaktorování a uvedení do dobrého stavu.
- neměnná infrastruktura. Doručení AMI podle plánu.
- Struktura pro route53, když máte hodně položek a chcete, aby byly v konzistentním pořadí.
- Bojujte proti limitům rychlosti API. To je, když Amazon říká: "To je ono, nemohu přijímat žádné další požadavky, čekejte prosím." A polovina úřadu čeká, až bude moci spustit svou infrastrukturu.
- spotové instance. Amazon není levná akce a spoty umožňují poměrně hodně ušetřit. A tam o tom můžete vyprávět celou reportáž.
- Role zabezpečení a IAM.
- Hledejte ztracené zdroje, když máte případy neznámého původu v Amazone, žerou peníze. I když instance stojí 100-150 $ měsíčně, je to více než 1 000 $ ročně. Hledání takových zdrojů je lukrativní záležitost.
- A vyhrazené instance.
To je z mé strany vše. Terraform je velmi cool, použijte ho. Děkuji!
otázky
Díky za zprávu! Máte stavový soubor v S3, ale jak vyřešíte problém, že několik lidí může vzít tento stavový soubor a pokusit se jej nasadit?
Za prvé, nikam nespěcháme. Za druhé, existují příznaky, ve kterých hlásíme, že pracujeme na nějakém kousku kódu. To znamená, že navzdory tomu, že infrastruktura je velmi rozsáhlá, neznamená to, že někdo neustále něco používá. A když byla aktivní fáze, byl to problém, uchovávali jsme stavové soubory v Gitu. To bylo důležité, jinak by někdo udělal stavový soubor a my jsme je museli ručně shromáždit na hromadu, abychom mohli pokračovat dále. Nyní již takový problém není. Obecně platí, že Terraform tento problém vyřešil. A pokud se něco neustále mění, pak můžete použít zámky, které zabrání tomu, co jste řekli.
Používáte open source nebo enterprise?
Žádný podnik, tedy vše, co můžete jít a stáhnout zdarma.
Jmenuji se Stanislav. Chtěl jsem udělat malý dodatek. Mluvil jste o funkci Amazonu, která vám umožňuje učinit instanci nezničitelnou. To je i v samotném Terraformu, v bloku Life Second si můžete naordinovat zákaz změny, případně zákaz ničení.
Byl časově omezený. Dobrý postřeh.
Taky jsem se chtěl zeptat na dvě věci. Nejprve jste mluvil o testování. Použili jste nějaké testovací nástroje? Slyšel jsem o pluginu Test Kitchen. Možná je ještě něco jiného. A chtěl bych se zeptat na Místní hodnoty. Jak se v podstatě liší od vstupních proměnných? A proč nemohu něco parametrizovat pouze prostřednictvím Místních hodnot? Zkoušel jsem se tímto tématem zabývat, ale nějak jsem na to sám nepřišel.
Můžeme mluvit podrobněji za tímto sálem. Testovací nástroje si vyrábíme sami. Není tam co testovat. Obecně existují možnosti, kdy automatické testy infrastrukturu někde pozvednou, zkontrolují, zda je v pořádku, a pak vše zničí s hlášením, že je vaše infrastruktura stále v dobrém stavu. To nemáme, protože testovací zásobníky běží každý den. A to stačí. A když se něco začne lámat, tak se to začne lámat, aniž bychom to někde jinde kontrolovali.
Ohledně místních hodnot pokračujme v rozhovoru mimo publikum.
Ahoj! Díky za zprávu! Velmi informativní. Řekl jste, že máte spoustu stejného typu kódu k popisu infrastruktury. Uvažovali jste o vygenerování tohoto kódu?
Skvělá otázka, díky! Jde o to, že když používáme infrastrukturu jako kód, předpokládáme, že se podíváme na kód a pochopíme, jaký druh infrastruktury se za tímto kódem skrývá. Pokud je kód generován, pak si musíme představit, jaký kód bude generován, abychom pochopili, jaký druh infrastruktury tam bude. Nebo kód vygenerujeme, odevzdáme a ve skutečnosti dostaneme to samé. Proto jsme šli tak, jak jsme napsali, dostali jsme to. Navíc se generátory objevily o něco později, když jsme začali vyrábět. A na změnu už bylo pozdě.
Slyšeli jste o jsonnet?
Ne.
Podívej, tohle je vážně skvělá věc. Vidím konkrétní případ, kdy to můžete aplikovat a vygenerovat datovou strukturu.
Generátory jsou dobré, když je máte, jako ve vtipu o holicím strojku. To znamená, že poprvé je obličej jiný, ale pak mají všichni stejnou tvář. Generátory jsou velmi cool. Ale naše tváře jsou bohužel trochu jiné. To je problém.
Jen se podívej. Děkuji!
Jmenuji se Maxim a jsem ze Sberbank. Trochu jste řekl, že jste se pokusil přenést Terraform do analogu programovacího jazyka. Není jednodušší používat Ansible?
To jsou velmi odlišné věci. Ansible může vytvářet zdroje a Puppet může vytvářet zdroje v Amazonu. Terraform je ale přímo vybroušený.
Máte jen Amazon?
Není to tak, že máme pouze Amazon. Máme skoro jen Amazon. Ale klíčová vlastnost je, že si Terraform pamatuje. Pokud v Ansible řeknete: „Vyzvedni mi 5 případů“, zvýší se a pak řekneš: „A teď potřebuji 3“. A Terraform řekne: "Ok, zabiju 2" a Ansible řekne: "Ok, tady jsou 3 pro tebe." Celkem 8.
Ahoj! Děkujeme za vaši zprávu! Bylo velmi zajímavé slyšet o Terraformu. Chci jen malou poznámku k tomu, že Terraform stále nemá stabilní vydání, takže buďte s Terraformem velmi opatrní.
Pěkná lžíce k večeři. Čili pokud potřebujete řešení, tak občas odkládáte, co je nestabilní atd., ale funguje to a nám to pomohlo.
Otázkou je. Používáte vzdálený backend, používáte S 3. Proč nepoužíváte oficiální backend?
Oficiální?
Terraform Cloud.
Kdy se objevil?
před 4 měsíci.
Kdyby se to objevilo před 4 lety, pravděpodobně bych na vaši otázku odpověděl.
K dispozici je již vestavěná funkce a zámky a můžete uložit soubor stavu. Zkus to. Ale taky nemám vyzkoušené.
Jsme ve velkém vlaku, který se pohybuje vysokou rychlostí. A nemůžete jen tak vzít a vyhodit pár aut.
Mluvil jsi o sněhových vločkách, proč jsi nepoužil větev? Proč to tak nevyšlo?
Máme takový přístup, že celá infrastruktura je v jednom úložišti. Terraform, Puppet, všechny skripty, které s tím nějak souvisí, všechny jsou v jednom úložišti. Tímto způsobem můžeme zajistit, že přírůstkové změny budou testovány jednu po druhé. Pokud by se jednalo o hromadu poboček, pak by takový projekt bylo téměř nemožné udržovat. Uběhne šest měsíců a rozcházejí se natolik, že je to jen jakýsi trest. To je to, od čeho jsem chtěl před refaktorizací utéct.
tj nefunguje to?
To vůbec nejde.
Ve větvi jsem vystřihl sklíčko složky. To znamená, že pokud pro každý testovací zásobník uděláte například tým A má svého tátu, tým B má svého tátu, tak to také nefunguje. Vytvořili jsme jednotný kód testovacího prostředí, který byl dostatečně flexibilní, aby vyhovoval všem. To znamená, že jsme obsluhovali jeden kód.
Ahoj! Jmenuji se Yura! Díky za zprávu! Otázka ohledně modulů. Říkáte, že používáte moduly. Jak vyřešíte problém, pokud byly v jednom modulu provedeny změny, které nejsou kompatibilní se změnou jiné osoby? Nějakým způsobem verzovat moduly nebo se snažíte přivést zázračné dítě ke splnění dvou požadavků?
To je velký problém s hromadou sněhu. To je to, čím trpíme, když nějaká neškodná změna může narušit některou část infrastruktury. A to bude patrné až po delší době.
To znamená, že ještě není rozhodnuto?
Vyrábíte univerzální moduly. Vyhněte se sněhovým vločkám. A všechno vyjde. Druhá polovina zprávy je o tom, jak se tomu vyhnout.
Ahoj! Díky za zprávu! Rád bych to upřesnil. V zákulisí byla velká hromada, pro kterou jsem si přišel. Jak je integrována loutka a distribuce rolí?
uživatelská data.
To znamená, že prostě vyplivneš soubor a nějak na něm spustíš?
Uživatelská data jsou poznámka, to znamená, že když vytvoříme klon obrazu, pak tam Daemon vstane a snaží se zjistit, kdo to je, přečte si poznámku, že je vyrovnáváním zátěže.
To znamená, je to nějaký druh samostatného procesu, který je dán pryč?
My jsme to nevymysleli. Používáme to.
Ahoj! Mám jen dotaz ohledně Uživatel - data. Říkal jste, že tam jsou problémy, že někdo může poslat něco na špatné místo. Existuje nějaký způsob, jak uložit uživatelská data ve stejném Gitu, aby bylo vždy jasné, na co se uživatelská data vztahují?
Vygenerujeme uživatelská data ze šablony. To znamená, že se tam ukrývá určitý počet proměnných. A Terraform generuje konečný výsledek. Proto se nemůžete jen podívat na šablonu a říct, co se stane, protože všechny problémy souvisejí s tím, že si vývojář myslí, že v této proměnné předává řetězec, a pak se použije pole. A on - prásk a já - ten a ten, ten a ten, další řádek a všechno se zlomilo. Pokud se jedná o nový zdroj a člověk ho zvedne, vidí, že něco nefunguje, tak se to rychle vyřeší. A pokud byla tato skupina automatického škálování aktualizována, pak se v určitém okamžiku začnou instance ve skupině automatického škálování nahrazovat. A tleskáte, něco nefunguje. To bolí.
Ukazuje se, že jediným řešením je test?
Ano, vidíš problém, přidáš tam testovací kroky. To znamená, že výstup lze také testovat. Možná to není tak pohodlné, ale můžete také zadat nějaké značky - zkontrolujte, zda jsou zde uvedena uživatelská data.
Jmenuji se Timur. Je skvělé, že existují zprávy o tom, jak správně organizovat Terraform.
Ani jsem nezačal.
Myslím, že na příští konferenci možná bude. Mám jednoduchou otázku. Proč napevno kódujete hodnotu v samostatném modulu místo použití tfvars, tj. je modul s hodnotami lepší než tfvars?
To znamená, že bych sem měl napsat (snímek: Výroba/prostředí/nastavení.tf): doména = proměnná, doména vpcnetwork, proměnná vpcnetwork a stvars - dostat to samé?
Přesně to děláme. Odkazujeme například na modul zdroje nastavení.
Ve skutečnosti je to takový tfvars. Tfvars je velmi praktický v testovacím prostředí. Mám tfvars pro velké instance, pro malé. A hodil jsem jeden soubor do složky. A dostal jsem, co jsem chtěl. Když jsme viděli infrastrukturu, chceme být schopni vidět a okamžitě porozumět všemu. A tak se ukazuje, že je třeba se podívat sem, pak se podívat do tfvars.
Ukázalo se, že vše bylo na jednom místě?
Ano, tfvars je, když máte jeden kód. A používá se na několika různých místech s různými nuancemi. Pak byste hodili tfvars a získali své nuance. A my jsme infrastruktura jako kód ve své nejčistší podobě. Díval se a pochopil.
Ahoj! Narazili jste na situace, kdy poskytovatel cloudu zasahuje do toho, co jste s Terraformem udělali? Řekněme, že upravujeme metadata. Existují ssh klíče. A Google tam neustále podsouvá svá metadata, své klíče. A Terraform vždy píše, že má změny. Po každém spuštění, i když se nic nezmění, vždy řekne, že toto pole nyní aktualizuje.
S klíči, ale - ano, část infrastruktury je takovou věcí zasažena, čili Terraform nemůže nic změnit. Ani rukama nic nezměníme. Dokud s tím budeme žít.
To znamená, že jste na to narazili, ale na nic jste nepřišli, jak to dělá a dělá to sám?
Bohužel ano.
Ahoj! Jmenuji se Stanislav Starkov. Pošta. en Skupina. Jak řešíte problém s generováním tagu na ..., jak to předáváte dovnitř? Jak tomu rozumím, přes User - data, specifikovat jméno hostitele, podněcovat Puppet? A druhá část otázky. Jak řešíte tento problém v SG, tedy když vygenerujete SG, sto instancí stejného typu, jak je správně pojmenovat?
Ty případy, které jsou pro nás velmi důležité, si je krásně pojmenujeme. U těch, které nejsou potřeba, existuje dodatek, že se jedná o skupinu automatického škálování. A teoreticky to může být přibito a získat nový.
Pokud jde o problém s tagem, takový problém neexistuje, ale existuje takový úkol. A tagy používáme velmi, velmi intenzivně, protože infrastruktura je velká a drahá. A musíme se podívat na to, za co se utrácejí peníze, takže tagy nám umožňují utřídit, co a kam šlo. A proto je hledání něčeho zde hodně vynaložených peněz.
O čem ještě byla otázka?
Když SG vytvoří sto instancí, je potřeba je nějak rozlišovat?
Ne, ne. Každá instance má agenta, který mi říká, že mám problém. Pokud se agent hlásí, pak o něm agent ví a alespoň jeho IP adresa existuje. Už můžeš běžet. Za druhé používáme Consul pro Discovery, kde není žádný Kubernetes. A Consul také zobrazuje IP adresu instance.
To znamená, že cílíte přesně na IP, a ne na název hostitele?
Není možné navigovat podle názvu hostitele, tj. je jich mnoho. Jsou tam identifikátory instancí - AE atd. Někde to najdeš, můžeš to hodit do vyhledávání.
Ahoj! Uvědomil jsem si, že Terraform je dobrá věc, ušitá na míru mrakům.
Nejen to.
To je otázka, která mě zajímá. Pokud se rozhodnete přejít, řekněme, do Bare Metalu hromadně se všemi svými instancemi? Budou tu nějaké problémy? Nebo musíte stále používat jiné produkty, například stejný Ansible, který zde byl zmíněn?
Ansible je trochu o něčem jiném. To znamená, že Ansible je již spuštěn při spuštění instance. A Terraform funguje před spuštěním instance. Přechod na Bare Metal není.
Teď ne, ale obchod přijde a řekne: "Pojď."
Přepnutí na jiný cloud – ano, ale je zde trochu jiná funkce. Musíte napsat kód Terraform takovým způsobem, abyste mohli přejít na jiný cloud s menším krveprolitím.
Zpočátku bylo zadání, že celá naše infrastruktura je agnostická, tedy jakýkoli cloud by měl být v pořádku, ale v určitém okamžiku to firma vzdala a řekla: „Dobře, za dalších N let se nikam nepohneme, můžete využívat služby od Amazon“.
Terraform vám umožňuje vytvářet front-endové úlohy, konfigurovat PagerDuty, datové dokumenty atd. Má spoustu ocasů. Dokáže prakticky ovládat celý svět.
Díky za zprávu! Taky točím Terraformem už 4 roky. Ve fázi hladkého přechodu k Terraformu, k infrastruktuře, k deklarativnímu popisu jsme byli postaveni před situaci, kdy někdo něco dělal ručně a vy jste se snažili vytvořit plán. A mám tam nějakou chybu. Jak se s takovými problémy vypořádáváte? Jak najdete ztracené zdroje, které byly označeny?
Většinou rukama a očima, pokud v reportáži uvidíme něco divného, tak rozebereme, co se tam děje, nebo to rovnou zabijeme. Obecně jsou žádosti o stažení běžnou věcí.
Pokud dojde k chybě, vrátíte se zpět? Zkoušel jsi to udělat?
Ne, to je rozhodnutí člověka ve chvíli, kdy vidí problém.
Zdroj: www.habr.com