Dlaczego w Ansible nie możemy w pełni korzystać z podejścia deklaratywnego we wszystkich playbookach?

Ansible dąży do deklaratywności, opisując pożądany stan systemu. Jednak pełna deklaratywność jest ograniczona ze względu na konieczność wykonania sekwencji operacji i zależności między zadaniami, co czasami wymaga podejścia imperatywnego, aby poprawnie osiągnąć końcowy stan. Niektóre moduły lub zadania mogą wymagać wykonania działań w określonej kolejności lub zależeć od wyniku poprzednich zadań.

Na przykład:

1. Warunkowe wykonywanie zadań: Użycie when: do wykonania zadania tylko w określonych warunkach może naruszać czystość deklaratywności, ponieważ warunek często opiera się na bieżącym (a nie pożądanym końcowym) stanie lub wyniku poprzedniego zadania.
2. Użycie register i changed_when: Zapisywanie wyniku zadania do zmiennej (register) i używanie tego wyniku w kolejnych zadaniach lub do określenia, czy nastąpiła zmiana (changed_when) jest również elementem imperatywnym.
3. Moduły wykonujące polecenia: Moduły typu command, shell, script są z natury imperatywne, ponieważ po prostu wykonują dane polecenie, nie gwarantując i nie opisując końcowego stanu.

Przykład elementu imperatywnego:

- name: Upewnij się, że usługa działa
  systemd:
    name: my_service
    state: started
  register: service_status

- name: Zrestartuj usługę, jeśli jest uruchomiona
  command: systemctl restart my_service
  when: service_status.changed

Tutaj, drugie zadanie jest wykonywane tylko wtedy, gdy pierwsze zmieniło stan usługi (np. ją uruchomiło). To jest warunek imperatywny zależny od wyniku poprzedniego działania.

Ogólnie, Ansible oferuje podejście hybrydowe: stara się być jak najbardziej deklaratywny, ale pozostawia miejsce (czasami konieczne) na użycie konstrukcji imperatywnych tam, gdzie wymaga tego logika wdrożenia i zarządzania konfiguracją.