Proč v Ansible nemůžeme plně využívat deklarativní přístup ve všech playbookách?

Ansible usiluje o deklarativnost tím, že popisuje požadovaný stav systému. Nicméně, úplná deklarativnost je omezena kvůli nutnosti provádět sekvenci operací a závislostí mezi úkoly, což někdy vyžaduje imperativní přístup k dosažení správného konečného stavu. Některé moduly nebo úkoly mohou vyžadovat provádění akcí v určitém pořadí nebo záviset na výstupu předchozích úkolů.

Například:

1. Podmíněné provádění úkolů: Použití when: k provedení úkolu pouze za určitých podmínek může narušit čistotu deklarativnosti, protože podmínka je často založena na aktuálním (a nikoli požadovaném konečném) stavu nebo výsledku předchozího úkolu.
2. Použití register a changed_when: Uložení výstupu úkolu do proměnné (register) a použití tohoto výstupu v následných úkolech nebo k určení, zda došlo ke změně (changed_when) je také imperativní prvek.
3. Moduly, které vykonávají příkazy: Moduly jako command, shell, script jsou svou podstatou imperativní, protože jednoduše vykonávají daný příkaz, aniž by garantovaly nebo popisovaly konečný stav.

Příklad imperativního prvku:

- name: Zajistit, že služba běží
  systemd:
    name: my_service
    state: started
  register: service_status

- name: Restartovat službu, pokud běží
  command: systemctl restart my_service
  when: service_status.changed

Zde se druhý úkol provádí pouze tehdy, pokud první změnila stav služby (například ji spustila). Jedná se o imperativní podmínku závislou na výsledku předchozí akce.

Obecně Ansible nabízí hybridní přístup: snaží se být co nejvíce deklarativní, ale ponechává prostor (někdy nutný) pro použití imperativních konstrukcí tam, kde to logika nasazení a správy konfigurace vyžaduje.