Ansible: architektura, instalace, inventory, ad-hoc

Ansible: architektura, instalace, inventory a první ad-hoc příkazy

V sérii o Dockeru na VPS jsme instalovali Docker, nastavovali Compose, stavěli Nginx s SSL a dokonce postavili cluster Docker Swarm z několika nodů. Každý z těchto kroků jsme dělali ručně: přihlásit se přes SSH, zadat příkazy, zkontrolovat výsledek. Pro jeden server je to v pořádku. Pro tři už je to citelně nudné. Pro třicet je to samostatná práce: třicet terminálů, třicetkrát stejné příkazy, a jistota, že na některém serveru se něco pokazí, a vy o tom zjistíte až později.

Ansible řeší přesně tento problém. Jednou popíšete požadovaný stav serverů (jaké balíčky jsou instalované, jaké služby běží, jaké soubory jsou na místě), a Ansible sám přivede do tohoto stavu libovolný počet strojů a při potřebě to zopakuje pokaždé stejně. Toto je první článek z desetidílné série: probereme, jak je Ansible postavený, jak ho instalovat, jak popsat své servery a jak spustit první příkazy bez jakéhokoliv playbooku. Dál série povede od jednoduchých playbooků k rolím, secrets, velkým infrastrukturám a automatickému nasazení z CI/CD.

1.1 Problém: desítky nebo stovky serverů bez ruční práce

Správa více serverů rukou má tři chronické problémy. Zaprvé rychlost: každá změna se násobí počtem strojů. Zadruhé drift: servery nastavené v různou dobu různými lidmi se postupně liší, a nikdo si už nepamatuje proč. Zatřetí reprodukovatelnost: když je potřeba další stejný server, instrukce existuje jen v hlavě někoho, nebo ve zastaralém textovém souboru.

Automatizace konfigurace nahrazuje ruční kroky popisem, který lze uložit do gitu, zkontrolovat, prohlédnout a zopakovat.

1.2 Skripty, Ansible nebo Chef/Puppet/Salt

Existují tři typické přístupy k tomuto problému, a liší se modelem práce, ne jen syntaxí.

Pro většinu týmů s desítkami serverů, VPS nebo vyhrazenými stroji dává právě Ansible nejlepší poměr mezi úsilím na startu a přínosem z automatizace.

1.3 Čtyři klíčové vlastnosti

• Agentless. Na řízených serverech se nemusí nic instalovat: žádný agent, žádný démon. Stačí SSH a Python.
• Běžné SSH jako transport. Ansible využívá to, co už je na každém Linux serveru. Pro Windows stroje jako řízené nody se používá WinRM (nebo SSH).
• Idempotence. Opakované spuštění stejného úkolu nerozbije stav. Modul zkontroluje aktuální stav, a pokud už odpovídá požadovanému, nic nemění a nahlásí „ok" místo „changed".
• YAML jako jazyk. Popis automatizace se čte bez speciálních znalostí, takže ho může přečíst a zkontrolovat i kolega, který Ansible nepsal.

Idempotenci se vyplatí probrat na příkladu, protože právě ona odlišuje Ansible od skriptů. Příkaz echo "line" >> /etc/file ve skriptu přidá řádek při každém spuštění, a po pěti spuštěních bude soubor mít pět stejných řádků. Modul Ansible, který popisuje „tento řádek musí být v tomto souboru", ověří přítomnost řádku a přidá ho jen jednou. Totéž s balíčky: state=present znamená „má být instalovaný", ne „instalovat znovu".

2. Architektura: jak to funguje

2.1 Tři komponenty

• Control node. Stroj, ze kterého spouštíte Ansible: notebook, CI server nebo bastion host. Tady je instalovaný Ansible, leží inventory, playbooky a SSH klíče. Control node běží na Linuxu nebo macOS; Windows je podporován jen přes WSL.
• Managed nodes. Cílové servery, které řídíte. Potřebují jen Python a přístup přes SSH k běžnému POSIX shellu.
• Inventory. Seznam a popis managed nodů: jaká mají jména a adresy, jak se k nim připojit a jak jsou seskupené.

