Kāpēc Ansible mēs nevaram pilnībā izmantot deklaratīvo pieeju visās playbook'ās?

Ansible cenšas būt deklaratīvs, aprakstot vēlamo sistēmas stāvokli. Tomēr pilnīga deklaratīvība ir ierobežota, jo ir nepieciešams izpildīt operāciju secību un atkarības starp uzdevumiem, kas dažreiz prasa imperatīvu pieeju, lai pareizi sasniegtu galīgo stāvokli. Daži moduļi vai uzdevumi var prasīt veikt darbības noteiktā secībā vai būt atkarīgi no iepriekšējo uzdevumu rezultātiem.

Piemēri:

1. Nosacījuma uzdevumu izpilde: when: izmantošana, lai izpildītu uzdevumu tikai noteiktos apstākļos, var pārkāpt tīru deklaratīvumu, jo nosacījums bieži balstās uz pašreizējo (nevis vēlamo galīgo) stāvokli vai iepriekšējo uzdevumu rezultātu.
2. register un changed_when izmantošana: Uzdevuma rezultāta saglabāšana mainīgajā (register) un šī rezultāta izmantošana nākamajās uzdevumos vai „izmaiņu” noteikšana (changed_when) arī ir imperatīvs elements.
3. Komandu izpildes moduļi: command, shell, script moduļi ir pēc savas dabas imperatīvi, jo tie vienkārši izpilda norādīto komandu, nenodrošinot un nesniedzot galīgā stāvokļa aprakstu.

Imperatīva elementa piemērs:

- nosaukums: Nodrošināt, ka pakalpojums darbojas
  systemd:
    nosaukums: my_service
    stāvoklis: sākts
  reģistrēt: pakalpojuma_stāvoklis

- nosaukums: Pārliecināties, ka pakalpojums ir sākts, ja tas ir
  komanda: systemctl restart my_service
  when: pakalpojuma_stāvoklis.changed

Šeit otrā uzdevuma izpilde notiek tikai tad, ja pirmā uzdevuma izmaiņas pakalpojuma stāvoklī (piemēram, tas tika palaists). Tas ir imperatīvs nosacījums, kas ir atkarīgs no iepriekšējās darbības rezultāta.

Kopumā, Ansible piedāvā elastīgu pieeju: tas cenšas būt pēc iespējas deklaratīvāks, bet ļauj izmantot imperatīvas struktūras tur, kur tas ir loģiski nepieciešams un konfigurācijas pārvaldībā.