Prezentace infrastruktury jako kódu v opakovatelném textovém formátu je jednoduchá osvědčená praxe pro systémy, se kterými nemusíte mít problémy. Tato praxe nese název — , a zatímco pro její implementaci, zejména v AWS, existují dva populární nástroje: a .
Porovnávám zkušenosti s Terraform a CloudFormation
Před příchodem do (také známé jako ) jsem pracoval a přibližně tři roky jsem používal Terraform. Na novém místě jsem také plně využíval Terraform, a pak firma prosadila přechod na všechno jako Amazon, včetně CloudFormation. Usilovně jsem vyvíjel osvědčené praktiky pro obě platformy a používal oba nástroje v velmi složitých pracovních procesech na úrovni organizace. Později, po pečlivém zvážení důsledků přechodu z Terraform na CloudFormation, jsem dospěl k názoru, že Terraform je pravděpodobně nejlepší volbou pro organizaci.
Terraform je hrozný
Beta verze softwaru
Terraform ještě ani nevydal verzi 1.0, což je pádný důvod ho nepoužívat. Od doby, kdy jsem ho poprvé vyzkoušel, se výrazně změnil, ale tehdy ještě terraform apply často selhával po několika aktualizacích nebo prostě po pár letech používání. Řekl bych, že "teď je všechno jinak", ale... tak to říká asi každý, že? Jsou tu změny, které nejsou kompatibilní s předchozími verzemi, i když jsou na místě, a dokonce je pocit, že syntaxe a abstrahce zdrojových uložišť jsou nyní přesně to, co potřebujeme. Nástroj se zdá být skutečně lepší, ale... :-0
Na druhou stranu, AWS si vedlo dobře při udržování kompatibility s předchozími verzemi. Asi proto, že jejich služby se často důkladně testují uvnitř organizace a až poté, po přejmenování, se zveřejňují. Takže "udělali dobrou práci" je ještě slabě řečeno. Udržování kompatibility s předchozími verzemi API pro tak rozmanitý a složitý systém jako AWS je neuvěřitelně těžké. Kdo musel udržovat veřejné API, jež se používají tak široce, si musí být vědom toho, jak těžké to je po tak dlouhou dobu. A chování CloudFormation se podle mé paměti za léta nikdy nezměnilo.
Seznam se, noha… to je kulka
Jak vím, odstranit zdroj cizího Z vlastního CF stacku není možné importovat CloudFormation stack. Podobně je to i s Terraformem. Ten umožňuje importovat existující zdroje do svého stacku. Tato funkce je, dá se říci, úžasná, ale s velkou silou přichází i velká odpovědnost. Jakmile je zdroj přidán do stacku, není možné tento zdroj během práce se svým stackem odstranit nebo změnit. Jednou jsem na to doplatil. Na webu Twitch někdo, aniž by měl špatné úmysly, omylem importoval cizí skupinu zabezpečení AWS do svého vlastního Terraform stacku. Zadal pár příkazů a… skupina zabezpečení (spolu s příchozím provozem) zmizela.
Terraform Velký
Obnova z neúplných stavů
Někdy CloudFormation nemůže úplně přejít z jednoho stavu do druhého. Snaží se vrátit k předchozímu stavu. Je škoda, že to není vždy proveditelné. Opravit to, co zůstalo, bývá děsivé — nikdy nevíte, zda CloudFormation ocení, že ho hackují — i když jen pro opravu. A zda se vrátí k předchozímu stavu, to moc nedokáže odhadnout a ve výchozím nastavení visí hodiny v očekávání zázraku.
Terraform má naopak elegantnější způsob, jak se zotavit po neúspěšných přechodech, a nabízí rozšířenou ladící sadu.
Jasnější změny ve státních dokumentech
„Dobrá, load balancere, měníš se. Ale jak?“
— znepokojený inženýr, připravený stisknout tlačítko „přijmout“.
Někdy potřebuji provést nějaké manipulace s load balancerem ve stacku CloudFormation — například přidat číslo portu nebo změnit skupinu zabezpečení. CloudFormation změny znázorňuje slabě. Já, jako na trní, desetkrát kontroluji yaml soubor, abych se ujistil, že jsem nic podstatného neodstranil a že jsem nic zbytečného nepřidal.
Terraform je v tomto ohledu mnohem transparentnější. Někdy je až příliš průhledný (čti: otravný). Naštěstí byla do poslední verze přidána vylepšená vizualizace změn — nyní je přesně vidět, co se mění.
Flexibilita
Pište software od konce.
Přesně řečeno, nejdůležitější vlastností dlouhodobě fungujícího softwaru je schopnost přizpůsobit se změnám. Jakýkoli software pište naopak. Já jsem se nejčastěji spálil tím, že jsem vzal "jednoduchou" službu a pak se snažil vše vtěsnat do jedné zásobníku CloudFormation nebo Terraform. A samozřejmě, po měsících vyšlo najevo, že jsem všechno pochopil špatně, a služba není vlastně tak jednoduchá! A teď nějakým způsobem potřebuji rozdělit velkou zásobníku na malé části. Když pracujete s CloudFormation, je možné to udělat pouze tím, že nejprve obnovíte existující zásobník, a to já, se svými databázemi, nedělám. Terraform mi však umožnil provést dekonstrukci zásobníku a rozdělit ho na srozumitelnější menší části.
Moduly v git
Sdílení kódu Terraform mezi mnoha zásobníky je mnohem jednodušší než sdílení kódu CloudFormation. S Terraformem můžete umístit kód do repozitáře git a odkazovat na něj pomocí sémantické kontroly verzí. Každý, kdo má přístup k tomuto repozitáři, může opětovně použít sdílený kód. Ekvivalent od CloudFormation je S3, ale ten nemá stejné výhody, a není žádný důvod, proč bychom měli vzdát git ve prospěch S3.
Organizace rostla a schopnost sdílet společné zásobníky dosáhla kritické úrovně. S Terraformem je to snadné a přirozené, zatímco CloudFormation vás donutí skákat přes obruče, než budete mít něco podobného.
Operations as code
"Zaskriptujme to a je to."
- inženýr tři roky předtím, než vynalezl kolo Terraform.
Když se mluví o vývoji softwaru, tak Go nebo program v Javě není prostě jen kód.
Code as Code
Vždyť tu je i infrastruktura, na které to běží.
Infrastruktura jako kód
Ale odkud se tam vzala? Jak ji monitorovat? Kde žije váš kód? Potřebují vývojáři povolení k přístupu?
Operations as Code
Být vývojářem softwaru není jen o psaní kódu.
Nejen AWS: určitě využíváte služby i dalších poskytovatelů. SignalFx, PagerDuty nebo Github. Možná máte interní server Jenkins pro CI/CD nebo interní řídicí panel Grafana pro monitoring. Infra as Code je vybíráno z různých důvodů, a každý z nich je stejně důležitý pro vše, co se týká softwaru.
Když jsem pracoval na Twitchi, urychlovali jsme služby uvnitř smíšených vestavěných systémů a systémů AWS Amazonu. Tvorili jsme a udržovali mnoho mikroslužeb, což zvyšovalo provozní náklady. Diskuse probíhaly asi takto:
- Já: Sakra, je to docela dost dřiny na start jedné mikroslužby. Tohle budu muset použít k založení účtu AWS (šly jsme k 2 účtům na mikroslužbu), pak tohle — pro nastavení upozornění, ještě tohle — pro repozitář kódu, a tohle — pro seznam e-mailových adres, a tohle...
- Lead: Napsáme skript a hotovo.
- Já: Jasně, ale ten skript se změní. Bude potřeba způsob, jak zkontrolovat, že všechny tyto vestavěné součásti Amazonu mají aktuální stav.
- Lead: Zní to dobře. A pro to napíšeme skript.
- Já: Skvěle! A skriptu bude jistě potřeba ještě předat parametry. Přijme je?
- Lead: Jasně, že přijme, co by jinak dělal!
- Já: Proces se může změnit, dojde ke ztrátě zpětné kompatibility. Bude potřeba nějaký semantický kontrolní systém verzí.
- Lead: Skvělý nápad!
- Já: Nástroje lze změnit ručně, uvnitř uživatelského rozhraní. Potřebujeme způsob, jak to kontrolovat a opravovat.
…3 roky nato:
- Lead: A vznikl nám terraform.
Morálka příběhu je taková: i když jste po uši ve všem amazonovském, stejně používáte něco, co není od AWS, a tyto služby mají stav, který používá jazyk pro konfiguraci, aby tento stav synchronizoval.
CloudFormation lambda vs git-moduly terraform
lambda je řešení CloudFormation pro otázku uživatelské logiky. Pomocí lambda lze nebo . Tento přístup představuje další komplikace, které neexistují v semantickém kontrolním systému verzí modulů git v Terraformu. Pro mě samotnou se stala nejpalčivější otázkou správa oprávnění pro všechny tyto uživatelské lambda (a to jsou desítky účtů AWS). Druhou nejdůležitější otázkou byla problém typu "co bylo dřív — slepice nebo vejce?": ta se týkala kódu lambda. Samotná tato funkce — infrastruktura a kód, a také potřebuje monitorování a aktualizace. Posledním hřebíkem do rakve byla obtížnost semantického aktualizování změn kódu lambda; ještě bylo třeba udělat tak, aby akce zásobníku se nezměnily mezi spuštěními bez přímého příkazu.
Pamatuji si, jak jsem jednou chtěl vytvořit kanárkovou verzi nasazení pro prostředí Elastic Beanstalk s tradičním load balancerem. Nejjednodušší by bylo provést druhé nasazení EB vedle produkčního prostředí a udělat ještě krok: zkombinovat automaticky škálovatelnou skupinu kanárkového nasazení s LB nasazením do produkčního prostředí. A protože Terraform používá , to bude vyžadovat 4 navíc řádky kódu v Terraformu. Když jsem se ptal, zda neexistuje srovnatelné řešení v CloudFormation, ukázali mi celou repozitář v gitu s kontejnerem pro nasazení a dalšími: a to vše — pro něco, co bychom mohli udělat se šťastnými 4 řádky kódu v Terraformu.
Lepší detekce odchylky
Ujistěte se, že realita odpovídá očekáváním.
— velmi výkonná funkce operations as code, protože pomáhá zajistit, že realita odpovídá očekáváním. Je dostupná jak v CloudFormation, tak v Terraformu. Ale s rostoucí velikostí pracovního stacku byla detekce odchylky v CloudFormation stále více chybných detekcí.
S Terraformem máte mnohem pokročilejší hooky životního cyklu pro detekci odchylky. Například zadáte příkaz přímo v definici úlohy ECS, pokud chcete ignorovat změny v definici konkrétní úlohy, aniž byste přitom ignorovali změny ve všech nasazeních ECS.
CDK a budoucnost CloudFormation
CloudFormation se těžko spravuje ve velkých, meziinfrastrukturních měřítkách. Mnohé z těchto obtíží byly uznány a nástroji chybí takové věci jako , struktura pro definici cloudové infrastruktury v kódu a její provedení prostřednictvím AWS CloudFormation. Bude zajímavé vidět, co čeká aws-cdk v budoucnu, ale těžko konkurovat jiným výhodám Terraformu; k posílení CloudFormation budou zapotřebí globální změny.
Aby Terraform nezklamal
To je přece "infrastruktura jako KÓD", ne "jako text".
První dojem z Terraformu na mě udělal dost špatný. Myslím, že jsem jednoduše nepochopil přístup. Prakticky všichni inženýři ho na poprvé nevědomky vnímají jako textový formát, který je třeba přetvořit na požadovanou infrastrukturu. NEDĚLEJTE TO TAK.
Základní principy dobrého softwarového vývoje platí i pro Terraform
Viděl jsem, jak mnoho praktik, které se používají pro vytváření dobrého kódu, je ignorováno v Terraformu. Učili jste se roky, abyste se stali dobrým programátorem. Nezřekněte se této zkušenosti jen proto, že pracujete s Terraformem. Základní pravdy dobrého vývoje softwaru se vztahují i na Terraform.
Jak můžete napsat kód a nedokumentovat ho?
Setkal jsem se s obrovskými stacky Terraformu bez jakékoli dokumentace. Jak lze psát kód po stránkách — úplně bez dokumentace? Přidávejte dokumentaci, která vysvětluje váš kód Terraform (důraz zde na slovo „kód“), proč je tato část tak důležitá a co děláte.
Jak lze nasazovat služby, které byly kdysi jednou velkou funkcí main()?
Setkal jsem se s velmi složitými stacky Terraformu, prezentovanými jako jediný modul. Proč takto nen nasazujeme software? Proč rozdělujeme velké funkce na menší? Ty samé odpovědi platí i pro Terraform. Pokud je váš modul příliš velký — je třeba ho rozdělit na menší moduly.
Nepoužívá vaše společnost knihovny?
Viděl jsem, jak inženýři, při rozjezdu nového projektu s pomocí Terraformu, jednoduše zkopírovali obrovské kusy z jiných projektů do svých vlastních a pak je upravovali, dokud to nezačalo fungovat. Vy byste v naší firmě pracovali takto s „produkčním“ kódem? Nepoužíváme knihovny bez důvodu. Ano, ale kam bychom se bez společných knihoven dostali?!
Nepoužíváte PEP8 nebo gofmt?
Ve většině jazyků existuje standardní akceptovaný formátovací schéma. V Pythonu je to PEP8. V Go — gofmt. Terraform má svůj: terraform fmt. Používejte ho s radostí!
Budete používat React, aniž byste znali JavaScript?
Moduly Terraformu mohou zjednodušit část vaší složité infrastruktury, ale to neznamená, že v tom nemusíte mít vůbec žádné znalosti. Chcete správně používat Terraform bez porozumění zdrojům? Jste odsuzováni k neúspěchu: čas uběhne a vy se Terraform stejně nenaučíte.
Kódujete singletony, nebo vkládáním závislostí?
Zavislosti jsou uznávanou nejlepší praxí pro vývoj softwaru, kterou preferují singletony. Jak to pomůže v Terraformu? Setkal jsem se s moduly Terraform, které závisí na vzdáleném stavu. Místo toho, abyste psali moduly, které extrahují ze vzdáleného stavu, napište modul, který přijímá parametry. A poté tyto parametry předávejte do modulu.
Vaše knihovny dělají deset věcí dobře nebo jednu – skvěle?
Nejlépe fungují knihovny, které se soustředí na jeden úkol, který vykonávají na výbornou. Místo psaní velkých modulů Terraform, které se snaží dělat všechno najednou, skládajte je do částí, které dělají něco jednoho dobře. A poté je kombinujte tak, jak je potřeba.
Jak provádíte změny v knihovnách bez zpětné kompatibility?
Obecnému modulu Terraform, stejně jako běžné knihovně, je třeba nějakým způsobem sdělit uživatelům o změnách bez zpětné kompatibility. Když dochází k takovýmto změnám v knihovnách, je to frustrující, a stejně tak je frustrující, když se ve modules Terraform provádějí změny bez zpětné kompatibility. Doporučuje se používat git tags a semver při použití modulů Terraform.
Je váš produkční služba spuštěna na notebooku nebo v datovém centru?
Hashicorp má nástroje jako pro spuštění vašeho terraform. Tyto centralizované služby usnadňují správu, audit a schvalování změn terraform.
Nepíšete snad testy?
Inženýři uznávají, že kód je třeba testovat, ale často přitom zanedbávají kontroly při práci s Terraformem. Pro infrastrukturu to nese zrádné momenty. Doporučuji "testovat" nebo "vytvářet příklady" stacků s využitím modulů, které lze správně nasadit pro ověření během CI/CD.
Terraform a mikroservisy
Život a smrt firem s mikroservisním přístupem závisí na rychlosti, aktualizaci a destrukci nových pracovních stacků mikroservisů.
Nejrozšířenějším negativním aspektem spojeným s mikroservisními architekturami, od kterého se nelze zbavit, je práce, nikoli kód. Pokud vnímáte Terraform pouze jako způsob automatizace pouze infrastrukturní stránky mikroservisní architektury, připravujete se o skutečné výhody tohoto systému. Nyní už .
Zdroj: habr.com
