Infrastructure as Code: Všechno co jste kdy chtěli vědět, ale báli jste se zeptat

Kdy (ne)uvažovat o automatizované infrastruktuře

Jak s oblibou říká náš kolega Lukáš Klášterský, pokud s cloudem začínáte, „don’t think big” a nejprve se s ním důkladně seznamte. Naopak, pokud je cloud pro vás již standard, provozujete zde několik větších aplikací a vše „běží, jak má“, tak možná přišel čas pomýšlet i na Infrastructure as Code (IaC).

Co je tedy hlavním cílem IaC? Jak již název předesílá, jde o to, mít infrastrukturu definovanou podobným způsobem jako zdrojové kódy aplikace. Výsledkem je tedy IaC blueprint (či artefakt), který popisuje „jak má vypadat tato část infrastruktury“. Zjednodušeně můžeme říci, že každá část infrastruktury má svůj jednoznačný blueprint, který definuje: „Takto má vypadat moje databáze,“ či: „Takto vypadá můj Redis Cluster.“

Samozřejmě můžete namítat, že každá komponenta každé vaší aplikace je jiná, individuální. V tom případě IaC pravděpodobně není pro vás. Nejzajímavějšího synergického efektu napříč celým prostředím docílíte tehdy, máte-li jasně definované architektonické standardy (a zároveň je i dodržujete), které poté realizujete právě pomocí IaC.

Nicméně pokud žádný standard nemáte nebo je obtížné takový standard definovat, i zde mohou být specifické use-cases, kdy IaC bude dávat smysl.

Trošku předběhnu: na tomto příkladu (zjednodušeném) se dá ukázat, jak může vypadat takový IaC blueprint pro databázi (v prostředí AWS, blueprint definován pomocí AWS CloudFormation):

Nyní nebudeme zabíhat do detailu, co která část znamená, ale chtěl jsem vám hned na začátku ukázat „jak to reálně vypadá“.

Proč automatizovat infrastrukturu aneb use cases

No dobrá, tak již víme, co to IaC asi zhruba je, a máme rámcovou představu, k čemu by to asi mohlo být dobré. Pojďme se podívat na konkrétní využití IaC.

Pro ty z vás, kteří dáváte přednost stručnosti před detailními příklady, je shrnutí zhruba následující:

Kdy uvažovat nad Infrastructure as a Code

• Mám jasně definované infrastrukturní standardy.
• Potřebuji dynamicky tvořit jednotlivá aplikační prostředí.
• Dochází k častým změnám v prostředí, které chci centrálně řídit.

Kdy pro mě Infrastructure as a Code spíše není

• S cloudem se teprve seznamuji, mám spíše základní zkušenosti s provozem cloudového prostředí.
• Moje infrastruktura je primárně „statická“, bez mnoha změn.
• Aplikační infrastruktura je značně individuální a není možné definovat obecný závazný standard.

Obecně tedy můžeme říci, že Infrastructure as a Code je nedílnou součástí automatizace cloudového prostředí a automatizace samotná je jednou z hlavních motivací pro využití cloudu.

Use case 1: Dynamické prostředí

Tento scénář se typicky týká vývojových či testovacích prostředí. Proč bych měl provozovat vývojové prostředí permanentně (a platit za něj), když jej vývoj potřebuje „jen když zrovna něco nasazuje a testuje“? Nebo možná mám více vývojových týmů, které pracují nad stejnou aplikací. Aby mezi nimi nedocházelo ke „kolizím“, chci mít možnost každému týmu připravit identické prostředí (a poté ho zase smazat, až nebude potřeba).

Pokud takové prostředí definujete pomocí IaC blueprintů, můžete jej dynamicky celé nasadit a v momentě, kdy je již nepotřebujete, zase smazat. A to vše zcela automatizovaně v rámci vaší CI/CD pipeline.

Use case 2: Infrastruktura jako nedílná součást aplikace

Tento scénář podporuje jeden z důležitých aspektů vývoje cloud-native aplikací, a tím je parita mezi prostředími. Ideálně chci, aby moje testovací prostředí bylo stejné jako produkční (možná menší z pohledu výkonu), ale architekturně identické.

