In this blog post we’re going to talk about how Ansible can streamline the process of managing any event that takes place in a digital environment.
First of all, what is an event? An event is considered to be any event that takes place in a digital environment. Examples would be:
- Click on the shopping cart.
- Mistake when entering your password.
- Attempted network intrusión.
- Application service down.
Some of these events serve us at the business level, through the use of data analysis. With others, it may be necessary to act on the system to avoid loss of service or any other type of critical reason for the environment.
Conventional procedure dictates that these events should be handled as follows: an operator receives the event and, based on what has happened, escalates the team to act or takes manual action himself. This can lead to hours of response time and a margin of human error that may not be acceptable.
For this reason, tools such as Ansible have helped organisations to standardise this type of action. In this case, if the operator receives an event for which a procedure needs to be executed, the operator may be instructed to execute an automation. Even so, there is still room for error in not having removed the human component from the equation and some degree of delay in the necessary action, given that: the event has been triggered, the operator has received it, and the operator has had to decide what to do.
What is Event-Driven Ansible?
Ansible alone is not capable of receiving an event and deciding what to do with it. Red Hat initiated the development of the open-source Event-Driven Ansible technology, EDA from now on, which allows listening to events from various sources and, based on their content, being able to make a decision on what action to take.
It is a component supported by Red Hat and a community, which allows companies to avoid having to develop a customised solution for each source of events and thus be able to focus their efforts on developing the automation that will act on this event.
EDA receives the events thanks to different plugins, thus allowing the solution to be extended to non-conventional data sources. Examples of sources are:
- Kafka
- Alertmanager
- Azure Service Bus
- Watchdog
- Webhook
And how do we tell EDA to get data from a particular source and perform an action when a certain condition is met? The answer is Rulebooks. A Rulebook is a YAML file similar to an Ansible Playbook where we can define the source of events and the conditions that must be met to execute various actions.
In the following image you can see an example of a Rulebook, with each of the above elements detailed:
- In sources we will specify the list of sources to be used in this Rulebook It can be one or several, depending on the use case.
- Rules will be a list as sources, where each element will have a condition and an action. When the event arrives, the conditions are evaluated one by one until one is met. At that point, the action will be executed. In this case we would execute an Ansible Playbook to start or stop a service.
In addition to running a Playbook, a rule allows, among others:
- Execute modules directly.
- Generate an event.
- Defining a variable.
- Running a Job Template in AWX/AAP.
Use case: event with origin Kafka
Let’s imagine that in our organisation we use Kafka as an event streaming tool. In it, another tool publishes events in Kafka about the change of state in a particular service, httpd. What we are looking for is that through EDA we can start up again, to give service to our customers again.
The Rulebook will be as follows:
Where we will execute the Playbook restart_service.yml in case we receive an event for the httpd service and status stopped.
The content of the Playbook will be the following:
This prints a message saying that it is restarting the service (obviously, it won’t do this as we don’t tell it to do so, it is purely informational).
Finally, we can run the Rulebook to listen for incoming events with the ansible-rulebook command.
If we now produce messages through Kafka like the one in the following image, we won’t see anything.
Instead, by producing a message like the following, we will see that the Rulebook reacts when the only condition is met:
The Rulebook process will keep running, so if it receives a new event that meets the condition, it will act again as we have specified.
In short, we have managed to execute an automation from an event coming from Kafka. This use case can be extended by performing one more action when the service goes to the started state, or even being able to act on any service, not just httpd.
Conclusion
Organisations are inundated with events from many different sources: ServiceNow, Alertmanager, Kafka… If action is required for all of them, operational cost can be affected, in addition to response times and possible human error. EDA offers a solution to combat these costs. Thus, teams can focus on developing different processes in reaction to each type of event, without having to worry about receiving, deciding and executing these procedures manually.
References
-
EDA Documentation: https://ansible.readthedocs.io/projects/rulebook/en/latest/introduction.html
-
EDA Collection: https://github.com/ansible/event-driven-ansible
-
Kafka UI: https://github.com/provectus/kafka-ui
