Rulebooks de Ansible

Un rulebook de Ansible® es un conjunto de reglas condicionales que Event-Driven Ansible utiliza para realizar acciones de TI en un modelo de automatización basado en eventos. Con los rulebooks, los usuarios indican a Event-Driven Ansible la fuente que debe supervisar en busca de un evento y, cuando este ocurre, la acción que debe llevar a cabo si se cumplen determinadas condiciones.

Al igual que los playbooks de Ansible, se escriben en YAML, un lenguaje comprensible para las personas, pero utilizan reglas condicionales con el formato si sucede esto, se hace aquello. Estas permiten definir el momento en que un evento debe ejecutar una acción. A partir de las instrucciones de un rulebook, Event-Driven Ansible supervisa la fuente objetivo del evento, reconoce el momento en que se produce y ejecuta la acción adecuada de forma automática. 

Con los rulebooks de Ansible, los equipos de TI pueden escribir en el código las decisiones que deben tomarse y diseñar las acciones que deben llevarse a cabo si se cumplen ciertas condiciones, de modo que estas se realicen siempre de la misma manera. Además, los rulebooks pueden iniciar los playbooks de Ansible que ya posean cuando se cumplan las condiciones, lo cual aumenta la utilidad de los playbooks de confianza que los equipos desarrollaron y mejoraron a lo largo del tiempo. 

Al incorporar sus conocimientos a los rulebooks, los equipos no solo pueden utilizar Event-Driven Ansible para reducir los errores que se cometen por cansancio cuando se realizan tareas repetitivas, sino también crear procesos de TI más eficientes y uniformes.

Event-Driven Ansible ofrece la función de gestión de eventos necesaria para automatizar las tareas que consumen mucho tiempo y responder a las condiciones cambiantes de cualquier área de TI. Procesa los eventos que contienen información específica sobre las condiciones de los entornos de TI, determina la respuesta adecuada y ejecuta las acciones automatizadas para abordar o corregir el evento. Event-Driven Ansible se puede utilizar para automatizar las tareas de gestión de los servicios de TI, como la mejora de las solicitudes de seguimiento de incidentes, la resolución de los problemas y la gestión de los usuarios, así como muchas otras tareas propias de los entornos de TI.

Por ejemplo, su herramienta de determinación del estado interno de los sistemas (la fuente del evento) controla los enrutadores de red y descubre que uno de ellos no responde. Esto se reconoce como un evento. Event-Driven Ansible lo recibe, incorpora sus datos a través de las condiciones del rulebook y lo asocia con la acción deseada, ya sea volver a aplicar una configuración, restablecer el enrutador, crear una solicitud de seguimiento de incidentes o redirigir el tráfico. Luego, según las instrucciones del rulebook, activa la acción y restablece el enrutador para que vuelva a funcionar con normalidad. Esto puede suceder en cualquier momento, incluso a las dos de la madrugada, mientras los ingenieros duermen.

La flexibilidad de Event-Driven Ansible es posible gracias a los rulebooks de Ansible, los cuales conectan las fuentes de eventos con las acciones correspondientes a través de reglas.

Los rulebooks de Ansible contienen la fuente del evento y las instrucciones condicionales (las reglas) que especifican las acciones que se deben llevar a cabo cuando se cumple una condición determinada. Una regla incluye una única condición y su acción correspondiente, en tanto que un conjunto de reglas es un grupo compuesto por varias reglas y acciones. Los rulebooks pueden incluir diversos conjuntos de reglas.

Están diseñados para ser flexibles, por lo que pueden:

• supervisar una o varias fuentes; 
• incluir una o varias reglas;
• activar una o varias acciones. 

Event-Driven Ansible integra la flexibilidad de las fuentes, las reglas y las acciones para que los usuarios puedan configurar las acciones que deberán llevarse a cabo si se cumplen determinadas condiciones de TI.

La primera parte de un rulebook define la fuente o las fuentes que desea supervisar en busca de eventos. A la hora de identificar los eventos y recopilar datos sobre ellos, Event-Driven Ansible se basa en fuentes de eventos inteligentes, como aplicaciones y herramientas de terceros para la determinación del estado interno de los sistemas. Se utilizan complementos para conectar Event-Driven Ansible con estas fuentes y buscar eventos. 

Los conjuntos de contenido certificado Red Hat® Ansible Certified Content Collection de ansible.eda incluyen una serie de complementos prediseñados de fuentes de eventos que pueden ser útiles para comenzar a utilizar Event-Driven Ansible. Sin embargo, Red Hat recomienda a los partners y proveedores que utilicen complementos personalizados y diseñados específicamente para su tecnología. De este modo, será más fácil obtener beneficios a partir de los datos de eventos y se simplificará el proceso de integración.

