Event-Driven Ansible: Automatiza Respuestas a Eventos 2026

Event-Driven Ansible convierte tu automatización en algo reactivo: en lugar de lanzar playbooks a mano o esperar a que salte un cron, la infraestructura responde sola en cuanto ocurre algo. Una alerta de Prometheus, un webhook de GitHub o un mensaje en Kafka disparan el playbook correcto en segundos, sin que nadie abra una terminal a las tres de la madrugada.

Event-Driven Ansible es el salto natural cuando ya tienes playbooks y roles maduros: dejar de preguntarte cuándo ejecuto esto y empezar a definir ante qué señal debe ejecutarse solo.

Qué es Event-Driven Ansible y en qué se diferencia de un playbook

Un ansible-playbook clásico tiene un ciclo de vida muy simple: arranca, ejecuta sus tareas contra el inventario y termina. Es imperativo y puntual. Event-Driven Ansible invierte ese modelo con un proceso llamado ansible-rulebook que arranca y no termina: se queda escuchando indefinidamente una o varias fuentes de eventos y sólo actúa cuando un evento cumple una condición que tú has escrito.

La diferencia práctica es enorme. Con cron, tu ventana de reacción es el intervalo del cron. Con monitorización tradicional, alguien recibe una alerta y decide qué hacer. Con Event-Driven Ansible, la señal y la respuesta viven en el mismo artefacto versionado en Git, y el tiempo entre ambas se mide en segundos.

Por debajo hay una pieza que conviene conocer: el motor de reglas Drools, escrito en Java. Es lo que permite evaluar condiciones complejas sobre un flujo continuo de eventos sin que el rendimiento se hunda, y también la razón de que necesites una JVM en el nodo de control.

Arquitectura de Event-Driven Ansible: fuentes, reglas y acciones

Event-Driven Ansible se apoya en un único fichero YAML llamado rulebook. No es un playbook, aunque se le parezca: un rulebook no describe tareas, describe de dónde vienen los eventos y qué hacer con ellos. Tiene cuatro piezas.

Fuentes de eventos disponibles

Las fuentes se dividen en dos familias. Las de endpoint se quedan escuchando a que alguien les hable (webhook, alertmanager), mientras que las de sondeo consultan activamente un recurso (url_check, file_watch). Las integraciones con buses de mensajes como kafka o aws_sqs_queue mantienen una conexión persistente.

Un detalle importante que rompe muchos tutoriales antiguos: los plugins básicos migraron al espacio de nombres eda.builtin. Si copias un ejemplo de 2023 verás ansible.eda.webhook; hoy la forma recomendada es eda.builtin.webhook. La compatibilidad hacia atrás sigue existiendo, pero conviene escribir lo nuevo bien desde el principio. Tienes el catálogo completo en la documentación de fuentes de eventos.

Acciones que puede disparar una regla

• run_playbook: ejecuta un playbook local. Es la acción más habitual.
• run_module: lanza un módulo suelto sin necesidad de playbook.
• run_job_template: dispara una plantilla de trabajo en AWX o en Ansible Automation Platform.
• set_fact y post_event: alimentan el propio motor para encadenar reglas.
• debug y print_event: imprescindibles mientras desarrollas.
• shutdown: termina el proceso de forma ordenada.

Esa acción run_job_template es la bisagra que conecta este mundo con el que ya conoces: si mantienes un servidor AWX como torre de control de automatización, los eventos pueden lanzar directamente tus plantillas existentes, con su RBAC y su registro de ejecuciones intactos.

Requisitos previos para instalar Event-Driven Ansible

Aquí es donde más gente tropieza. Las dependencias de Event-Driven Ansible son más pesadas que las de Ansible a secas, justamente por el motor de reglas en Java.

La JVM no es opcional ni un capricho: sin un Java 17 o superior en el PATH, el proceso ni siquiera arranca. En Debian y Ubuntu basta con instalar el paquete openjdk-17-jdk; en familias RHEL, java-17-openjdk-devel.

