Infraštruktúra je dnes málokedy statická – projekty sa nasadzujú rýchlejšie, prostredia sa kopírujú medzi stagingom a produkciou, pribúdajú nové servery, kontajnery, siete aj bezpečnostné pravidlá. To, čo kedysi stačilo nastaviť raz a „nechať bežať“, sa dnes mení prakticky neustále. Práve v tomto kontexte vznikol pojem Infrastructure as Code (skrátene IaC) – infraštruktúra ako kód.
Infrastructure as Code znamená, že servery, siete, úložiská, DNS záznamy či firewall pravidlá nedefinujeme manuálne v administračnom rozhraní, ale popisujeme ich pomocou konfiguračných súborov. Tieto súbory sú verzované, podliehajú code review a prechádzajú automatizovaným procesom nasadenia rovnako ako aplikačný kód. Takže ide o zásadnú zmenu myslenia: infraštruktúra sa prestáva spravovať ako „manuálna konfigurácia“ a začína sa správať ako aplikačný softvér.
Bez Infrastructure as Code sa moderná infraštruktúra stáva neudržateľnou. Manuálne zásahy vedú k nezdokumentovaným zmenám, rozdielom medzi prostrediami a bezpečnostným rizikám. IaC preto nie je len automatizácia – je to spôsob, ako získať kontrolu nad komplexitou.
Naša prvá časť článku sa zameriava na širší kontext Infrastructure as Code. Vysvetlíme si, ako sa IaC historicky vyvinulo, aký má vzťah k DevOps, prečo sa čoraz viac presadzuje GitOps prístup a akú rolu zohráva bezpečnosť. Pozrieme sa na rozdiely medzi cloudovým a on-prem použitím, objasníme deklaratívny a imperatívny prístup a stručne predstavíme najznámejšie nástroje. Cieľom je vytvoriť pevný teoretický základ, na ktorom bude možné v druhej časti postaviť detailné porovnanie konkrétnych riešení.
Čo je Infrastructure as Code
Infrastructure as Code (IaC) je prístup k správe a provisioning (zriaďovaniu) infraštruktúry prostredníctvom strojovo čitateľných definícií, namiesto manuálnej konfigurácie cez terminál alebo grafické rozhranie. Takto zapísané definície sa typicky ukladajú v systéme verzovania (napr. Git) a svoje prostredia nasadzujú automatizovane. IaC môže pokrývať širokú škálu zdrojov od fyzických „bare-metal“ serverov až po virtuálne stroje a sieťové prvky.
Myšlienka automatizácie infraštruktúry sa začala formovať s nástupom cloudových služieb po roku 2000, keď potreba rýchleho zriadenia a aktualizácie prostredí začala prevyšovať možnosti manuálnej správy. V roku 2006, so vznikom napr. AWS EC2, organizácie začali riešiť nové výzvy škálovania a reprodukovateľnosti prostredí, čo viedlo k myšlienke písať infraštruktúru ako kód.
IaC v sebe spája princípy, ktoré boli dlho používané v inom kontexte softvérového vývoja – verzovanie, recenzie zmien, testovanie a automatizované nasadenia.
Infrastructure as Code zavádza princíp single source of truth – jediným autoritatívnym zdrojom konfigurácie je verzovaný kód, nie aktuálny stav infraštruktúry.
Idempotencia v Infrastructure as Code
Idempotencia znamená, že opakované spustenie IaC konfigurácie vedie vždy k rovnakému výslednému stavu bez vedľajších efektov. Nástroj najskôr porovná aktuálny stav so želaným stavom a vykoná iba nevyhnutné zmeny. Ak je infraštruktúra už v správnom stave, nič sa nemení.
Táto vlastnosť je zásadná pre spoľahlivú automatizáciu a bezpečné nasadzovanie zmien v produkcii. Bez idempotencie by opakované spustenie mohlo spôsobovať nepredvídateľné výsledky alebo nekonzistentné prostredie.
Metódy a prístupy: deklaratívny vs imperatívny model
V Infrastructure as Code sa rozlišujú dva základné modely:
- Deklaratívny model – opisuje, ako má infra vyzerať (napr. Terraform, CloudFormation). Systém sa potom stará o to, ako tento stav dosiahnuť.
- Imperatívny model – opisuje sekvenciu krokov, ktoré musia byť vykonané, aby sa dosiahol požadovaný stav.
Jedným z kľúčových princípov moderných Infrastructure as Code nástrojov je porovnávanie deklarovaného a aktuálneho stavu infraštruktúry. Keď definujeme infraštruktúru v konfiguračných súboroch, opisujeme tzv. želaný stav (desired state). Nástroj následne komunikuje s cieľovou platformou prostredníctvom API a zisťuje, aký je aktuálny stav zdrojov (current state). Rozdiel medzi týmito dvoma stavmi sa vyhodnotí a systém pripraví sériu operácií, ktoré sú potrebné na zosúladenie reality s deklaráciou v kóde. Tento mechanizmus je základom deklaratívneho prístupu a umožňuje opakovateľné a kontrolované zmeny bez potreby manuálne sledovať každý detail infraštruktúry.
Na to, aby tento proces fungoval spoľahlivo, väčšina IaC nástrojov používa tzv. state file – súbor so stavom, ktorý obsahuje informácie o tom, aké zdroje boli vytvorené a ako sú prepojené. Tento stav umožňuje nástroju presne identifikovať, ktoré objekty spravuje a aké zmeny sa majú vykonať. Pred samotnou aplikáciou zmien sa typicky generuje execution plan (alebo plan), ktorý transparentne zobrazí, čo bude vytvorené, upravené alebo odstránené. Tento plánovací krok je zásadný z pohľadu bezpečnosti a kontroly, pretože umožňuje zmeny najprv skontrolovať a schváliť, až potom ich reálne aplikovať na produkčnú infraštruktúru.
V tímovom prostredí je práca so stavom a plánom ešte dôležitejšia. State file by nemal byť uložený lokálne na počítači jednotlivca, ale v centralizovanom, zabezpečenom úložisku (napríklad remote backend), ktoré podporuje uzamykanie (locking). Uzamykanie zabraňuje tomu, aby dvaja členovia tímu aplikovali zmeny súčasne a poškodili stav infraštruktúry. Štandardnou praxou je, že každý návrh zmeny infraštruktúry prechádza cez pull request, v rámci ktorého sa automaticky v CI/CD pipeline vygeneruje execution plan. Tím tak presne vidí, aký dopad bude mať zmena ešte pred jej aplikovaním. Až po schválení a kontrole sa spustí samotné „apply“, čím sa zabezpečí auditovateľnosť, zníženie rizika chýb a konzistentnosť medzi prostrediami. Takýto workflow robí z Infrastructure as Code nielen technický nástroj, ale riadený proces spolupráce.
Rozdiel medzi Infrastructure as Code a Configuration Management
Infrastructure as Code sa zameriava na provisioning zdrojov – vytváranie serverov, sietí, databáz alebo cloud služieb. Configuration Management sa sústreďuje na konfiguráciu už existujúcich systémov – inštaláciu balíkov, úpravu nastavení a správu služieb.
V praxi sa oba prístupy kombinujú: IaC vytvorí infraštruktúru a nástroje na konfiguráciu zabezpečia jej správne nastavenie. Ide o dve vrstvy tej istej automatizačnej architektúry.
Prečo nestačí Bash skript
Bash skript je forma automatizácie, ale nepracuje s deklarovaným stavom infraštruktúry ani so správou stavu. Typicky vykonáva sekvenciu príkazov bez toho, aby vedel vyhodnotiť rozdiel medzi aktuálnym a požadovaným stavom.
IaC nástroje naopak porovnávajú realitu s deklaráciou, generujú plán zmien a zabezpečujú kontrolovanú aplikáciu. Skripty môžu byť užitočné, no samy o sebe nepredstavujú plnohodnotný Infrastructure as Code prístup.
Cloud vs. on-prem: kde sa IaC používa
Infrastructure as Code sa dnes široko využíva v:
- public cloudoch – kde poskytovatelia ponúkajú API pre takmer každý zdroj (virtuálne stroje, siete, identity, databázy atď.); IaC tu unikátne umožňuje rýchly, opakovateľný a prevediteľný provisioning bez manuálneho klikania.
- on-prem / bare metal prostrediach – kde IaC začína pokrývať provisioning operačných systémov, sieťových prvkov a ďalších komponentov (napr. v kombinácii s PXE boot, konfiguračnými manažérmi a orchestrátormi).
Aj keď je cloud prirodzené prostredie pre IaC, rovnaké princípy automatizácie a verzovania platia aj pre on-prem infraštruktúru.
GitOps a bezpečnostný kontext
GitOps je prax, ktorá dopĺňa IaC tým, že používa Git ako jediný zdroj pravdy pre infraštruktúru aj aplikácie. GitOps definuje, ako sa zmeny aplikácií a infry dostávajú do produkčného prostredia – pomocou merge requestov a CI/CD pipeline, ktoré nasadzujú zmeny automaticky. Odlišuje sa od tradičného „push“ prístupu tým, že infra agent (pull mechanizmus) sleduje Git a synchronizuje aktuálny stav s tým deklarovaným.
V oblasti bezpečnosti (DevSecOps) IaC zdôrazňuje potrebu:
- policy-as-code,
- analýzy kódu pred nasadením,
- auditovateľnosti a spätnej vysledovateľnosti zmien.
Nesprávne nastavené IaC šablóny môžu viesť k hromade bezpečnostných rizík – napríklad otvorené sieťové porty, nesprávne nastavené prístupové práva alebo únik citlivých údajov (napr. databázové heslá priamo v konfigurácii), čo vyžaduje skenovanie a validáciu ako súčasť CI/CD pipeline.
Vendor lock-in a cloud-agnostic prístup
Vendor lock-in znamená závislosť od konkrétneho cloud poskytovateľa, najmä ak využívate jeho špecifické managed služby. Migrácia do iného prostredia potom môže byť náročná. Cloud-agnostic prístup sa snaží túto závislosť minimalizovať používaním štandardných technológií a prenositeľných architektúr. Zvyšuje flexibilitu, no často znamená aj väčšiu prevádzkovú zodpovednosť.
Tému vendor lock-in a cloud-agnostic prístupu spomíname preto, že Infrastructure as Code síce zjednodušuje automatizáciu, ale automaticky negarantuje prenositeľnosť architektúry. Mnohí si myslia, že ak majú infra definovanú v IaC, môžu jednoducho „prepnúť provider“ a presunúť prostredie inde. V realite však IaC len opisuje infraštruktúru – neodstraňuje rozdiely medzi platformami.
Pri zmene providera (napríklad z AWS na Azure) sa často ukáže, že jednotlivé služby nemajú priamy ekvivalent. Managed databáza, load balancer či identity systém fungujú inak, majú odlišné parametre a správanie. Aj keď použijete rovnaký nástroj (napr. Terraform), musíte prepísať zdrojové definície, upraviť architektúru a otestovať kompatibilitu aplikácie. Ešte výraznejší rozdiel nastáva pri prechode z cloudu na bare metal – namiesto volania API pre hotové služby musíte riešiť provisioning serverov, storage, sieť, vysokú dostupnosť a zálohovanie manuálne alebo pomocou ďalších nástrojov.
Prechod je teda možný, ale nie je to len technická zmena providera v konfigurácii. Ide o architektonickú zmenu, ktorá ovplyvňuje spôsob škálovania, bezpečnosti aj prevádzky. Cloud-agnostic prístup môže migráciu zjednodušiť, no úplnú nezávislosť od platformy prakticky nikdy nezaručí.
IaC v kontexte DevOps a tradičných control panelov
IaC je dnes považované za kľúčový prvok praxe DevOps. DevOps sa snaží prelomiť tradičné bariéry medzi vývojom a prevádzkou tým, že zjednotí procesy, nástroje a kultúru. V tomto zmysle IaC pomáha tímom výrazne zlepšiť:
- automatizáciu vytvorenia prostredí,
- zlepšenie transparentnosti konfigurácií,
- skrátenie času nasadenia a zvýšenie spoľahlivosti.
Na rozdiel od tradičných control panelov a ručných nastavení, ktoré každé prostredie robia jedinečným a často neudržateľným, IaC umožňuje definovať želaný stav infraštruktúry a automaticky zabezpečiť jeho zosúladenie s realitou.
Top 5 nástrojov IaC v krátkosti
Tieto nástroje patria medzi najčastejšie používané::
- Terraform – univerzálny IaC nástroj s deklaratívnym jazykom HCL, širokou komunitou a podporou mnohých providerov.
- Pulumi – moderný IaC umožňujúci definovať infra pomocou bežných programovacích jazykov (JavaScript, Python, Go atď.).
- AWS CloudFormation – natívne riešenie pre AWS infra, deklaratívne šablóny.
- Ansible / Chef / Puppet / Salt – tradičné konfiguračné manažéry s IaC schopnosťami, často používané aj pre on-prem scenáre.
- Kubernetes-native prístupy (napr. GitOps s Flux/ArgoCD) – implicitne rieši infra ako rekurentne synchronizovaný stav.
Detailne sa na ne pozrieme v pokračovaní.
Ako to funguje
Vo všeobecnosti sa dá povedať, že každý Infrastructure as Code nástroj potrebuje určitý mechanizmus, ktorým sa „napojí“ na cieľovú infraštruktúru, no forma tohto mechanizmu sa líši podľa filozofie konkrétneho nástroja. V nástrojoch ako Terraform alebo OpenTofu ide o explicitné providery – pluginy, ktoré komunikujú s API konkrétnej platformy (AWS, Azure, VMware, Kubernetes a podobne). Bez providera by nástroj nevedel, ako preložiť deklaráciu v kóde na reálne API volania. Podobne funguje aj Pulumi, hoci z pohľadu používateľa sa viac tvári ako klasická programátorská knižnica; aj tu však pod kapotou existujú balíky a integrácie, ktoré zabezpečujú komunikáciu s konkrétnym cloudom alebo systémom. V tomto zmysle možno povedať, že väčšina moderných IaC nástrojov potrebuje určitý „adapter“ alebo integračnú vrstvu medzi deklaráciou a cieľovým prostredím.
Pri cloud-natívnych nástrojoch, ako sú CloudFormation alebo Azure Bicep, je situácia trochu iná. Tam provider ako samostatný plugin nepotrebujeme, pretože nástroj je priamo súčasťou ekosystému daného cloudu a implicitne používa jeho API. Funkčne však ide o ten istý princíp – IaC definícia sa musí nejako pretransformovať na konkrétne operácie nad infraštruktúrou. Rovnako aj pri Kubernetes-centric prístupoch (napríklad Crossplane) existujú „providers“, ktoré prekladajú Kubernetes objekty na zdroje v externých systémoch. Z toho vyplýva, že hoci terminológia sa líši (provider, plugin, driver, resource plugin), architektonicky všetky IaC nástroje potrebujú integračný mechanizmus, ktorý im umožní komunikovať s cieľovou platformou. Rozdiel nie je v tom, či ho používajú, ale v tom, ako je navrhnutý a nakoľko je pre používateľa viditeľný.
Configuration drift
Drift vzniká vtedy, keď sa reálny stav infraštruktúry začne líšiť od stavu definovaného v IaC kóde. Ak máte server vytvorený cez Terraform/OpenTofu/Pulumi a následne sa prihlásite do cloudu alebo na server a manuálne zmeníte konfiguráciu – napríklad:
- upravíte veľkosť disku,
- otvoríte port vo firewalle,
- alebo pridáte ďalší zdroj mimo IaC,
tak ste vytvorili rozdiel medzi „zdrojom pravdy“ (repozitár) a realitou. To je drift. Drift narúša jeden zo základných princípov IaC: že Git (alebo iný VCS) je jediný zdroj pravdy o infraštruktúre.
Konkrétne riziká:
- Pri ďalšom apply môže nástroj vašu manuálnu zmenu prepísať.
- Tím netuší, že sa niečo zmenilo – chýba auditovateľnosť.
- Prostredia sa začnú líšiť (napr. staging vs. produkcia).
- Bezpečnostné pravidlá sa môžu obísť mimo review procesu.
- Pri disaster recovery nebude infra obnovená tak, ako v skutočnosti bežala.
V praxi sa drift často objaví práve pri „rýchlej oprave v produkcii“, ktorú niekto neskôr zabudne premietnuť späť do IaC. Z technického pohľadu áno – je to porušenie modelu IaC. Z praktického pohľadu sa však občas stane, že manuálny zásah je nevyhnutný (napr. incident).
Rozdiel medzi zodpovedným a nezodpovedným prístupom je v tom, či:
- Manuálnu zmenu následne zapracujete do IaC.
- Spustíte kontrolu/plán, aby ste videli rozdiel.
- Máte proces, ktorý drift deteguje.
Najlepšia prax
Ak používate IaC, platí jednoduché pravidlo:
Ak sa niečo zmení mimo kódu, je to dočasné riešenie – a musí sa to vrátiť späť do kódu.
Inak sa z IaC postupne stane len „približná dokumentácia“ namiesto skutočného zdroja pravdy a stráca svoje benefity.
Zhrnutie
Infrastructure as Code nie je len ďalší nástroj do CI/CD pipeline. Je to strategický prístup k správe infraštruktúry, ktorý zásadne mení spôsob, akým organizácie premýšľajú o serveroch, sieťach a bezpečnosti. Historicky vzniklo ako odpoveď na potrebu škálovateľnosti a opakovateľnosti, no dnes predstavuje štandard v moderných DevOps a DevSecOps procesoch.
V spojení s GitOps modelom sa Git stáva jediným zdrojom pravdy a infraštruktúra sa riadi rovnakými pravidlami ako aplikačný vývoj. Z pohľadu bezpečnosti je IaC zároveň príležitosťou aj rizikom – umožňuje automatizované vynucovanie politík, no zároveň vyžaduje dôslednú kontrolu a skenovanie definícií ešte pred ich nasadením.
Či už ide o public cloud, VPS, virtualizačné prostredie alebo bare-metal infraštruktúru, princípy IaC zostávajú rovnaké: definovať želaný stav, verzovať ho, automatizovať jeho nasadenie a minimalizovať manuálne zásahy. Výber konkrétneho nástroja je až druhý krok. Kľúčové je pochopiť samotnú filozofiu – infra ako kód znamená infra ako riadený, opakovateľný a kontrolovaný proces.
V druhej časti sa preto detailne pozrieme na konkrétne nástroje Infrastructure as Code, ich architektúru, rozdiely, licenčné modely a vhodné scenáre použitia.
