Защо в Ansible не можем напълно да използваме декларативния подход във всички playbook-и?

Ansible се стреми към декларативност, описвайки желаното състояние на системата. Въпреки това, пълната декларативност е ограничена поради необходимостта от изпълнение на последователност от операции и зависимости между задачите, което понякога изисква императивен подход за правилното постигане на крайното състояние. Някои модули или задачи могат да изискват изпълнение на действия в определен ред или да зависят от изхода на предишни задачи.

Например:

1. Условно изпълнение на задачи: Използването на when: за изпълнение на задача само при определени условия може да наруши чистотата на декларативността, тъй като условието често се базира на текущото (а не на желаното крайно) състояние или резултата от предишна задача.
2. Използване на register и changed_when: Запазването на изхода на задача в променлива (register) и използването на този изход в последващи задачи или за определяне дали е настъпила промяна (changed_when) също е императивен елемент.
3. Модули, които изпълняват команди: Модулите като command, shell, script са по природа императивни, тъй като просто изпълняват дадена команда, без да гарантират или описват крайното състояние.

Пример за императивен елемент:

- name: Уверете се, че услугата работи
  systemd:
    name: my_service
    state: started
  register: service_status

- name: Рестартирайте услугата, ако е работеща
  command: systemctl restart my_service
  when: service_status.changed

Тук, втората задача се изпълнява само ако първата е променила състоянието на услугата (например, я е стартирала). Това е императивно условие, зависещо от резултата от предишното действие.

Общо взето, Ansible предлага хибриден подход: опитва се да бъде максимално декларативен, но оставя място (понякога необходимо) за използване на императивни конструкции там, където логиката на внедряване и управление на конфигурацията го изисква.