Instala Event-Driven Ansible paso a paso

Ejecuta lo siguiente en tu nodo de control, el mismo desde el que ya lanzas playbooks. Instalamos primero las dependencias de sistema y después el binario dentro de un entorno virtual, para no ensuciar los paquetes de Python del sistema operativo.

sudo apt update
sudo apt install -y openjdk-17-jdk python3-pip python3-venv

python3 -m venv ~/eda
source ~/eda/bin/activate

pip install ansible-core ansible-rulebook
ansible-galaxy collection install ansible.eda

Comprueba que todo quedó en su sitio antes de seguir. Si java -version devuelve algo menor que 17, revisa JAVA_HOME; es el fallo número uno en instalaciones nuevas.

java -version
ansible-rulebook --version
ansible-galaxy collection list | grep eda

La colección oficial vive en el repositorio ansible/event-driven-ansible y se publica también en Ansible Galaxy, donde puedes fijar la versión exacta si necesitas reproducibilidad en tus despliegues.

Tu primer rulebook con Event-Driven Ansible

Vamos a construir el caso más didáctico de Event-Driven Ansible: un webhook que escucha en el puerto 5000 y, cuando recibe un mensaje concreto, ejecuta un playbook. Crea primero el playbook que hará el trabajo real, reiniciar-servicio.yml.

---
- name: Responder a un evento de servicio caído
  hosts: all
  become: true
  tasks:
    - name: Reiniciar el servicio afectado
      ansible.builtin.service:
        name: "{{ servicio | default('nginx') }}"
        state: restarted

    - name: Registrar la actuación
      ansible.builtin.lineinfile:
        path: /var/log/eda-actuaciones.log
        line: "{{ ansible_date_time.iso8601 }} reinicio automático"
        create: true

Fíjate en que es un playbook completamente normal: no tiene nada específico de este modelo. Esa es justo la gracia — todo tu catálogo de playbooks existente sirve tal cual, incluidos los que ya hayas validado con Molecule para probar roles y playbooks.

Ahora el rulebook, webhook-rulebook.yml, que es la pieza nueva. Aquí es donde defines la fuente y la condición que debe cumplirse.

---
- name: Escuchar eventos de monitorizacion
  hosts: all
  sources:
    - eda.builtin.webhook:
        host: 0.0.0.0
        port: 5000
        token: "cambia-esto-por-un-secreto"

  rules:
    - name: Reiniciar si el servicio esta caido
      condition: event.payload.estado == "caido"
      action:
        run_playbook:
          name: reiniciar-servicio.yml

    - name: Registrar cualquier otro evento
      condition: event.payload.estado != "caido"
      action:
        debug:

La sintaxis de condition merece atención: opera sobre el objeto event, que contiene el JSON recibido bajo la clave payload. Puedes encadenar comparaciones con and y or, comprobar existencia con is defined y usar operadores numéricos. La documentación oficial de ansible-rulebook recoge la gramática completa.

Arrancar y probar

Lanza el proceso con el inventario que ya uses. Verás que el prompt no vuelve: está escuchando.

ansible-rulebook --rulebook webhook-rulebook.yml -i inventory.yml --verbose

Desde otra terminal, simula el evento. Si la condición encaja, en la primera ventana verás arrancar el playbook casi al instante.

curl -H 'Content-Type: application/json' \
     -H 'Authorization: Bearer cambia-esto-por-un-secreto' \
     -d '{"estado": "caido", "servicio": "nginx"}' \
     http://127.0.0.1:5000/endpoint

Si no ocurre nada, no toques el rulebook todavía: cambia la condición por event is defined y usa la acción print_event. Ver el payload crudo tal y como llega resuelve el 90 % de los problemas en dos minutos.

Casos de uso reales de Event-Driven Ansible