Tento přístup mi výrazně zjednodušuje hledání případných chyb a celkový troubleshooting prostředí. Popis infrastruktury je tedy nedílnou součástí doručení aplikace a takovou aplikaci jsem schopen okamžitě nasadit do cílového prostředí.

Za malou chvíli si řekneme, že existují různé typy blueprintů a jedním z nich jsou blueprinty určené pro konfiguraci samotné landing zone (cloudového prostředí). V tomto use case je cílem mít všechna prostředí (z obecného pohledu, nikoliv v kontextu samotné aplikace) nastavena naprosto identicky – vynutit standard.

Například ve všech prostředích je vždy vyžadována konkrétní tagging policy, ve všech prostředích je nakonfigurována auditní stopa a veškerá prostředí „by default“ mají nějakým (identickým) způsobem nakonfigurovánu páteřní síť.

Use case 3: Automatizovaný životní cyklus infrastruktury

Během doby se standardy mění, rozšiřují či jinak upravují. Díky IaC mohu jednoduchým způsobem provádět modifikace či jiné změny nad veškerou infrastrukturou, a tím řídit celý životní cyklus infrastruktury. Od vytvoření přes veškeré její změny až po finální zrušení.

Na začátku jsem si například definoval, že pro veškeré databáze chci mít k dispozici 14 denních záloh a že ke každé databázi můžou přistupovat administrátoři z konkrétního síťového rozsahu. Postupem času došlo k rozhodnutí, že je z business pohledu nutné udržovat 30 záloh, a zároveň došlo k rozšíření organizace o další pobočku, jejíž zaměstnanci také potřebují přístup ke všem databázím.

Mohu jednoduchým způsobem modifikovat můj původní blueprint pro databázi, tyto požadavky do něj zakomponovat a poté automatizovaně provést úpravu veškerých databází vytvořených na základě tohoto blueprintu. Stejně tak mohu například veškeré komponenty vytvořené na základě tohoto bluepintu kdykoliv hromadně odstranit.

Blueprinty, kam se podíváte

Jak jsem již naznačil před chvílí, existují v principu tři základní kategorie IaC blueprintů:

• Infrastrukturní
• Konfigurující prostředí (landing zone)
• Bezpečnostní

Blueprinty pro infrastrukturu aplikace

Tyto blueprinty se poté ještě dělí na:

• Generické
• Aplikačně-specifické

Pod generickými blueprinty aplikace si můžeme představit například již zmiňovanou databázi. Ta je reprezentována jedním jediným IaC blueprintem a veškeré aplikace využívají pouze jej. Dalším příkladem může být nasazení kontejnerizační infrastruktury či virtuálního serveru.

Aplikačně-specifické blueprinty jsou součástí jedné konkrétní aplikace a nejsou využívány jinou aplikací. Toto mohou být například aplikační parametry uložené v AWS System Manager Parameter Store či Azure AppConfig) nebo specifické aplikační tajnosti v AWS Secret Manager nebo Azure Vault.

Blueprinty pro konfiguraci prostředí (landing zone)

O těchto blueprintech jsem se již zmínil před chvílí. Jsou určeny pro konfiguraci celého cloud prostředí a jsou nasazovány vždy, bez ohledu na to, jaká aplikace je v rámci prostředí provozována.

Patří sem například komponenty typu Budgets (aby v každém prostředí byl nasazen nějaký mechanismus pro kontrolu a reporting nákladů), konfigurace páteřní sítě (například standardní routovací tabulky do mé Hub sítě, jak popisuje Jakub Procházka ve svém článku Rozplétáme cloudové sítě) nebo to může být například nějaká serverless funkce odpovědná za forwarding bezpečnostních logů do centrálního SIEM prostředí.

Bezpečnostní blueprinty

Toto je specifická kategorie blueprintů, které se také nasazují do každého prostředí, ale má je ve své kompetenci bezpečnostní oddělení. Smyslem bezpečnostních blueprintů je definovat bezpečnostní politiky, které kontrolují či přímo vynucují, aby byly plněny mé bezpečnostní požadavky (typicky se využívají komponenty jako AWS Config nebo Azure Policy).