2.2 Co se děje během spuštění

Každý úkol projde stejným cyklem:

1. Control node se připojí k serveru přes SSH.
2. Zkopíruje na něj malý Python modul s potřebnou logikou (do dočasného adresáře).
3. Spustí modul a sesbírá výsledek do JSON.
4. Vyčistí dočasné soubory.
5. Vrátí výsledek na control node, kde Ansible zobrazí stav: ok, changed nebo failed.

Z toho vyplývá zajímavý důsledek: protože se modul doručuje na server pokaždé znovu, u správy verzí nevznikají žádné problémy. Na samotných serverech není nic, co by bylo nutné aktualizovat.

2.3 Co na řízených serverech není potřeba

Žádný agent, žádný neustále běžící démon, žádný otevřený port kromě SSH. To zjednodušuje údržbu (nic se neaktualizuje) a zmenšuje plochu útoku (žádný další listener na síťovém portu).

2.4 Druhá strana mince: control node je potřeba chránit

Control node drží klíče k celému parku serverů, takže je to kritický uzel. Praktická pravidla: používejte samostatný SSH klíč jen pro automatizaci, chraňte ho passphrase nebo ho držte v ssh-agentu, omezte, kdo se může přihlásit na control node, a nikdy neukládejte jeho privátní klíč na sdílené stroje. O správě secrets promluvíme samostatně v 7. díle série (Ansible Vault).

2.5 Požadavky na Python na řízených serverech

Moduly Ansible se spouští na serveru, proto je potřeba Python. Na většině serverových images Debian, Ubuntu, AlmaLinux nebo Rocky je k dispozici hned po instalaci. V minimálních images (kontejnerech, některých cloudových images) nemusí být, a pak je potřeba ho nainstalovat před prvním spuštěním. Výjimku tvoří síťové moduly (běží na straně control nodu, bez Pythonu na zařízení) a modul raw, který vykonává příkaz bez Pythonu a právě proto se často používá pro úvodní instalaci Pythonu.

3. Instalace Ansible na control node

3.1 Dva balíčky: ansible a ansible-core

Před instalací se vyplatí znát, že existují dva balíčky. ansible-core je minimální: samotný jazyk, běhové prostředí a vestavěné moduly. ansible je plnější balíček „s bateriemi": totéž plus sada kolekcí vybraných komunitou. Kolekcím je věnován samostatný díl série (Ansible Galaxy a Collections, 6. díl), a na začátek se hodí libovolný z obou; plný balíček je pohodlnější, protože hned obsahuje většinu potřebných modulů.

3.2 Způsoby instalace

3.3 Doporučení: pipx

Pro CI server a VPS doporučujeme pipx. Je to praktická volba: Ansible se instaluje do samostatného virtuálního prostředí, nekonfliktuje se systémovým Pythonem a aktualizuje se jedním příkazem. Oficiální dokumentace označuje jako hlavní způsob pip, a pipx jako běžnou alternativu pro případy, kdy pip není dostupný kvůli politice OS. A na moderních Debianu a Ubuntu je to právě tak: systémový Python je označen jako „externally managed", a pip install bez dalších přepínačů tam odmítá fungovat. Proto je pipx přirozenou volbou.

# Ubuntu / Debian
sudo apt update
sudo apt install -y pipx
pipx ensurepath

# AlmaLinux / Rocky (po připojení EPEL)
sudo dnf install -y pipx
pipx ensurepath

# Samotná instalace
pipx install --include-deps ansible

Po pipx ensurepath otevřete nový terminál, aby se aktualizovala PATH. Pozdější aktualizace:

pipx upgrade --include-injected ansible

3.4 Instalace z Ubuntu PPA

sudo apt update
sudo apt install -y software-properties-common
sudo add-apt-repository --yes --update ppa:ansible/ansible
sudo apt install -y ansible

