What Is Event-Driven Ansible?

Event-Driven Ansible, or EDA, is a new type of Ansible content that was released into general availability in Ansible Automation Platform 2.4 in June of 2023. With this new type of content, Ansible users can now trigger automation based on events, or a certain set of criteria that they can define and watch for, as opposed to our traditional content which requires manual activation.

Event-Driven Ansible requires a source of events, a set of rules in the form of a rulebook, and actions to take based on the matched rule.

Event Sources

Event-Driven Ansible requires an intelligent source of events to listen to. These sources integrate with Event-Driven Ansible via Event Source plugins and these plugins are written in Python. Event Source plugins are provided via an Ansible Collection. Currently, Event-Driven Ansible provides a default set of source plugins that can be used in the ansible.eda collection.

However, since these are not specific to Partner technologies they are not optimized for Partner-specific events. Red Hat Partner ISVs can contribute and certify these plugins to make them available for use by customers. By certifying these plugins, a partner agrees to jointly support them with Red Hat per the Ansible Certification Policy Guide.

Partners can build your own event source plugin in python. A plugin is a single python file. There is in-depth documentation on event source plugins and how to create them here.

Rulebooks

While event source plugins watch for events, a rulebook defines what the event is that it should watch for.

Event-Driven Ansible requires a source of events, a rulebook to allow for the events to be checked against conditions and a course of action based on the matched condition. Ansible Rulebooks provide a mechanism for us to gather the event data and match it against the conditions we have built and trigger the desired action and response. Rulebooks have been built with the Ansible user in mind and therefore are also based in YAML and follow a very similar structure to the Ansible Playbook.

Red Hat partner ISVs may also contribute these for use by customers, and can be either certified (if you intend for customers to use them as-is without making changes), or submitted as validated content if they’re intended to be customizable. These processes are defined in the last section of this document.

There is in-depth documentation on rulebooks and how to create them here.

Actions

An action is what happens when a defined event is detected.

An action gives us the ability to respond to a condition that has been matched in the rules. The action can be the triggering of a playbook, Ansible module, setting facts or a template in the Automation controller. When using a playbook or a template, we are able to automate a response whether it is to remediate an issue or perhaps enrich observation etc. The user will typically build these with the operational knowledge of how they would want to resolve the event that was detected.

Red Hat partner ISVs may also contribute these for use by customers, and can be either certified (if you intend for customers to use them as-is without making changes), or submitted as validated content if they’re intended to be customizable. These processes are defined in the last section of this document.

There is in-depth documentation on actions and how to call them here.