¿Por qué en Ansible no podemos usar completamente el enfoque declarativo en todos los playbooks?

Ansible busca la declaratividad, describiendo el estado deseado del sistema. Sin embargo, la declaratividad completa está limitada debido a la necesidad de realizar una secuencia de operaciones y dependencias entre tareas, lo que a veces requiere un enfoque imperativo para lograr correctamente el estado final. Algunos módulos o tareas pueden requerir realizar acciones en un orden específico o depender de la salida de tareas anteriores.

Por ejemplo:

1. Ejecución condicional de tareas: El uso de when: para ejecutar una tarea solo bajo ciertas condiciones puede violar la pureza declarativa, ya que la condición a menudo se basa en el estado actual (y no en el estado final deseado) o en el resultado de una tarea anterior.
2. Uso de register y changed_when: Guardar la salida de una tarea en una variable (register) y usar esa salida en tareas posteriores o para determinar si hubo un cambio (changed_when) también es un elemento imperativo.
3. Módulos que ejecutan comandos: Los módulos como command, shell, script son por naturaleza imperativos, ya que simplemente ejecutan un comando dado sin garantizar ni describir el estado final.

Ejemplo de un elemento imperativo:

- name: Asegurar que el servicio esté en ejecución
  systemd:
    name: my_service
    state: started
  register: service_status

- name: Reiniciar el servicio si está en ejecución
  command: systemctl restart my_service
  when: service_status.changed

Aquí, la segunda tarea solo se ejecuta si la primera cambió el estado del servicio (por ejemplo, lo inició). Esto es una condición imperativa que depende del resultado de la acción anterior.

En general, Ansible ofrece un enfoque híbrido: intenta ser lo más declarativo posible, pero deja espacio (a veces necesario) para usar construcciones imperativas donde la lógica de despliegue y gestión de la configuración así lo requiera.