De ce în Ansible nu putem folosi pe deplin abordarea declarativă în toate playbook-urile?

Ansible urmărește declarativitatea, descriind starea dorită a sistemului. Cu toate acestea, declarația completă este limitată din cauza necesității de a executa o secvență de operațiuni și dependențe între sarcini, ceea ce uneori necesită o abordare imperativă pentru a atinge corect starea finală. Unele module sau sarcini pot necesita efectuarea acțiunilor într-o anumită ordine sau pot depinde de rezultatul sarcinilor anterioare.

De exemplu:

1. Executarea condiționată a sarcinilor: Utilizarea when: pentru a executa o sarcină doar în anumite condiții poate încălca puritatea declarativă, deoarece condiția se bazează adesea pe starea curentă (și nu pe cea dorită finală) sau pe rezultatul unei sarcini anterioare.
2. Utilizarea register și changed_when: Salvarea rezultatului unei sarcini într-o variabilă (register) și utilizarea acestuia în sarcini ulterioare sau pentru a determina dacă a avut loc o modificare (changed_when) este, de asemenea, un element imperativ.
3. Module care execută comenzi: Module precum command, shell, script sunt, prin natura lor, imperative, deoarece execută pur și simplu o comandă dată, fără a garanta sau descrie starea finală.

Exemplu de element imperativ:

- name: Asigurați-vă că serviciul rulează
  systemd:
    name: my_service
    state: started
  register: service_status

- name: Repornirea serviciului dacă rulează
  command: systemctl restart my_service
  when: service_status.changed

Aici, a doua sarcină se execută doar dacă prima a schimbat starea serviciului (de exemplu, l-a pornit). Aceasta este o condiție imperativă, dependentă de rezultatul acțiunii anterioare.

În general, Ansible oferă o abordare hibridă: încearcă să fie cât mai declarativ posibil, dar lasă spațiu (uneori necesar) pentru utilizarea construcțiilor imperative acolo unde logica de implementare și gestionare a configurației o cere.