Pro Debian se novější verze instaluje ze stejného PPA, ale přes ruční připojení repozitáře s klíčem v /usr/share/keyrings/; přesné kroky s odpovídajícími kódovými jmény Debianu a Ubuntu jsou na oficiální stránce instalace pro jednotlivé OS.

3.5 Ověření

ansible --version
python3 --version

Příkaz ansible --version zobrazuje verzi ansible-core, cestu ke konfiguračnímu souboru, cestu k modulům a verzi Pythonu, pod kterou běží. Verzi plného balíčku ansible zobrazuje samostatný příkaz ansible-community --version.

3.6 Verze a požadavky na Python

K listopadu 2026 je aktuální větev plného balíčku ansible 14.x, běžící na ansible-core 2.21. Pro tuto verzi je na control nodu potřeba Python 3.12-3.14, a na řízených serverech Python 3.9-3.14. Z toho vyplývají dvě praktické věci:

• Starý Python na control nodu. V některých běžných distribucích je systémový Python starší než 3.12 (například Ubuntu 22.04 nebo Debian 12). Pak se vyplatí nainstalovat samostatný novější Python a ukázat na něj pipx (pipx install --python python3.12 --include-deps ansible), nebo vzít starší větev ansible-core.
• Velmi staré řízené servery. Pokud je na cílovém systému Python starší než 3.9, aktuální verze ansible-core s ním nemůže fungovat, a pro takové stroje je potřeba starší verze ansible-core.

Verze se mění několikrát za rok, takže před instalací se vyplatí ověřit tabulku podpory na stránce vydání oficiální dokumentace Ansible.

4. SSH klíče: bezheslový přístup

4.1 Proč hesla nefungují ve velkém měřítku

Ansible provádí akce na mnoha serverech najednou, a ptát se na heslo při každém spojení není možné. Navíc hesla pro SSH jsou i z hlediska bezpečnosti horší než klíče: lze je uhodnout, dostávají se do historie příkazů a jsou obtížně centrálně měnitelná. Proto je standardním přístupem SSH klíč.

4.2 Generování klíčového páru

Pokud ještě nemáte samostatný klíč pro automatizaci, vytvořte ho na control nodu:

ssh-keygen -t ed25519 -C "ansible-control" -f ~/.ssh/ansible_ed25519

Typ ed25519 je moderní, krátký a rychlý. Nástroj nabídne nastavení passphrase. Pro klíč, který řídí celý park serverů, je passphrase vhodná: abyste ho nemuseli zadávat pokaždé, přidejte klíč do ssh-agentu (ssh-add ~/.ssh/ansible_ed25519). Na CI serveru, kde se klíč používá bez účasti člověka, se obvykle ukládá do secrets platformy, o čem bude řeč v 10. díle.

4.3 Distribuce veřejného klíče

ssh-copy-id -i ~/.ssh/ansible_ed25519.pub admin@192.0.2.11

Tento příkaz je potřeba spustit pro každý řízený server. Na začátek se hodí libovolný existující účet s právy sudo (v příkladu admin). Později, ve 4. díle, vytvoříme samostatného uživatele pro automatizaci přímo pomocí Ansible, a teď je hlavní nastavit přístup.

4.4 Ruční ověření před prvním spuštěním

ssh -i ~/.ssh/ansible_ed25519 admin@192.0.2.11 "hostname && sudo -n true && echo sudo-ok"

Tento příkaz odpoví na tři otázky najednou: zda funguje přihlášení klíčem bez hesla, zda je správné jméno hostu a zda uživatel může vykonávat sudo bez vyžádání hesla. Přepínač -n způsobí, že sudo skončí chybou místo dotazu. Pokud ručně vše funguje, zafunguje i Ansible. Pokud ne, problém je třeba vyřešit hned, ne uprostřed vykonávání úkolu.

4.5 Oprávnění: sudo bez hesla nebo s heslem

Většina administrativních úkolů potřebuje root práva, která Ansible získává přes sudo (parametr become). Existují dva přístupy:

