Reprezentovat infrastrukturu jako kód v opakovatelném textovém formátu je jednoduchý osvědčený postup pro systémy, které nevyžadují hraní s myší. Tato praxe má jméno - , a zatím existují dva populární nástroje k jeho implementaci, zejména v AWS: и .
Porovnání zkušeností s Terraform a CloudFormation
Před příchodem do (Aka ) Pracoval jsem a používal Terraform po dobu tří let. Na novém místě jsem s vypětím všech sil používal i Terraform a následně firma prosadila přechod na vše á la Amazon, včetně CloudFormation. Pilně jsem vyvíjel osvědčené postupy pro oba a oba nástroje používám ve velmi složitých pracovních postupech v rámci celé organizace. Později, po promyšleném zvážení důsledků migrace z Terraformu na CloudFormation, jsem se přesvědčil, že Terraform je pro organizaci pravděpodobně tou nejlepší volbou.
Terraform Hrozný
Beta software
Terraform ještě ani nevydal verzi 1.0, což je dobrý důvod, proč ji nepoužívat. Od té doby, co jsem to poprvé zkusil sám, se to hodně změnilo, ale tehdy terraform apply často se porouchal po několika aktualizacích nebo jednoduše po několika letech používání. Řekl bych, že „teď je všechno jinak“, ale... to, jak se zdá, říkají všichni, ne? Existují změny, které jsou nekompatibilní s předchozími verzemi, i když jsou vhodné, a dokonce se zdá, že syntaxe a abstrakce zdrojů jsou nyní to, co potřebujeme. Zdá se, že nástroj se opravdu zlepšil, ale... :-0
Na druhou stranu AWS odvedl dobrou práci při zachování zpětné kompatibility. Je to pravděpodobně proto, že jejich služby jsou v rámci organizace často důkladně testovány a teprve poté, přejmenovány, jsou publikovány. Takže „usilovně se snažili“ je slabé slovo. Udržování zpětné kompatibility s API pro systém tak rozmanitý a komplexní, jako je AWS, je neuvěřitelně obtížné. Každý, kdo musel udržovat veřejná API, která jsou používána tak široce, jak jsou, by měl pochopit, jak obtížné je to dělat po tolik let. Ale chování CloudFormation, v mé paměti, se za ta léta nikdy nezměnilo.
Potkat nohu... je to kulka
Pokud vím, smažte zdroj outsider Zásobník CloudFormation z vašeho zásobníku CF není možný. To samé platí s Terraformem. Umožňuje vám importovat existující zdroje do vašeho zásobníku. Dá se říci, že funkce je úžasná, ale s velkou silou přichází velká zodpovědnost. Stačí přidat prostředek do zásobníku a při práci se zásobníkem nemůžete tento prostředek odstranit ani změnit. Jednoho dne se to nepovedlo. Jednoho dne na Twitchi někdo omylem importoval něčí bezpečnostní skupinu AWS do jejich vlastního zásobníku Terraform, aniž by se pustil do nějaké neplechu. Zadal jsem několik příkazů a... bezpečnostní skupina (spolu s příchozím provozem) zmizela.
Terraform Skvělý
Zotavení z neúplných stavů
Někdy CloudFormation nemusí zcela přejít z jednoho stavu do druhého. Zároveň se pokusí vrátit k předchozímu. Škoda, že to není vždy možné. Může být děsivé ladit, co se stalo později – nikdy nevíte, zda bude CloudFormation ráda, že je hacknuta – i když to jen opravíte. Zda bude možné vrátit se do předchozího stavu nebo ne, opravdu neví, jak určit, a ve výchozím nastavení visí celé hodiny a čeká na zázrak.
Na druhou stranu Terraform má tendenci se zotavovat z neúspěšných přechodů mnohem elegantněji a nabízí pokročilé nástroje pro ladění.
Jasnější změny stavu dokumentu
"Dobře, vyvažovači zátěže, měníš se." Ale jak?"
—neklidný inženýr, připravený stisknout tlačítko „přijmout“.
Někdy potřebuji provést nějaké manipulace s nástrojem pro vyrovnávání zatížení v zásobníku CloudFormation, jako je přidání čísla portu nebo změna skupiny zabezpečení. ClouFormation špatně zobrazuje změny. Na špendlíkech a jehlách desetkrát dvakrát zkontroluji yaml soubor, abych se ujistil, že jsem nevymazal nic potřebného a nepřidal nic zbytečného.
Terraform je v tomto ohledu mnohem transparentnější. Někdy je až příliš průhledný (čti: nudný). Naštěstí nejnovější verze obsahuje vylepšené zobrazení změn, takže nyní přesně vidíte, co se mění.
Flexibilita
Napište software pozpátku.
Řečeno na rovinu, nejdůležitější vlastností softwaru s dlouhou životností je schopnost přizpůsobit se změnám. Napište jakýkoli software pozpátku. Nejčastěji jsem dělal chyby tím, že jsem vzal „jednoduchou“ službu a pak jsem vše začal nacpat do jednoho zásobníku CloudFormation nebo Terraform. A samozřejmě, o měsíce později se ukázalo, že jsem vše pochopil špatně a služba ve skutečnosti nebyla jednoduchá! A teď potřebuji nějak rozdělit velký zásobník na malé součástky. Když pracujete s CloudFormation, lze to provést pouze tak, že nejprve znovu vytvoříte existující zásobník, a to se svými databázemi nedělám. Terraform naproti tomu umožňoval rozřezat stoh a rozložit jej na srozumitelnější menší části.
Moduly v git
Sdílení kódu Terraform mezi více zásobníky je mnohem jednodušší než sdílení kódu CloudFormation. S Terraformem můžete umístit svůj kód do úložiště git a přistupovat k němu pomocí sémantické správy verzí. Každý, kdo má přístup k tomuto úložišti, může sdílený kód znovu použít. Ekvivalentem CloudFormation je S3, ale nemá stejné výhody a není důvod, proč bychom měli opouštět git ve prospěch S3.
Organizace rostla a schopnost sdílet společné zásobníky dosáhla kritické úrovně. Díky Terraformu je to všechno snadné a přirozené, zatímco CloudFormation vás přiměje skákat přes obruče, než se vám něco takového podaří zprovoznit.
Operace jako kód
"Napíšeme to a dobře."
— inženýr 3 roky před vynálezem kola Terraform.
Pokud jde o vývoj softwaru, Go nebo Java program není jen kód.
Kód jako kód
Je tam i infrastruktura, na které to funguje.
Infrastruktura jako kód
Ale odkud je? Jak to sledovat? Kde se nachází váš kód? Potřebují vývojáři oprávnění k přístupu?
Operace jako kód
Být softwarovým vývojářem neznamená jen psát kód.
AWS není jediný: pravděpodobně používáte jiné poskytovatele. SignalFx, PagerDuty nebo Github. Možná máte interní server Jenkins pro CI/CD nebo interní řídicí panel Grafana pro monitorování. Infra jako kód je zvolen z různých důvodů a každý je stejně důležitý pro vše, co souvisí se softwarem.
Když jsem pracoval na Twitchi, zrychlili jsme služby uvnitř smíšených vestavěných a AWS systémů Amazon. Vychrlili jsme a podpořili mnoho mikroslužeb, čímž jsme zvýšili provozní náklady. Diskuse probíhaly asi takto:
- Я: Sakra, to je spousta gest k přetaktování jedné mikroslužby. Budu muset použít tento odpad k vytvoření účtu AWS (přešli jsme na 2 účty mikroservis), pak toto pro nastavení upozornění, toto pro úložiště kódů a toto pro seznam e-mailů a pak toto...
- Vést: Pojďme to naskriptovat a dobře.
- Я: Dobře, ale změní se samotný scénář. Budeme potřebovat způsob, jak zkontrolovat, zda jsou všechny tyto vestavěné věci Amazon aktuální.
- Vést: To zní dobře. A napíšeme k tomu scénář.
- Я: Skvělý! A skript bude pravděpodobně muset ještě nastavit parametry. Přijme je?
- Vést: Ať si vezme, kam jde!
- Я: Proces se může změnit a zpětná kompatibilita bude ztracena. Bude vyžadována nějaká sémantická kontrola verzí.
- Vést: Skvělý nápad!
- Я: Nástroje lze měnit ručně v uživatelském rozhraní. Budeme potřebovat způsob, jak to zkontrolovat a opravit.
…o 3 roky později:
- Vést: A dostali jsme terraform.
Morálka příběhu je: i když vy hlava nehlava ve všem Amazon, stále používáte něco, co není od AWS, a tyto služby mají stav, který používá konfigurační jazyk, aby byl tento stav synchronizován.
CloudFormation lambda vs git moduly terraform
lambda je řešením problému vlastní logiky od CloudFormation. S lambdou můžete nebo . Tento přístup zavádí další složitosti, které nejsou přítomny v sémantickém verzování modulů git Terraform. Pro mě byla nejpalčivějším problémem správa oprávnění pro všechny tyto uživatelské lambdy (a to jsou desítky účtů AWS). Dalším důležitým problémem byl problém „co bylo dřív, slepice nebo vejce?“: souvisel s lambda kódem. Tato funkce je sama o sobě infrastrukturou a kódem a sama potřebuje monitorování a aktualizace. Posledním hřebíčkem do rakve byla obtížnost sémantické aktualizace změn lambda kódu; také jsme museli zajistit, aby se akce zásobníku bez přímého příkazu mezi běhy neměnily.
Vzpomínám si, jak jsem jednou chtěl vytvořit kanárkové nasazení pro prostředí Elastic Beanstalk s klasickým load balancerem. Nejjednodušší věcí by bylo provést druhou implementaci pro EB vedle produkčního prostředí a udělat to o krok dále: zkombinovat skupinu nasazení s automatickým škálováním a LB nasazení do produkčního prostředí. A protože Terraform používá , bude to vyžadovat 4 řádky kódu navíc v Terraformu. Když jsem se zeptal, zda existuje srovnatelné řešení v CloudFormation, upozornili mě na celé úložiště git s potrubím nasazení a vším, vše kvůli něčemu, co by mohly udělat chudé 4 řádky kódu Terraform.
Lépe detekuje drift
Ujistěte se, že realita odpovídá očekávání.
je velmi výkonná operace jako funkce kódu, protože pomáhá zajistit, aby realita odpovídala očekáváním. Je k dispozici s CloudFormation a Terraform. Ale jak produkční zásobník rostl, hledání driftu v CloudFormation produkovalo stále více falešných detekcí.
S Terraformem máte mnohem pokročilejší háky životního cyklu pro detekci posunu. Například zadáte příkaz přímo v definici úlohy ECS, pokud chcete ignorovat změny v definici konkrétní úlohy, aniž byste ignorovali změny celého nasazení ECS.
CDK a budoucnost CloudFormation
CloudFormation je obtížné spravovat ve velkém měřítku napříč infrastrukturou. Mnohé z těchto potíží jsou rozpoznány a nástroj potřebuje věci jako , framework pro definování cloudové infrastruktury v kódu a její provozování prostřednictvím AWS CloudFormation. Bude zajímavé vidět, co budoucnost přinese aws-cdk, ale bude mít těžké konkurovat ostatním silným stránkám Terraformu; k aktualizaci CloudFormation budou nutné globální změny.
Aby Terraform nezklamal
Toto je „infrastruktura jako kód“, a nikoli „jako text“.
Můj první dojem z Terraformu byl dost špatný. Myslím, že jsem ten přístup jen nepochopil. Téměř všichni inženýři jej nedobrovolně vnímají jako textový formát, který je třeba převést do požadované infrastruktury. NEDĚLEJTE TO TAKTO.
Zásady dobrého vývoje softwaru platí také pro Terraform.
Viděl jsem mnoho praktik přijatých k vytvoření dobrého kódu, které byly v Terraformu ignorovány. Léta jste studoval, abyste se stal dobrým programátorem. Nevzdávejte se této zkušenosti jen proto, že pracujete s Terraformem. Pro Terraform platí zásady dobrého vývoje softwaru.
Jak nemůže být kód zdokumentován?
Viděl jsem obrovské hromádky Terraformu s absolutně žádnou dokumentací. Jak můžete napsat kód na stránky - s absolutně žádnou dokumentací? Přidejte dokumentaci, která vysvětluje vaše kód Terraform (důraz na slovo „kód“), proč je tato sekce tak důležitá a co děláte.
Jak můžeme nasadit služby, které byly kdysi jednou velkou funkcí main()?
Viděl jsem velmi složité zásobníky Terraform prezentované jako jeden modul. Proč nenasadíme software tímto způsobem? Proč rozdělujeme velké funkce na menší? Stejné odpovědi platí pro Terraform. Pokud je váš modul příliš velký, musíte jej rozdělit na menší moduly.
Nevyužívá vaše společnost knihovny?
Viděl jsem, jak inženýři, kteří vytvořili nový projekt pomocí Terraformu, hloupě zkopírovali obrovské kusy z jiných projektů do svých vlastních, a pak si s nimi pohrávali, dokud to nezačalo fungovat. Pracovali byste takto s „bojovým“ kódem ve vaší firmě? Nevyužíváme jen knihovny. Ano, ale kde jsme bez sdílených knihoven v zásadě?!
Nepoužíváš PEP8 nebo gofmt?
Většina jazyků má standardní, akceptované schéma formátování. V Pythonu je to PEP8. V Go - gofmt. Terraform má své vlastní: terraform fmt. Užijte si to pro své zdraví!
Budete používat React bez znalosti JavaScriptu?
Moduly Terraform mohou zjednodušit některé části složité infrastruktury, kterou vytvoříte, ale to neznamená, že si s tím nemůžete vůbec pohrát. Chcete správně používat Terraform, aniž byste rozuměli zdrojům? Jste odsouzeni k záhubě: čas uplyne a nikdy nezvládnete Terraform.
Kódujete pomocí singletonů nebo dependency injection?
Dependency injection je uznávanou nejlepší praxí pro vývoj softwaru a je upřednostňována před singletony. Jak je to užitečné v Terraformu? Viděl jsem moduly Terraform, které závisí na vzdáleném stavu. Namísto psaní modulů, které získávají vzdálený stav, napište modul, který přebírá parametry. A pak předat tyto parametry modulu.
Dělají vaše knihovny deset věcí dobře nebo jednu skvělou?
Knihovny, které fungují nejlépe, jsou ty, které se zaměřují na jeden úkol, který dělají velmi dobře. Místo psaní velkých modulů Terraform, které se snaží dělat vše najednou, vytvářejte jejich části, které dělají jednu věc dobře. A pak je kombinujte podle potřeby.
Jak provedete změny v knihovnách bez zpětné kompatibility?
Běžný modul Terraform, stejně jako běžná knihovna, potřebuje nějakým způsobem sdělovat změny uživatelům, aniž by byl zpětně kompatibilní. Je nepříjemné, když se tyto změny dějí v knihovnách, a stejně tak nepříjemné, když se v modulech Terraform provádějí změny, které nejsou zpětně kompatibilní. Při použití modulů Terraform se doporučuje používat značky git a semver.
Běží vaše produkční služba na vašem notebooku nebo v datovém centru?
Hashicorp má nástroje jako provozovat svůj terraform. Tyto centralizované služby usnadňují správu, audit a schvalování terraformních změn.
Nepíšeš testy?
Inženýři uznávají, že kód je potřeba testovat, ale sami na testování při práci s Terraformem často zapomínají. Pro infrastrukturu je to plné zrádných okamžiků. Moje rada je „testovat“ nebo „vytvářet příklady“ zásobníků pomocí modulů, které lze správně nasadit pro testování během CI/CD.
Terraform a mikroslužby
Život a smrt mikroslužeb závisí na rychlosti, inovaci a narušení nových pracovních sad mikroslužeb.
Nejběžnější negativní aspekt spojený s architekturami mikroslužeb, který nelze odstranit, souvisí s prací, nikoli s kódem. Pokud si myslíte, že Terraform je jen způsob, jak automatizovat pouze infrastrukturní stránku architektury mikroslužeb, pak přicházíte o skutečné výhody systému. Teď už je .
Zdroj: www.habr.com