Por que no Ansible não podemos usar completamente a abordagem declarativa em todos os playbooks?

O Ansible procura a declaratividade, descrevendo o estado desejado do sistema. No entanto, a declaratividade completa é limitada devido à necessidade de executar uma sequência de operações e dependências entre tarefas, o que às vezes requer uma abordagem imperativa para alcançar corretamente o estado final. Alguns módulos ou tarefas podem exigir realizar ações numa ordem específica ou depender da saída de tarefas anteriores.

Por exemplo:

1. Execução condicional de tarefas: O uso de when: para executar uma tarefa apenas sob certas condições pode violar a pureza declarativa, pois a condição muitas vezes baseia-se no estado atual (e não no estado final desejado) ou no resultado de uma tarefa anterior.
2. Uso de register e changed_when : Guardar a saída de uma tarefa numa variável (register) e usar essa saída em tarefas posteriores ou para determinar se houve uma alteração (changed_when) também é um elemento imperativo.
3. Módulos que executam comandos: Módulos como command, shell, script são por natureza imperativos, pois simplesmente executam um comando dado sem garantir nem descrever o estado final.

Exemplo de um elemento imperativo:

- name: Garantir que o serviço está em execução
  systemd:
    name: my_service
    state: started
  register: service_status

- name: Reiniciar o serviço se estiver em execução
  command: systemctl restart my_service
  when: service_status.changed

Aqui, a segunda tarefa só é executada se a primeira alterou o estado do serviço (por exemplo, iniciou-o). Isto é uma condição imperativa que depende do resultado da ação anterior.

De modo geral, o Ansible oferece uma abordagem híbrida: tenta ser o mais declarativo possível, mas deixa espaço (às vezes necessário) para usar construções imperativas onde a lógica de implantação e gestão de configuração assim o exige.