• Vyžádat heslo sudo pokaždé: přidejte k příkazům --ask-become-pass (-K). Bezpečnější, ale nepohodlné pro automatizaci.
• Povolit sudo bez hesla pro automatizačního uživatele: pohodlné pro CI a automatické nasazení, ale snižuje ochranu: kdo získá klíč, získá i root.

echo 'admin ALL=(ALL) NOPASSWD:ALL' | sudo tee /etc/sudoers.d/ansible
sudo chmod 440 /etc/sudoers.d/ansible
sudo visudo -cf /etc/sudoers.d/ansible

Poslední příkaz zkontroluje syntaxi souboru: chyba v sudoers může zablokovat přístup k sudo, proto se vyplatí kontrolovat vždy. Mějte otevřenou session s právy root, dokud se nepřesvědčíte, že nové pravidlo funguje.

4.6 Parametry připojení

Pokud se jména uživatelů, porty nebo klíče mezi servery liší, popisuje se to parametry hostu: ansible_user (kdo se připojuje), ansible_port (nestandardní port SSH), ansible_ssh_private_key_file (jaký klíč použít). Nastavují se v inventory nebo v konfiguraci, o čemž bude řeč dál.

4.7 První připojení a known_hosts

Při prvním připojení se SSH ptá, zda důvěřujete otisku klíče serveru. V automatizaci tato otázka zastaví vykonávání. Správné řešení je přidat otisky předem:

ssh-keyscan -H 192.0.2.11 192.0.2.12 198.51.100.21 >> ~/.ssh/known_hosts

Všimněte si: ssh-keyscan důvěřuje tomu, co odpoví server v okamžiku dotazu. U citlivých systémů ověřte otisky (ssh-keygen -lf) s tím, co zobrazuje panel providera nebo konzole serveru. Vypínat kontrolu klíčů hostu místo toho se nevyplatí, proč přesně, rozebereme v sekci o ansible.cfg.

5. Inventory: popisujeme infrastrukturu

Inventory je „mapa" vašeho parku: jaké servery existují, jak se jmenují, jak se k nim připojit a jak jsou seskupené. Ansible nehádá, kam se připojit: pracuje jen s těmi nody, které jsou popsané v inventory.

5.1 Dva formáty: INI a YAML

Ansible podporuje oba formáty „z krabice". INI je jednodušší a kratší, YAML lépe škáluje a je pohodlnější, když má host hodně proměnných. Stejný park v INI:

[webservers]
web1 ansible_host=192.0.2.11
web2 ansible_host=192.0.2.12

[databases]
db1 ansible_host=198.51.100.21 ansible_port=2222

[production:children]
webservers
databases

[all:vars]
ansible_user=admin
ansible_python_interpreter=/usr/bin/python3

A v YAML:

all:
  vars:
    ansible_user: admin
    ansible_python_interpreter: /usr/bin/python3
  children:
    webservers:
      hosts:
        web1:
          ansible_host: 192.0.2.11
        web2:
          ansible_host: 192.0.2.12
    databases:
      hosts:
        db1:
          ansible_host: 198.51.100.21
          ansible_port: 2222
    production:
      children:
        webservers:
        databases:

Adresy v příkladech jsou z rozsahů vyhrazených pro dokumentaci (192.0.2.0/24 a 198.51.100.0/24), nahraďte je svými.

5.2 Skupiny nodů

Skupiny jsou hlavní nástroj inventory: umožňují obracet se k mnoha serverům jedním jménem. Dvě skupiny existují vždy bez jakéhokoliv popisu: all (všechny hosty) a ungrouped (hosty, které nepatří do žádné jiné skupiny). Každý host patří alespoň do jedné z nich.

5.3 Vnořené skupiny

V INI se vnořenost zadává příponou :children v záhlaví skupiny (jako v příkladu [production:children]), v YAML klíčem children. Host z dceřiné skupiny automaticky patří i do rodičovské: web1 patří do webservers i do production. To je výhodné pro popisování samostatných prostředí: například skupiny staging a production, každá se svými webservers. Cyklické vztahy mezi skupinami jsou zakázané.

