Deklarativní konfigurace systémů a infrastruktury

Deklarativní konfigurace

Deklarativní konfigurace je přístup ke správě systémů, při kterém správce popisuje žádoucí cílový stav infrastruktury a softwaru, zatímco samotný nástroj rozhoduje, jak tohoto stavu dosáhnout. Na rozdíl od imperativního stylu (krok za krokem „jak to udělej“) se deklarativní styl soustředí na „co má platit“. Tento posun umožňuje idempotentní nasazení, automatickou opravu odchylek (drift remediation), lepší škálování a vyšší odolnost vůči chybám. V praxi se s ním setkáme v nástrojích Ansible (deklarativní úmysl nad imperativními moduly), Puppet (model prostředků a kompilace katalogu) a Chef (zdrojový model a konvergence).

Imperativní vs. deklarativní přístup

  • Imperativní: přesná sekvence příkazů (procedura). Vysoká kontrola, ale zároveň vysoká kognitivní zátěž a náchylnost k chybám při změně podmínek.
  • Deklarativní: popis stavu (balíček nginx má být present, služba enabled a running, soubor má mít obsah a práva). Nástroj sám zvolí kroky a zachová idempotenci.
  • Hybridní: běžná je kombinace: deklarativní data + imperativní handlers pro změny závislé na událostech (např. restart služby po změně konfigurace).

Klíčové vlastnosti deklarativní konfigurace

  • Idempotence: opakované spuštění vede ke stejnému výsledku bez vedlejších efektů.
  • Konvergence: systém se z libovolného výchozího stavu přibližuje k cílovému stavu, dokud ho nedosáhne.
  • Detekce a náprava driftu: průběžná kontrola odchylek od deklarovaného stavu a jejich automatické nebo řízené opravy.
  • Oddělení dat a logiky: proměnné, inventář, šablony a role oddělují „co“ od „jak“.
  • Determinismus a auditovatelnost: stejné vstupy ⇒ stejné výstupy; možnost reprodukovatelných buildů a auditní stopa.

Model prostředků, závislosti a pořadí

Deklarativní nástroje modelují systém jako graf prostředků (resources) a jejich závislostí. Plánovač z grafu odvodí pořadí změn a provede pouze to, co je nezbytné.

  • Prostředek (resource): např. balíček, služba, soubor, uživatel, pravidlo firewallu.
  • Atributy: cílový stav (verze, povolení, šablona obsahu, vlastník, práva).
  • Závislosti: výslovné (require, notify) nebo implicitní (soubor vyžaduje balíček poskytující binárku).
  • Řešení konfliktů: cykly v grafu jsou chybou návrhu; korektní modul by měl být idempotentní a transakční v rámci svého prostředku.

Jak fungují jednotlivé nástroje

  • Ansible: playbooky v YAML definují stavy úloh nad inventářem hostitelů. Ansible je agentless (SSH/WinRM), moduly provádějí operace idempotentně a vrací changed/ok. Orchestrace je sekvenční, deklarativní úmysl se vyjadřuje parametry modulů (např. state: present, enabled: true), zatímco komplexní kroky lze skrýt do rolí. Handlers reagují na změny (např. restart služby po úpravě konfigurace).
  • Puppet: manifesty definují prostředky a jejich vlastnosti. Master kompiluje katalog pro klienta (agenta) podle faktů (Facter), Hiera poskytuje data. Agent periodicky porovnává aktuální stav s katalogem a konverguje; drift je automaticky opravován.
  • Chef: recipes a resources deklarují stav systému. Chef client běží konvergenční smyčku, používá ohai pro fakta a datové tašky. Makroekonomika je podobná Puppet: agent na uzlu periodicky zajišťuje cílový stav.

Životní cyklus: od deklarace ke změně

  1. Shromáždění faktů: informace o platformě, balíčkovacím systému, síťovém prostředí.
  2. Evaluace pravidel a šablon: proměnné, role, podmínky, šablony konfigurací.
  3. Plánování: vytvoření grafu změn, výpočet závislostí, detekce nutných zásahů.
  4. Aplikace: provedení idempotentních operací, vyhodnocení změn (changed), spuštění handlerů.
  5. Ověření a report: validace stavu, notifikace a metriky pro audit a monitoring.

Idempotence v praxi

  • Čtení-před-zápisem: modul nejprve zjistí aktuální stav a změní pouze odlišnosti.
  • Konfigurační šablony: deterministický render (např. Jinja2, ERB) a atomická výměna souboru; změna pouze pokud se liší hash/obsah.
  • Bezpečný restart: restart služby pouze při změně relevantních artefaktů.
  • Transakčnost: v rámci prostředku s rollbackem při selhání (např. záloha původního souboru).

Drift management a samoopravné systémy

Configuration drift vzniká manuálními zásahy, rozdílnými verzemi či dočasnými hotfixy. Agentní nástroje (Puppet, Chef) drift automaticky detekují a vrací systém do cílového stavu na základě katalogu. U Ansible se drift typicky řeší periodickým spouštěním playbooků (cron/runner) nebo přechodem na pull režim a integrací s inventářem v CMDB.

Oddělení dat a logiky: role, proměnné, šablony

  • Role a moduly: zapouzdřují opakovaně použitelnou logiku (instalace, konfigurace, služba).
  • Datové vrstvy: group_vars/host_vars v Ansible, Hiera v Puppet, data bags v Chef – umožňují různé hodnoty pro prostředí (dev/test/prod), region, velikost.
  • Šablony: generují konfigurace z deklarativních strukturovaných dat; zajišťují konzistenci napříč uzly.

Orchestrace vs. konfigurace

