Cuando trabajamos con Ansible, una de las herramientas más útiles para optimizar nuestras automatizaciones son los handlers. Estos nos permiten ejecutar acciones específicas solo cuando ciertas tareas se completan con éxito, evitando así operaciones innecesarias que podrían consumir recursos o generar interrupciones sin motivo.
Los handlers son, en esencia, tareas que se definen de forma muy similar a las habituales, con la misma sintaxis y estructura, pero con una diferencia clave: no se ejecutan automáticamente en el flujo lineal del playbook. En lugar de eso, se activan solo cuando una tarea anterior les notifica que ha habido un cambio o que se ha cumplido una condición particular.
Para entenderlo mejor, imaginemos que queremos instalar Apache 2 en un servidor. Usamos el módulo apt para asegurarnos de que el paquete esté presente y actualizamos la caché. Sin embargo, instalar Apache no siempre implica que el servicio se inicie automáticamente. Por eso, queremos que el servidor web se reinicie solo si la instalación o alguna configuración ha cambiado.
Podríamos poner una tarea que reinicie el servicio directamente, pero eso no sería muy eficiente ni declarativo, porque el reinicio se ejecutaría siempre, incluso si no hubo cambios. Aquí es donde entran los handlers: definimos un bloque llamado handlers donde declaramos la tarea que reinicia el servidor web, por ejemplo, usando el módulo service para reiniciar Apache 2.
Luego, en la tarea que instala Apache, añadimos la opción notify con el nombre del handler que queremos activar, por ejemplo, reinicie el servidor web. De este modo, Ansible solo ejecutará el handler si la tarea de instalación realmente hizo algún cambio, como instalar el paquete o modificar la configuración.
Un ejemplo de cómo quedaría el playbook sería:
- hosts: servidores
become: yes
tasks:
- name: Instalar Apache 2
apt:
name: apache2
state: present
update_cache: yes
notify: reinicie el servidor web
handlers:
- name: reinicie el servidor web
service:
name: apache2
state: restarted
Cuando ejecutamos este playbook, Ansible primero instala Apache 2. Si la instalación implica un cambio (por ejemplo, si Apache no estaba instalado antes), entonces se activa el handler y se reinicia el servicio. Si ejecutamos el playbook nuevamente y Apache ya está instalado, la tarea no hará cambios y el handler no se ejecutará, evitando reinicios innecesarios.
Este mecanismo nos permite mantener nuestras automatizaciones limpias, eficientes y declarativas, asegurando que las acciones que pueden afectar al sistema solo se realicen cuando realmente son necesarias. Así, podemos gestionar servicios, reinicios o cualquier otra acción dependiente de cambios previos de forma controlada y elegante.