5.4 Proměnné na úrovni inventory

Parametry určující, jak se připojit:

• ansible_host: reálná adresa nebo DNS jméno, pokud se liší od jména hostu v inventory (v příkladu web1 je jen pohodlný název);
• ansible_port: port SSH, pokud není 22;
• ansible_user: uživatel pro připojení;
• ansible_python_interpreter: cesta k Pythonu na serveru. Explicitní hodnota odstraní varování o automaticky nalezeném interpretru a předejde chybám na systémech s více verzemi Pythonu.

Proměnné deklarované v sekci [all:vars] platí pro všechny hosty; proměnné skupiny (například [webservers:vars]) jen pro její členy; proměnné v řádku hostu mají nejvyšší priority mezi těmito třemi. Celý systém priority proměnných rozebereme ve 3. díle.

5.5 Rozsahy hostů

Pro stejnorodé servery není nutné vypisovat každý: zápis web[01:50].example.com vytvoří padesát hostů od web01 do web50. Krok se zadává třetím číslem (web[01:50:2] dá jen liché), podporovány jsou i písmenné rozsahy (db-[a:f].example.com).

5.6 Kde ukládat inventory

• Jeden soubor: pro malý park dostačuje. Jednoduché, vše na první pohled.
• Adresář (například inventory/ s několika soubory): Ansible čte všechny soubory v něm podle abecedy. Výhodné, když park roste nebo když se část inventory generuje automaticky (k tomu se dostaneme v 9. díle o dynamickém inventory). Pokud je jedna proměnná definována ve více souborech, vyhrává poslední podle abecedního pořadí, takže pořadí souborů lze kontrolovat prefixy (01-, 02-).

V každém případě ukládejte inventory do gitu spolu s dalším kódem automatizace, ale bez hesel a klíčů v otevřeném tvaru.

5.7 Kontrola inventory

ansible-inventory -i inventory/hosts.ini --list
ansible-inventory -i inventory/hosts.ini --graph

První příkaz vypíše vše, co Ansible „rozumí" o vašich hostech, ve formátu JSON, včetně proměnných. Druhý zobrazí strom skupin. Pro příklad výše bude vypadat přibližně takto:

@all:
  |--@production:
  |  |--@databases:
  |  |  |--db1
  |  |--@webservers:
  |  |  |--web1
  |  |  |--web2
  |--@ungrouped:

Zvykněte si provádět tuto kontrolu po každé změně inventory: hned ukáže chyby ve skupinách a proměnných, než se projeví jako „cizí" chování na serverech.

6. ansible.cfg: základní konfigurace

6.1 Kde Ansible hledá konfiguraci

Ansible prochází čtyři místa v tomto pořadí a použije první nalezený soubor. Ostatní soubory se ignorují, jejich obsah se neslučuje:

1. Soubor zadaný v proměnné prostředí ANSIBLE_CONFIG, pokud je nastavena;
2. ansible.cfg v aktuálním adresáři (projektová konfigurace);
3. ~/.ansible.cfg v domovském adresáři;
4. /etc/ansible/ansible.cfg (celosystémová).

Pro projekty je téměř vždy nejlepší druhá varianta: ansible.cfg leží v kořeni repozitáře spolu s inventory a playbooky, a všichni, kdo s repozitářem pracují, získají stejná nastavení. Jakou konfiguraci Ansible aktuálně používá, ukazuje řádek config file ve výstupu ansible --version.

6.2 Klíčové parametry

[defaults]
inventory = ./inventory/hosts.ini
remote_user = admin
private_key_file = ~/.ssh/ansible_ed25519
host_key_checking = True

• inventory: výchozí cesta k inventory, aby se -i nemuselo uvádět v každém příkazu;
• remote_user: uživatel pro připojení, pokud není uveden v inventory;
• private_key_file: výchozí klíč;
• host_key_checking: kontrola otisků klíčů hostů (výchozí zapnuto).

Které parametry jste změnili vůči výchozím hodnotám, lze zkontrolovat příkazem ansible-config dump --only-changed.