El ejemplo del webhook es un punto de partida, pero el valor de Event-Driven Ansible aparece cuando lo conectas a lo que ya tienes montado.

• Remediación de alertas. Alertmanager envía la alerta a un rulebook en vez de a una persona. Si ya tienes Prometheus desplegado con Ansible, el circuito se cierra sin piezas nuevas.
• Cumplimiento continuo. Un cambio de configuración fuera de proceso genera un evento y el playbook devuelve la máquina a su estado declarado.
• Respuesta a incidentes de seguridad. Un patrón sospechoso en los logs dispara el bloqueo, complementando defensas reactivas como Fail2ban gestionado con Ansible.
• Integración con CI/CD. Un webhook de GitHub tras un merge lanza el despliegue, en paralelo o como alternativa a tu servidor Jenkins automatizado con Ansible.
• Escalado reactivo. Una métrica de saturación en una cola provoca el aprovisionamiento de trabajadores adicionales.

Buenas prácticas de Event-Driven Ansible en producción

Pasar de la demo al servicio real exige unas cuantas decisiones sobre Event-Driven Ansible que nadie te cuenta en el primer tutorial.

Ejecútalo como servicio, no en una sesión SSH

Como el proceso es de larga duración, necesita supervisión. Una unidad de systemd con reinicio automático es el mínimo razonable.

[Unit]
Description=Motor de reglas ansible-rulebook
After=network-online.target

[Service]
User=eda
WorkingDirectory=/opt/eda
ExecStart=/opt/eda/venv/bin/ansible-rulebook \
  --rulebook /opt/eda/webhook-rulebook.yml \
  -i /opt/eda/inventory.yml
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

Actívalo con systemctl enable --now ansible-rulebook y vigila journalctl -u ansible-rulebook -f los primeros días.

Controla los eventos duplicados

Una alerta que repica cada treinta segundos puede lanzar el mismo playbook veinte veces seguidas. Usa throttle con once_within para agrupar eventos en una ventana temporal, y diseña los playbooks para que sean idempotentes: si se ejecutan dos veces, el resultado debe ser el mismo.

Filtra antes de evaluar

Los filtros de eventos como eda.builtin.json_filter o eda.builtin.normalize_keys limpian el payload antes de que llegue al motor de reglas. Normalizar claves con guiones a guiones bajos evita condiciones ilegibles y errores difíciles de diagnosticar.

Versiona los rulebooks igual que el resto

Un rulebook es código, y define comportamiento automático sobre producción. Debe pasar por revisión, vivir en Git y desplegarse con el mismo rigor que aplicas a tu infraestructura declarativa con GitOps.

Troubleshooting de Event-Driven Ansible

Una regla de oro para depurar Event-Driven Ansible: valida siempre el playbook por separado antes de culpar al motor de reglas. Si funciona a mano y no funciona por evento, el problema está en la condición o en las variables, casi nunca en el motor.

Conclusión: cuándo merece la pena Event-Driven Ansible

No todo necesita ser reactivo. Si tu operación se apaña con playbooks programados y el volumen de incidencias es bajo, añadir un motor de reglas y una JVM sólo suma complejidad. El punto de inflexión llega cuando repites la misma intervención manual una y otra vez, siempre ante la misma señal: ahí es donde Event-Driven Ansible deja de ser un juguete y empieza a devolverte horas.

Empieza pequeño. Elige una sola alerta recurrente y de bajo riesgo, escribe el rulebook, déjalo en modo debug una semana entera y comprueba cuántas veces habría acertado. Cuando la confianza esté ahí, cambia la acción por el playbook real. Ese camino incremental es mucho más sólido que automatizar veinte respuestas el primer día.

Si quieres seguir por esta línea, el artículo introductorio de Red Hat complementa bien lo visto aquí, y en el resto de tutoriales de Ansible del blog tienes los cimientos sobre los que apoyar tus reglas.

Preguntas frecuentes sobre Event-Driven Ansible