What it is?

Redhat says:

Event-Driven Ansible is a new way to enhance and expand automation. It improves IT speed and agility, while enabling consistency and resilience. The Event-Driven Ansible technology was developed by Red Hat and is available as a developer preview. Community input is essential. Since we are building a solution to best meet your needs, we’re providing an opportunity for you to advocate for those needs.

How does it work?

In Ansible you write Playbooks. In Event Driven Ansible you write rulebook. But instead of just defining what tasks should be run, you define several more things:

First you define some sources that Event-Driven Ansible listens to. This can be webooks, alertmanagers, changed URLs or files.

Then you define rules. These rules state what should happen (actions) and when (conditions) it should happen.

Conditions can be a triggered alert from the Alertmanager or an unreachable website, a newly created file or just a message that was received from the webook.

Actions define, what should happen after a condition is triggered. Probably the most common action will be run_playbook which executes a defined playbook. Other actions can be running a module (instead of a whole playbook) or setting a fact.

Here’s an example.
This rulebook listens starts a webhook on port 5000 and listens for incoming connections. When an incoming connection has a payload that says Ansible is super cool, the „Say Hello“ rule’s condition will be met. Then the action will be executed, in this case the playbook say-what.yml will be executed.

Why?

Traditionally Ansible follows a push-based model where you trigger runs that change something.
With Event Driven Ansible you can perform these changes automatically based on your defined conditions. This can make some manual tasks superfluous:

Imagine getting a ticket to create a new user in your organization. Event Driven Ansible can check for this new ticket and act on it automatically.

It can also help in troubleshooting issues. When your monitoring notices that some systems failed, Event Driven Ansible can watch for these failures and collect valuable information on the failed systems.

Now let’s take a look into it!

Installation

The Installation is simple – I just followed the official documentation and installed java, ansible, ansible-rulebook and some collections.

Running

When first running ansible-rulebook you get zero output:

Running with -h is better and provides the help:

Thinking that it should work somehow like ansible-playbook I just passed my aforementioned rulebook:

No dice. However, with –rulebook I got one step further.

Creating a simple inventory and using it finally worked:

So now there is a webhook listening locally on port 5000. Let’s curl it:

Okay, as I have to send a payload to the webhook, that was expected. Let’s POST some simple message to the webhook.

This time I got another error. It seems ansible-rulebook uses a squid proxy internally. The ansible-rulebook-process also threw an error.

After consulting the documentation I found the correct URL to POST to and also what to data to post: A JSON-Payload to localhost:5000/endpoint:

Now we’re talking! The ansible-rulebook picked up the message and acted on it by executing the defined playbook. You can spot the familiar ansible-playbook output.

Here’s the playbook that was executed:

A cool thing: The playbook is dynamically loaded, so it can be changed without needing to restart the rulebook. Changes to the rulebook do require a restart of ansible-rulebook htough.

The first simple example worked! Let’s check out further what we can to with Event Driven Ansible.

Event Sources

As explained above Event Driven Ansible has different event sources and I demonstrated the webhook source. Let’s try the url_check source. The official documentation for this source module is lacking (for now). So let’s look at the source code:

An ansible-rulebook event source plugin that polls a set of URLs and sends events with their status.

Arguments:
    urls – a list of urls to poll
    delay – the number of seconds to wait between polling

Example:

This seems quite easy to implement:

Here I’m using another action, the run_module. This module does not execute an Ansible Playbook but rather just a single task. In this example it should just pring SUCCESS.
The condition checks if the status of the website is up.

And after some considerable waiting it works:

Now you could use this to monitor some websites and in case of an error do some automated recovery or collect troubleshooting information. However, at the time of this writing, the module isn’t really stable.

file_watch

Let’s take a look at another event source, the file_watch. This module is so new, it isn’t even mentioned on the documentation yet. The source code however provides some docs:

An ansible-rulebook event source plugin for watching file system changes.
Arguments:
    path: The directory to watch for changes.
    ignore_regexes: A list of regular expressions to ignore changes
    recursive: Recursively watch the path if true

Example:

Implementing it seems easy at first:

But I don’t know what condition I can use. The above does not work and I wasn’t able to find out what conditions are accepted. To fix this I created an issue.

Actions

In the previous examples I already used two different actions:

  • the run_playbook action executes a playbook
  • the run_module action executes a module.

There are other actions and the one I used to find out more about payloads and events is the debug action.

Here’s how to use it:

And here it is in action:

You can see that this outputs all variables used in the event, so I can see what actually happened. This is also nice to see what events are supported.

The Event Driven Ansible Server

What Ansible AWX is for Ansible, the Event Driven Ansible Server is for the Ansible-rulebook.
The eda-server provides a web-UI where you can view your rulebooks, watch its runs and even execute one-off jobs.

The eda-server is in early development but already has the core functionality implemented.
I installed the eda-server with the provided docker-compose-file. After creating an admin-user and logging in to the webpage, I could add my project (basically a git-repository with your rulebooks and playbooks) and execute a job.

But that’s all what worked for me for now. Adding an inventory file via the web or deleting it isn’t implemented and the automatic rulebook activation did not work for me (probably because of some issue with docker).

There’s much to do and implement but looking at the speed of development I think we’ll have a usable product soon!

In the meantime I’ll continue checking out Event Driven Ansible.

Sources


Be part of the T-Systems MMS and check out our job offers as:

> DevOps Engineer (m/w/d) (Job advertisement in German language)

> (Senior) Cloud Engineer (m/w/d) (Job advertisement in German language)