Jako příklad mohu uvést například dodržování tagging policy, zda jsou veškeré komponenty opravdu šifrovány, jsou-li nastaveny specifické parametry jednotlivých komponent konkrétním způsobem atp.

Mohli byste namítat, že bezpečnostní blueprinty jsou zbytečné, protože veškeré parametry jsou nastaveny „tak, jak mají být,“ díky aplikačním blueprintům. To je sice pravda, ale pouze v momentě nasazení takového blueprintu. Postupem času může dojít k modifikaci jednotlivých cloud zdrojů (lidská chyba, nevědomá změna atp.). Smyslem bezpečnostních blueprintů je tedy kontinuální kontrola celého prostředí. Můžeme je tedy vnímat jako „kontrolní blueprinty“.

Jak to celé hraje dohromady

Pokud se tedy rozhodnete (a měli byste) implementovat všechny tři typy IaC blueprintů, výsledek bude vypadat zhruba takto:

Nejdříve jsou do prostředí nasazeny jednotlivé blueprinty pro konfigurace landing zone (konfigurace celého prostředí), poté bezpečnostní blueprinty a na závěr pak jednotlivé infrastrukturní blueprinty.

Tím docílíte stavu, kdy:

• každé prostředí (v tomto případě AWS prostředí) je nasazeno dle globálního standardu,
• kolegové z bezpečnostního oddělení ví, že veškeré požadavky na compliance prostředí jsou realizovány,
• samotná aplikace je nasazena v jasně definovaném standardu.

Životní cyklus blueprintů

Rozhodně bychom neměli zapomínat na to, že jednotlivé blueprinty se v čase mění a vyvíjejí tak, jak se mění vaše interní architekturní či bezpečnostní požadavky. Je tedy důležité mít definován postup, jak blueprinty v čase měnit.

Přistupujeme k nim podobně, jako k jinému programovému kódu.

Obvykle jsou výsledné blueprinty uloženy v centrálním repozitáři (například AWS S3 či Azure Storage Account), ze kterého jsou nasazovány. Tento repozitář by za žádných okolností neměl umožňovat přímou modifikaci těchto blueprintů!

Typický scénář řízené a auditované modifikace blueprintu je takový, že jsou jeho jednotlivé verze uloženy v nějakém centrálním source-code repository (například GIT). Při změně (commitu) nové verze blueprintu je spuštěna CI/CD pipeline, jejíž prvním krokem je validace provedených změn (review proces).

Pokud je review úspěšné, nasadí se nová verze blueprintu do testovacího prostředí, kde je otestováno, že „vše je, jak má být,“ a až poté dochází k finálnímu zpřístupnění nové verze blueprintu v centrálním repozitáři blueprintů.

Desired state a proč je to tak důležité

Pojďme si ještě popsat, co je to desired state a proč by vás to mělo zajímat. Desired state přístup popisuje „cílový stav objektu“, tedy že moje (například) databáze má vypadat „tak a tak“.

Využívá tedy deklarativní přístup. Deklaruji, „jak to má být“. Což je jiný přístup, než na který jste možná zvyklí – přístup imperativní, kde naopak definuji, „co se má jak nakonfigurovat“.

Příklad deklarativního přístupu:

• Moje databáze se má jmenovat MyDb.
• Databáze má mít velikost 20 GB.
• Výkon databáze je 2 CPU a 4 GB RAM.
• Disk databáze má být šifrován.

Příklad imperativního přístupu:

• Vytvoř databázi se jménem MyDb.
• Nakonfiguruj databázi MyDb tak, aby měla velikost 20 GB.
• Nakonfiguruj databázi MyDb tak, aby měla 2 CPU a 4 GB RAM.
• Zašifruj disk databáze MyDb.

Obrovskou výhodou deklarativního zápisu je, že mám onen desired state – tedy informaci, jak to má být. Pokud mám informaci o cílovém stavu, jsem schopný jednoduše kontrolovat v libovolném čase aktuální stav proti cílovému.

