Perché in Ansible non possiamo utilizzare completamente l'approccio dichiarativo in tutti i playbook?

Ansible mira alla dichiaratività descrivendo lo stato desiderato del sistema. Tuttavia, la dichiaratività completa è limitata a causa della necessità di eseguire una sequenza di operazioni e dipendenze tra le attività, il che a volte richiede un approccio imperativo per raggiungere correttamente lo stato finale. Alcuni moduli o attività possono richiedere di eseguire azioni in un ordine specifico o dipendere dall'output di attività precedenti.

Ad esempio:

1. Esecuzione condizionale delle attività: L'uso di when: per eseguire un'attività solo in determinate condizioni può violare la purezza dichiarativa, poiché la condizione si basa spesso sullo stato attuale (e non su quello finale desiderato) o sul risultato di un'attività precedente.
2. Utilizzo di register e changed_when: Salvare l'output di un'attività in una variabile (register) e usare tale output in attività successive o per determinare se c'è stato un cambiamento (changed_when) è anch'esso un elemento imperativo.
3. Moduli che eseguono comandi: Moduli come command, shell, script sono per natura imperativi, poiché semplicemente eseguono un comando dato senza garantire o descrivere lo stato finale.

Esempio di un elemento imperativo:

- name: Assicurarsi che il servizio sia in esecuzione
  systemd:
    name: my_service
    state: started
  register: service_status

- name: Riavviare il servizio se avviato
  command: systemctl restart my_service
  when: service_status.changed

Qui, la seconda attività viene eseguita solo se la prima ha modificato lo stato del servizio (ad esempio, l'ha avviato). Questo è un esempio di condizione imperativa dipendente dal risultato dell'azione precedente.

In generale, Ansible propone un approccio ibrido: cerca di essere il più dichiarativo possibile, ma lascia spazio (a volte necessario) all'uso di strutture imperative dove la logica di distribuzione e gestione della configurazione lo richiede.