6.3 Proč host_key_checking = False jen pro testy

Mnoho návodů doporučuje vypnout kontrolu klíčů hostů, aby zmizela otázka o důvěře při prvním připojení. To funguje, ale zcela odstraňuje ochranu proti podvržení serveru (man-in-the-middle): Ansible se připojí k komukoliv, kdo odpoví na požadované adrese, a předá mu vše, co odesíláte na server, včetně souborů a proměnných. Pro experimenty na dočasných virtuálních strojích je to přijatelné. Pro produkci je správná cesta v kapitole 4.7: předem přidat otisky do known_hosts a kontrolu ponechat zapnutou.

7. Ad-hoc příkazy: Ansible bez playbooku

Ad-hoc příkaz je jedna akce vykonaná na jednom nebo více serverech přímo z příkazové řádky, bez psaní playbooku. Pro jednorázové operace je to nejrychlejší způsob.

7.1 Syntaxe

ansible <pattern> -m <module> -a "<argumenty>"

Tři části: pattern (na koho aplikovat), modul (co udělat) a argumenty modulu. Pokud modul není uveden, použije se ansible.builtin.command.

7.2 Pattern: na jaké hosty působit

Pro vyloučení v bash shellu je znak ! obvykle třeba uvést v jednoduchých uvozovkách: ansible 'webservers:!web2' -m ping, jinak se shell pokusí rozbalit ho jako odkaz na historii příkazů. Dodatečně lze libovolný pattern zúžit volbou --limit (-l), například -l web1.

7.3 Užitečné moduly pro každodenní úkoly

Modul ping nemá nic společného s ICMP pingem: skutečně se přihlásí na server přes SSH, spustí malý Python kód a vrátí „pong". Úspěšná odpověď tedy znamená, že funguje SSH přístup, Python i oprávnění, a to je podstatně víc než „server odpovídá na síti".

7.4 Příklady

# Jsou všechny servery dostupné
ansible all -m ping

# Uptime všech webserverů (command výchozí)
ansible webservers -a "uptime"

# Volné místo, pipe potřebuje shell
ansible all -m ansible.builtin.shell -a "df -h / | tail -1"

# Restart Nginx s právy root
ansible webservers -b -m ansible.builtin.service -a "name=nginx state=restarted"

# Fakta o systému (filtr podle jména)
ansible web1 -m ansible.builtin.setup -a "filter=ansible_distribution*"

Volba -b (--become) zapíná zvýšení oprávnění přes sudo. Dodatečně se budou hodit -u (připojit se jiným uživatelem), -i (zadat inventory, pokud není v konfiguraci) a -K (vyžádat heslo sudo).

7.5 Režim kontroly: --check

Příznak --check (-C) spustí „zkoušku": Ansible ukáže, co by udělal, ale na serverech nic nemění. Dobře funguje s moduly, které umí předvídat výsledek (apt, copy, service a další). Ale command a shell se v režimu kontroly obvykle přeskakují, protože Ansible nemůže vědět, co udělá libovolný příkaz. Zkouška tedy není univerzální záruka bezpečnosti, vyplatí se ji používat spolu s kontrolou na jednom serveru.

7.6 Paralelismus: forks

Ve výchozím stavu Ansible pracuje s pěti servery najednou (parametr forks). Pro park stovky strojů to znamená dvacet sekvenčních „vln". Zvýšit paralelismus pro jednotlivé spuštění lze volbou -f:

ansible all -f 20 -m ping

Víc není vždy lepší: každý fork spotřebovává paměť a spojení na control nodu, a příliš agresivní hodnota se může zaseknout o limity SSH nebo sítě. Jemné ladění výkonu (forks, pipelining, SSH multiplexing) rozebereme v 8. díle.

8. První reálný scénář

Shrneme probrané do jednoho praktického scénáře: zkontrolovat park, podívat se na stav a bezpečně aktualizovat balíčky na webserverech.

8.1 Krok 1: je vše dostupné

ansible all -m ping