Například na začátku byla databáze šifrována, nicméně v průběhu času ji někdo (například díky lidské chybě) odšifroval. Pokud znám aktuální i cílový stav, jsem schopen tuto situaci detekovat, a to včetně detailní informace „co je jinak, než má být“.

Ukázka použití desired state

Ukázka funkcionality AWS CloudFormation Drift, tedy technologie, která nám umožňuje detekovat odchylky proti cílovému stavu:

Zde na první pohled vidím, že došlo k modifikaci zdroje ManagementSecurityGroup, který aktuálně neodpovídá svému cílovému stavu. Na základě této informace mám možnost provést případně opravné kroky.

AWS Cloud Formation Drifts je jedním z nástrojů spadajících do kategorie continuous cloud compliance, což je trošku širší oblast věnující se právě kontinuálnímu vyhodnocování definovaných pravidel. Patří sem nepřeberné množství nástrojů – jak nativních, například Azure Policy, AWS Config nebo zmiňované Cloud Formation Drifts, tak i externích, například nástroj CheckPoint CloudGuard.

Téma continuous cloud compliance je spíše na samostatný článek – nebojte se, brzy bude!

Jaké nástroje tedy mohu použít?

Pokud jste dočetli až sem, tak gratuluji! Koncept Infrastructure as a Code vás tedy pravděpodobně zaujal a nyní asi přemýšlíte, jak ho vlastně realizovat.

První rozhodnutí, které musíte učinit je, zda-li se chcete soustředit pouze na jedno konkrétní cloudové prostředí, nebo chcete jedním nástrojem řídit vše, od on-premise napříč různými cloud prostředími.

Pokud je váš cíl být opravdu hybridní, naše doporučení je využít nástroj Terraform od firmy HashiCorp. Tento nástroj je nesmírně silný, nicméně z mého pohledu může být jeho komplexní nasazení relativně komplikovaným úkolem. Na druhou stranu vám nabídne opravdu hybridní přístup k IaC napříč libovolnými prostředími.

Pokud se naopak chcete soustředit pouze na jedno konkrétní cloudové prostředí, doporučil bych spíše využít nástroje vybraného cloud poskytovatele.

V prostředí Amazon Web Services je to nástroj CloudFormation. Bystrý čtenář si jistě všiml, že v tomto článku jsou použity ukázky primárně z tohoto nástroje, který já osobně preferuji.

Co může být zajímavé, je možnost využít přidruženého nástroje Cloud Development Kit (CDK) pro tvorbu CloudFormation blueprintů. CDK využijí pravděpodobně ti z vás, u kterých se cloudovému prostředí věnuje zejména vývojové oddělení. CDK totiž umožňuje tvorbu CloudFormation blueprintů pomocí jednotlivých programovacích jazyků jako JavaScript, TypeScript, Python, Java, C#, a Go.

Pokud je vaším cloud prostředím Azure, tak rozhodně využijete Azure Resource Manager (ARM) šablony.

ARM je nativní a nedílnou součástí Azure. Pokud jste pozorní, jistě jste si všimli, že Azure překládá veškeré vaše operace (prováděné v grafické konzoli Azure) týkající se vytvoření jakéhokoliv zdroje právě do ARM template, které poté aplikuje.

Pokud se chcete inspirovat, jak vypadají tyto „interní“ ARM šablony, můžete si zkusit vytvořit libovolný zdroj a stáhnout si tuto vygenerovanou ARM šablonu.

Závěrem k Infrastructure as Code

Pokud vážně uvažujete nad automatizací cloudového prostředí, Infrastructure as Code je v podání jakéhokoliv nástroje určitě směr, kterým byste se měli vydat. A upřímně – pokud přemýšlíte nad tím, jak využít cloud ve vašem prostředí naplno, tak byste automaticky měli přemýšlet nad automatizací.

Na první pohled může Infrastructure as Code vypadat komplikovaně, ale věřte mi, že jakmile si vyzkoušíte nasadit několik komponent do vašeho prostředí a seznámíte se s celým konceptem IaC, už pravděpodobně nebudete chtít vytvářet vaše prostředí „ručně“. K tématu se ještě vrátíme v některém z příštích článků naší Encyklopedie cloudu.