47. Principy Infrastructure as Code a jejich výhody

Úvod a kontext

Doposud jsme se v kurzu bavili o tom, jak spravovat aplikace (Docker,
Kubernetes) a jak je automaticky sestavovat a nasazovat (CI/CD). Zbývá
poslední, stejně důležitý kus skládačky: jak vznikla a jak se spravuje
samotná infrastruktura, na které to všechno běží — virtuální
servery, sítě, databáze, load balancery, DNS záznamy, Kubernetes
clustery samotné. Infrastructure as Code (IaC) je přístup, kdy se
infrastruktura definuje a spravuje stejně jako aplikační kód: textovými
soubory ve verzovacím systému, ne ručními kliky v cloudové konzoli.
Tato lekce vysvětluje principy IaC obecně; následující lekce se věnují
konkrétnímu nástroji Terraform.

Teorie

Problém ruční správy infrastruktury

Ruční vytváření serverů přes webovou konzoli cloudového providera
(tzv. „ClickOps“) má vážné dlouhodobé problémy:

• Neopakovatelnost — nikdo si nepamatuje přesně, jaké nastavení
  bylo v konzoli zaškrtnuté před půl rokem; nové prostředí (staging,
  testovací) se těžko přesně zopakuje.
• Chybí historie a audit — kdo, kdy a proč změnil bezpečnostní
  skupinu nebo velikost instance, se dá dohledat jen z cloudových logů
  (pokud vůbec jsou zapnuté), ne z jasné, čitelné historie.
• Configuration drift — reálný stav infrastruktury se postupně
  rozchází s jakoukoliv dokumentací, protože se mění ad-hoc, mimo
  jakýkoliv proces.
• Škáluje se špatně — vytvořit ručně stovky podobných zdrojů (např.
  fronty, buckety pro každého zákazníka) je pomalé a chybové.

Deklarativní vs. imperativní přístup

IaC nástroje se dělí na dva přístupy:

• Imperativní — skript popisuje kroky, jak infrastrukturu
  vytvořit („vytvoř VPC, pak v ní vytvoř subnet, pak spusť instanci“).
  Podobá se běžnému skriptování (Bash, Ansible v základním použití
  moduly command/shell). Problém: skript musí sám řešit, co dělat,
  když zdroj už existuje, nebo co dělat při částečném selhání.
• Deklarativní — soubor popisuje požadovaný výsledný stav
  („má existovat VPC s tímto CIDR blokem a jeden subnet v ní“), a
  nástroj sám vypočítá, jaké kroky jsou potřeba k dosažení tohoto
  stavu z aktuálního stavu. Terraform i většina moderních Ansible
  modulů (ne syrové shell/command) jsou deklarativní.

Deklarativní přístup je dnes v IaC převažující, protože je odolnější —
opakované spuštění stejné definice nevytváří duplicitní zdroje, jen
sladí realitu s definicí.

Idempotence

Klíčovou vlastností dobrého IaC nástroje je idempotence — spuštění
téhož kódu vícekrát za sebou vede vždy ke stejnému výslednému stavu,
ne k vytvoření duplicitních zdrojů nebo k chybě při druhém spuštění.
Pokud je infrastruktura již v požadovaném stavu, druhé spuštění by
nemělo změnit vůbec nic (tzv. "no-op" běh). Idempotence je to, co dělá
IaC bezpečné spouštět opakovaně, i automaticky v CI/CD.

Stav (state) a zdroj pravdy

Deklarativní nástroje potřebují nějakým způsobem vědět, co už existuje,
aby mohly spočítat rozdíl mezi požadovaným a aktuálním stavem. Terraform
si k tomu vede vlastní state soubor (podrobně v příští lekci);
Ansible naproti tomu stav typicky nevede a při každém běhu se dotazuje
přímo cílového systému, jestli je v požadovaném stavu (tzv.
"agentless", stateless přístup) — to je zásadní koncepční rozdíl mezi
oběma nástroji, který se probere podrobněji v lekcích o Ansible.

Kde IaC končí a kde začíná konfigurace

V praxi se často kombinují dva typy nástrojů:

• Provisioning nástroje (Terraform, CloudFormation, Pulumi) —
  vytvářejí a ruší samotné infrastrukturní zdroje: virtuální servery,
  sítě, databáze jako služba, DNS záznamy.
• Konfigurační nástroje (Ansible, Chef, Puppet) — konfigurují
  software uvnitř už existujících serverů: instalují balíčky,
  upravují konfigurační soubory, spouští služby.

Typický tok: Terraform vytvoří virtuální server → Ansible na něm
nainstaluje a nakonfiguruje aplikaci. Hranice mezi nimi není vždy ostrá
(Terraform umí i základní konfiguraci přes user_data, Ansible umí
i vytvářet cloudové zdroje přes moduly), ale rozdělení odpovědností
podle tohoto vzoru je zavedená praxe.

Praktický příklad

Srovnání imperativního a deklarativního přístupu na stejném úkolu —
zajistit, že v cloudu existuje úložný bucket. Imperativní Bash skript
musí sám ošetřit, že bucket už může existovat:

#!/usr/bin/env bash
set -euo pipefail

BUCKET_NAME="moje-appka-uploads"

if aws s3api head-bucket --bucket "$BUCKET_NAME" 2>/dev/null; then
    echo "Bucket už existuje, nic nedělám."
else
    aws s3api create-bucket --bucket "$BUCKET_NAME" --region eu-central-1 \
        --create-bucket-configuration LocationConstraint=eu-central-1
    echo "Bucket vytvořen."
fi

Deklarativní ekvivalent v Terraformu (syntaxe HCL bude podrobně
vysvětlena v následující lekci) jen popisuje co má existovat —
o kontrolu existence a o samotné kroky se stará nástroj:

resource "aws_s3_bucket" "uploads" {
  bucket = "moje-appka-uploads"
}

Spuštění terraform apply je bezpečné opakovat libovolně mnohokrát —
pokud bucket už v požadované podobě existuje, Terraform nic nezmění.

Shrnutí

Infrastructure as Code nahrazuje ruční, neopakovatelnou správu
infrastruktury přes konzoli verzovaným, recenzovatelným kódem. Klíčový
je rozdíl mezi imperativním přístupem (popisuje kroky) a deklarativním
přístupem (popisuje výsledný stav) — deklarativní přístup je dnes
převažující díky idempotenci, tedy vlastnosti, že opakované spuštění
vede vždy ke stejnému výsledku. Provisioning nástroje (Terraform)
a konfigurační nástroje (Ansible) řeší odlišné vrstvy problému a
v praxi se běžně kombinují.

Kontrolní otázky

1. Jaké jsou hlavní problémy ruční správy infrastruktury přes cloudovou
   konzoli?
2. Vysvětlete rozdíl mezi imperativním a deklarativním přístupem
   k infrastruktuře na vlastním příkladu.
3. Co znamená idempotence a proč je pro IaC nástroj klíčová vlastnost?
4. Mini cvičení: rozhodněte, zda by následující úkol patřil spíš pod
   provisioning (Terraform), nebo konfiguraci (Ansible), a zdůvodněte
   to: "nainstalovat a nastavit Nginx na existujícím virtuálním
   serveru".