Complementos de contenido certificado de ansible.eda

Al utilizar los complementos del conjunto de ansible.eda, los usuarios pueden comenzar a procesar eventos rápidamente, ya que estos permiten que Event-Driven Ansible busque eventos y los procese con la lógica condicional de los rulebooks para determinar las acciones que deben llevarse a cabo. Si un evento no cumple las condiciones establecidas, Event-Driven Ansible no activará ninguna acción, y el evento se desestimará. 

Algunos de los complementos de fuentes comunes que se encuentran en el conjunto de ansible.eda son webhooks, Kafka y Prometheus AlertManager. Se utilizan con webhooks genéricos que pueden provenir de diversos sistemas y herramientas, colas de mensajes y alertas de sistemas de supervisión de eventos empresariales como Prometheus. 

Además, los partners de Red Hat proporcionan otros complementos certificados de fuentes de eventos que se adaptan de manera más concreta a sus tecnologías y soluciones, los cuales pueden incluir nuevas funcionalidades para que Event-Driven Ansible sea más compatible con sus productos. Asimismo, los usuarios pueden crear sus propios complementos para fuentes de eventos internas.

Por ejemplo, si tiene un conmutador de red y solo desea recibir notificaciones cuando falle un puerto, un partner puede diseñar un complemento que especifique con exactitud lo que debe buscar Event-Driven Ansible en el conmutador. De este modo, evitará recibir información irrelevante sobre lo que ocurre en el conmutador en todo momento. El complemento certificado podría ofrecer solo el nombre del host del dispositivo, el problema y un número de incidente, mientras que un complemento genérico (por ejemplo, un webhook) podría incluir detalles adicionales, como el nombre del remitente, la URL u otros datos que no sean relevantes para solucionar el problema.

Una vez que un complemento detecta un evento y proporciona información sobre este, Event-Driven Ansible filtra los datos en función de las reglas condicionales del rulebook y determina las acciones que deben llevarse a cabo. Las reglas son casos flexibles con el formato si sucede esto, se hace aquello, y definen los pasos que se deben seguir cuando los datos del evento cumplen determinadas condiciones. 

Por ejemplo, si el complemento se utiliza para supervisar los puertos de un enrutador de red, las reglas podrían establecer que si el puerto falla y no responde durante cinco minutos, se reinicie el enrutador. Si los datos del evento se filtran a través de las reglas y no cumplen las condiciones, no se llevará a cabo ninguna acción. 

Características de los rulebooks:

• Pueden contener una o varias reglas. 
• Pueden incluir una o varias condiciones que deben coincidir con el estado del evento, o bien varias de las cuales solo una debe coincidir. 
• Pueden ser compatibles con todos los operadores matemáticos tradicionales, como =, ≠, > y <.
• Pueden aceptar números enteros, cadenas, operadores booleanos (como and, or y not), valores flotantes y tipos de datos de condición nula. 

Por ejemplo, si evalúa un evento único e intenta que coincida con varias condiciones, puede utilizar el operador booleano and, el cual indica que cada una de estas condiciones deberá cumplirse antes de que se active la acción.
 

name: Combining ‘and’ operators
condition: event.version == "2.0" and event.name == "test" and event.alert_count > 10
action:
  debug:

Si supervisa múltiples eventos e intenta que coincidan varias condiciones, puede utilizar la opción all, la cual indica que es necesario que se cumpla cada una de ellas para que la condición se considere coincidente. Debido a que estas se relacionan con múltiples eventos, aparecen en líneas separadas.
 

name: Condition using both a fact and an event
condition:
  all:
    - fact.meta.hosts == "localhost"
    - event.target_os == "windows"
action:
  debug:

Cuando se utiliza la opción any, si se cumple alguna de las condiciones, se considera que hay una coincidencia y se activa la acción. Como ocurre en el ejemplo anterior, este código analiza varios eventos, por lo que las condiciones se enumeran en líneas separadas.
 

name: Any condition can match
condition:
  any:
    - event.target_os == "linux"
    - event.target_os == "windows"
action:
  debug:

Nota: En los ejemplos anteriores, la acción de depuración debe mostrar la información del evento para que pueda visualizar estos datos en Event-Driven Ansible.

Cuando los datos de un evento cumplen las condiciones de un rulebook, Event-Driven Ansible activa la acción o las acciones que se hayan especificado. 

A continuación, se enumeran algunas de las acciones más comunes:

• Run_playbook. Esta opción permite ejecutar un playbook de Ansible actual que haya diseñado para automatizar determinadas acciones, como la resolución de problemas en un servidor. 
• Run_job_template. Esta opción permite ejecutar una plantilla de trabajo a través del controlador de automatización de Red Hat Ansible Automation Platform. Al ejecutar la plantilla dentro de la plataforma, se obtienen varias ventajas, como la gestión del inventario, los controles de usuario y acceso, y los análisis sobre la acción realizada. 
• Run_module. Esta opción permite ejecutar un módulo de Ansible actual, el cual lleva a cabo una acción más concreta y específica. Esta opción es ideal cuando no se desea ejecutar un playbook completo.
• Post_event. Esta opción permite enviar un evento a un conjunto de reglas en ejecución. Por lo general, se incluye una vez ejecutada la acción run_playbook o run_job_template, y ofrece la posibilidad de volver a incorporar la información sobre el resultado de la acción a Event-Driven Ansible.
• Set_fact. Esta opción permite registrar los datos específicos sobre un evento o una acción, de modo que puedan volver a incorporarse a Event-Driven Ansible y utilizarse para ejecutar otras acciones. Los datos de los eventos son temporales y transitorios. Por lo tanto, establecer hechos sirve para guardar información específica sobre los eventos y conseguir que sea permanente.
• Debug. Esta opción es similar a la que se encuentra en los playbooks de Ansible. Si no se aportan argumentos, mostrará la carga útil del evento correspondiente y cualquier otra información que sea importante.

En esta sección, encontrará algunos ejemplos sencillos de rulebooks de Ansible. No se preocupe si no retiene todos los detalles, ya que el objetivo de los ejemplos es ofrecer una idea general sobre el funcionamiento conjunto de las fuentes, las reglas y las acciones en un rulebook completo. 

En el primer caso, se muestra una acción individual y bastante sencilla. De acuerdo con el código que figura a continuación, si se produce una interrupción en la fuente del evento, Event-Driven Ansible ejecutará un playbook de corrección.
 

rules:
  - name: An automatic remediation rule
    condition: event.outage == true
    action:
      run_playbook:
        name: remediate_outage.yml

En el ejemplo a continuación, presentamos un rulebook un poco más complejo y definimos la fuente del evento como el complemento certificado para Dynatrace. Las reglas definen las condiciones que esperamos encontrar; en este caso, especifican algunas condiciones relacionadas con el uso del hardware y de la aplicación.
 

---
- name: Listen for events on a webhook
  hosts: all
  sources:
    - dynatrace.eda.dt_esa_api:
        dt_api_host: "https://abc.live.dynatrace.com"
        dt_api_token: "asjfsjkfjfjh"
        delay: 60 
  Rules:
    - name: Problem payload Dynatrace for CPU issue
      condition: event.payload.problemTitle contains "CPU saturation"
      action:
        run_job_template:
          name: "Remediate CPU saturation issue"
          organization: "Default"
    - name: Problem payload Dynatrace for App Failure rate increase issue
      condition: event.payload.problemTitle contains "Failure rate increase"
      action:
        run_job_template:
          name: "Remediate Application issue"
          organization: "Default"
    - name: Update comments in Dynatrace
      condition: 
        all: 
          - event.status == "OPEN"
      action:
        run_playbook:
          name: dt-update-comments.yml

La carga útil del evento que recibimos se revisará en busca de los mensajes "CPU saturation" (saturación de la CPU) o "Failure rate increase" (aumento de la tasa de fallos). Si se encuentran estos mensajes en la carga útil, Event-Driven Ansible asignará playbooks de corrección o plantillas de trabajo a los eventos para resolver el problema.

Red Hat Ansible Automation Platform utiliza YAML, un lenguaje comprensible para las personas que permite que los usuarios compartan, evalúen y gestionen el contenido de automatización. La plataforma incluye las herramientas que se necesitan para implementar la automatización en toda la empresa, como Event-Driven Ansible, los playbooks y las funciones de análisis. Además, ofrece un panel visual, el control de acceso basado en funciones y otras funciones para que los equipos concentren y controlen la infraestructura de TI. Esto ayuda a reducir la complejidad operativa.

Las suscripciones de Red Hat incluyen acceso al contenido certificado de nuestro ecosistema sólido de partners, servicios de gestión alojados y soporte técnico durante el ciclo de vida para que implemente la automatización en toda la empresa. También podrá aprovechar el conocimiento especializado que hemos adquirido gracias a nuestras colaboraciones exitosas con miles de clientes.

Con el surgimiento de Red Hat Ansible Lightspeed with IBM watsonx Code Assistant, Ansible es más accesible para los principiantes, y los creadores de Ansible con experiencia se vuelven más productivos, eficientes y menos propensos a los errores. Los desarrolladores pueden realizar una solicitud de tarea en inglés, y Ansible Lightspeed interactuará con los modelos base watsonx de IBM para generar recomendaciones de código que luego se utilizarán para crear playbooks de Ansible.