Deklarativní konfigurace řeší stav uzlu. Orchestrace řeší souhru více uzlů a závislosti mezi službami (např. DB před aplikací, LB po aplikaci). Ansible často slouží jako orchestrace nad deklarativními rolemi; Puppet/Chef lze rozšířit o řídicí nástroje nebo kombinovat s Terraform (infrastruktura) a Kubernetes (běhové prostředí) v modelu GitOps.

Bezpečnost, tajemství a compliance jako kód

  • Tajemství: Ansible Vault, HashiCorp Vault, KMS/HSM – šifrované proměnné a dynamické secret enginy.
  • Hardening: bezpečnostní role/profily (CIS Benchmarks) a policy as code (InSpec, OpenSCAP) pro kontinuální validaci.
  • Minimální oprávnění: spouštění modulů s omezenými právy, become jen když je nezbytné, sudoers s granularitou.

Testování a kvalita: od lintingu po integrační testy

  • Linting a statická analýza: ansible-lint, yamllint, Puppet PDK, Cookstyle/Rubocop.
  • Jednotkové a integrační testy: Molecule (Ansible) s Docker/Podman/Cloud, rspec-puppet, Test Kitchen (Chef), Serverspec/InSpec pro verifikaci stavu.
  • Canary a postupné rollouty: aplikace změn na vybraný vzorek uzlů, měření dopadu, následné rozšíření.

GitOps a správa změn

Git je jediný zdroj pravdy pro kód konfigurací i data. CI/CD pipeline provádí linting, testy, sestavení artefaktů, podepisování a nasazení. Pull-request recenze zavádí princip čtyř očí, change tickets a automatizované changelogy zvyšují auditovatelnost. GitOps rozšiřuje tento princip na běhové prostředí (operátor sleduje repo a konverguje cluster).

Škálování a výkon

  • Paralelizace: Ansible forks, sharding inventáře; u agentů horizontální škálování masterů/kompilátorů.
  • Cache a fakta: ukládání faktů, opětovné použití spojení, lokální zrcadla repozitářů, minimalizace shell kroků.
  • Determinismus: fixní verze balíčků, zámky závislostí, repozitáře artefaktů (APT/YUM, Helm, PyPI proxy).

Srovnání: Ansible, Puppet, Chef

Aspekt Ansible Puppet Chef
Provozní model Agentless (push), volitelně pull Agent–server, periodická konvergence Agent–server, periodická konvergence
Jazyk YAML + moduly (Python) Puppet DSL + Hiera Ruby DSL + resources
Orchestrace Silná, snadné sekvencování Možná, přirozeně deklarativní graf Možná, deklarativní s Ruby idiomy
Idempotence Na úrovni modulů V jádru modelu V jádru modelu
Drift remediation Periodické běhy/cron Automaticky při každém běhu agenta Automaticky při každém běhu agenta
Učení/rychlý start Velmi rychlý Střední Střední

Integrace s dalšími deklarativními ekosystémy

  • Terraform: deklarativní správa infrastruktury (IaaC), vhodný pro provisioning zdrojů (VPC, VM, DNS), následně konfiguraci předává Ansible/Puppet/Chef.
  • Kubernetes: reconciliation loop a kontroléry; deklarativní manifesty, které cluster průběžně udržuje v cílovém stavu.
  • Nix/Guix: deklarativní správci balíčků a systémů s důrazem na reprodukovatelnost a neměnné obrazy.

Antipatterny a časté chyby

  • Vkládání shell úloh místo modulů ⇒ ztráta idempotence a přenositelnosti.
  • Míchání dat a logiky ⇒ horší znovupoužitelnost, složitá správa prostředí.
  • Skryté závislosti a implicitní pořadí ⇒ křehké playbooky/manifesty.
  • Chybějící testy a canary rollout ⇒ riziko výpadků při plošných změnách.
  • Manuální zásahy mimo nástroje ⇒ drift, který se později neočekávaně opraví.

Metriky a observabilita provozu

  • Change rate & success rate: kolik běhů provádí změny a kolik jich selže.
  • Mean Time to Recover (MTTR): doba návratu ke konvergovanému stavu po selhání.
  • Drift index: počet a závažnost odchylek vůči deklaracím.
  • Latence běhů: doba kompilace katalogu/realizace playbooku, vytížení masterů.

Doporučené postupy (best practices)

  • Začněte s tracking plánem konfigurací: definujte stavy, zdroje pravdy, konvence pojmenování.
  • Udržujte kód modulární: role/profily, malé prostředky, čisté rozhraní proměnných.
  • Zavádějte GitOps: PR review, CI lint + testy, podepisování a repozitáře artefaktů.
  • Zabezpečte tajemství: offload do Vaultu, rotace, audit přístupů.
  • Pracujte s canary nasazením a feature flags pro bezpečné změny.
  • Dokumentujte: katalog rolí/modulů, matice kompatibility OS/verzí, provozní runbooky.

Příklad end-to-end workflow (konceptuálně)

  1. Analytik/architekt definuje cílový stav služby (balíčky, soubory, služby, firewall).
  2. Ops vytvoří roli/manifest/recipe, přidá testy (Molecule/rspec/InSpec), spustí CI.
  3. PR schválí kolegové, CI publikovat verzi do repozitáře artefaktů.
  4. CD aplikuje změnu nejprve na canary skupinu, sleduje metriky a logy.
  5. Postupný rollout na celou flotilu, auditní záznam a report změn.

Závěr

Deklarativní konfigurace proměňuje správu systémů z řemesla „krok za krokem“ na inženýrskou disciplínu založenou na modelech, idempotenci a konvergenci. Nástroje jako Ansible, Puppet a Chef umožňují bezpečně a opakovatelně zavádět změny, minimalizovat configuration drift