En esta publicación del blog vamos a hablar sobre cómo Ansible puede agilizar el proceso de gestión de cualquier evento que tenga lugar en un entorno digital.
Primero de todo, ¿qué es un evento? Un evento se considera como cualquier suceso que se lleve a cabo en un entorno digital. Ejemplos de ello serían:
- Hacer click en el carrito de la compra.
- Equivocarte al introducir tu contraseña.
- Intento de intrusión en una red.
- Servicio de una aplicación caído.
Algunos de estos eventos nos sirven a nivel de negocio, a través de la utilización del análisis de datos. Con otros puede que sea necesario actuar sobre el sistema para evitar pérdida de servicio o cualquier tipo de motivo crítico para el entorno.
El procedimiento convencional determina que estos sucesos se deben gestionar de la siguiente manera: un operador recibe el evento y, en base a lo sucedido, escala al equipo que deba actuar o actúa él mismo de forma manual. Esto puede conllevar horas de respuesta y un margen de error humano que posiblemente no sean aceptables.
Por ello, herramientas como Ansible han ayudado a las organizaciones a estandarizar este tipo de actuaciones. En este caso, si al operador le llega un evento para el cual es necesario ejecutar un procedimiento, el operador puede tener instrucciones de ejecutar una automatización. Aun así, tenemos margen de error al no haber eliminado el componente humano de la ecuación y cierto grado de retraso en la acción necesaria, dado que: el evento se ha desencadenado, lo ha recibido el operador y el operador ha tenido que decidir qué hacer.
¿Qué es Event-Driven Ansible?
Ansible por sí solo no es capaz de recibir un evento y decidir qué hacer con él. Red Hat inició el desarrollo de la tecnología open-source Event-Driven Ansible, EDA de ahora en adelante, que permite escuchar eventos de varias fuentes y, en base al contenido de estos, poder tomar una decisión de la acción a ejecutar.
Es un componente con soporte de Red Hat y una comunidad, que permite a las compañías no tener que desarrollar a medida una solución para cada fuente de eventos y así poder focalizar el esfuerzo en el desarrollo de la automatización que actuará sobre este suceso.
EDA recibe los eventos gracias a diferentes plugins, permitiendo así extender la solución ante orígenes de datos no convencionales. Ejemplos de fuentes son:
- Kafka
- Alertmanager
- Azure Service Bus
- Watchdog
- Webhook
¿Y cómo le decimos a EDA que obtenga los datos de una fuente en concreto y realice una acción cuando se cumpla cierta condición? La respuesta es mediante los Rulebooks. Un Rulebook es un fichero YAML parecido a un Playbook de Ansible donde podemos definir el origen de los eventos y las condiciones que se deben cumplir para ejecutar diversas acciones.
En la siguiente imagen podéis ver un ejemplo de Rulebook, con cada elemento anterior detallado:
- En sources especificaremos la lista de fuentes a utilizar en este Rulebook. Pueden ser una o varias, dependiendo del caso de uso.
- Rules será una lista como sources, donde cada elemento tendrá una condición y una acción. Cuando el evento llega, se evalúan una por una las condiciones hasta que una se cumple. En ese momento, se ejecutará la acción. En este caso ejecutaríamos un Playbook de Ansible para arrancar o parar un servicio.
Además de ejecutar un Playbook, una regla permite, entre otros:
- Ejecutar módulos directamente.
- Generar un evento.
- Definir una variable.
- Ejecutar un Job Template en AWX/AAP.
Caso de uso: evento con origen Kafka
Imaginemos que en nuestra organización usamos Kafka como herramienta de streaming de eventos. En ella, otra herramienta publica eventos en Kafka sobre el cambio de estado en un servicio en concreto, httpd. Lo que buscamos es que a través de EDA podamos arrancar de nuevo, para volver a dar servicio a nuestros clientes.
El Rulebook será el siguiente:
Donde ejecutaremos el Playbook restart_service.yml en el caso de que recibamos un evento para el servicio httpd y estado stopped.
El contenido del Playbook será el siguiente:
Este imprime un mensaje diciendo que está reiniciando el servicio. (Obviamente, no lo hará ya que no le decimos que lo haga, es puramente informativo).
Finalmente, podemos ejecutar el Rulebook para escuchar los eventos entrantes con el comando ansible-rulebook.
Si ahora producimos mensajes a través de Kafka como el de la siguiente imagen, no veremos nada.
En cambio, produciendo un mensaje como el siguiente, veremos que el Rulebook reacciona al cumplirse la única condición:
El proceso del Rulebook seguirá en marcha, por lo que si recibe un nuevo evento que cumpla la condición, volverá a actuar como hemos especificado.
En definitiva, hemos conseguido ejecutar una automatización a partir de un evento procedente de Kafka. Este caso de uso se puede extender realizando una acción más cuando el servicio pase al estado de started, o incluso poder actuar sobre cualquier servicio, no solo el httpd.
Conclusión
Las organizaciones están inundadas con eventos de muchos orígenes distintos: ServiceNow, Alertmanager, Kafka… Si es necesario actuar para todos ellos, el coste operacional puede verse afectado, además de los tiempos de respuesta y el posible error humano. EDA nos ofrece una solución para combatir estos costes. Así, los equipos se pueden centrar en desarrollar diferentes procesos a reacción de cada tipo de evento, sin tener que preocuparse por recibir, decidir y ejecutar estos procedimientos de forma manual.
Referencias
Documentación de EDA: https://ansible.readthedocs.io/projects/rulebook/en/latest/introduction.html
Colección de EDA: https://github.com/ansible/event-driven-ansible
Kafka UI: https://github.com/provectus/kafka-ui