Úspěšná odpověď vypadá takto:

web1 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

Dokud ping neprojde na všech nodech, dál nemá smysl pokračovat.

8.2 Krok 2: kontrola uptime na všech nodech

ansible all -a "uptime"

web1 | CHANGED | rc=0 >>
 12:41:03 up 12 days,  3:07,  1 user,  load average: 0.08, 0.03, 0.01

Všimněte si slova CHANGED, přestože příkaz uptime nic nezměnil. Je to stejná vlastnost modulu command z kapitoly 1: neví, zda příkaz změnil stav, proto vždy nahlásí „changed". Není to chyba, ale připomínka, že pro skutečně idempotentní akce jsou potřeba specializované moduly, ne command.

8.3 Krok 3: aktualizace balíčků na webserverech

Nejdřív zkouška na jednom serveru, pak reálné spuštění na něm, a až potom na všech:

# Debian / Ubuntu: zkouška na jednom hostu
ansible webservers -l web1 -b -m ansible.builtin.apt -a "update_cache=yes upgrade=dist" --check

# Reálné spuštění na jednom hostu
ansible webservers -l web1 -b -m ansible.builtin.apt -a "update_cache=yes upgrade=dist"

# Po kontrole: na všech webserverech
ansible webservers -b -m ansible.builtin.apt -a "update_cache=yes upgrade=dist"

# Pro RHEL-podobné systémy
ansible webservers -b -m ansible.builtin.dnf -a "name='*' state=latest"

Taková posloupnost („canary": nejdřív jeden, pak všichni) je návyk, který zachraňuje před situací, kdy problematická aktualizace současně položí celý park. Pro produkční servery v 8. díle rozebereme direktivu serial, která automatizuje postupnou aktualizaci po skupinách.

8.4 Jak číst výstup

Nejčastější zmatek u začátečníků: UNREACHABLE znamená problém s přístupem (SSH), a FAILED problém s vykonáním (modul, oprávnění, Python). Jsou to různé třídy problémů, a diagnostika začíná na různých místech.

9. Omezení ad-hoc a co dál

9.1 Kde ad-hoc končí

Ad-hoc příkazy jsou ideální pro jednorázové operace: zkontrolovat dostupnost, podívat se na verzi, restartovat službu, sesbírat fakta. Ale nehodí se pro opakovatelné scénáře: sekvence akcí se neuchovává, logika („pokud nastala změna, restartuj službu") se nevyjadřuje, a výsledek nelze zkontrolovat ani prohlédnout v gitu. Jakmile se chytíte, že zadáváte stejný dlouhý příkaz potřetí, je čas na playbook.

9.2 Co jsme udělali v tomto článku

• Pochopili jsme, jak je Ansible postavený: control node, managed nodes, inventory, vykonávání přes SSH bez agenta.
• Instalovali jsme ho na control node a ujasnili si verze a požadavky na Python.
• Nastavili jsme bezheslový přístup klíči a připravili servery na automatizaci.
• Popsali jsme park serverů v inventory se skupinami a proměnnými.
• Nastavili jsme ansible.cfg, aniž bychom vypínali kontrolu klíčů hostů.
• Vykonali jsme první ad-hoc příkazy a naučili se číst jejich výstup.

9.3 Co dál v sérii

Další článek je věnován playbookům: souborům, které popisují posloupnost úkolů, umožňují používat handlers (restart služby jen po změně konfigurace), smyčky a tagy. Právě tam se objeví skutečná idempotentní automatizace. Dál série povede od proměnných a šablon Jinja2 k praktickému nastavení reálného VPS (4. díl: nginx, firewall, SSH klíče, uživatelé), rolí, Ansible Galaxy, Vaultu pro secrets, škálování na stovky nodů, dynamického inventory a konečně automatického nasazení přes Forgejo nebo GitHub Actions. Pro ty, kdo se chtějí předem seznámit s CI/CD, je začátek tohoto tématu rozebraný v článku „Co je CI/CD: od ručního deploy k automatizovaným pipelines".

Často kladené otázky