Event Driven Ansible

History

The cli component of Event Driven Ansible is ansible-rulebook. The first commits on Github are from Februrary 2022, so its a rather new tool. In December of the same year, Red Hat started to add it to the Ansible Automation Platform (AAP) Subscription as a developer preview. In Mai 2023 it was announced, that it will be part of the upcoming AAP 2.4 release. It’s also available as a Python package (ansible-rulebook) and as an Ansible collection (ansible.eda), so you don’t have to have a Red Hat subscription in order to use it.

Concept

The term “Event Driven Ansible” says it all. It’s an event that drives an Ansible run. In other words, if an event occures, then an Ansible (f.e. playbook) run is triggered. The simple logic behind it is obvious:

IF – THEN !

In contrary to ansible-playbook or ansible-navigator, the ansible-rulebook cli starts a deamon that runs until its stopped or it fails. While running, it waits for events to happen.

Vocabulary

A Rulebook consists of one or many rulesets. A ruleset has a list of sources („where is the event coming from?“) and a rule. The rule consists of one or many conditions („if“) and one or many actions(„then“).

The sources can be many: At the moment there is support for monitoring tools (Prometheus, Zabbix, Sensu), cloud providers (Google, AWS, Azure) and many more (AppDynamics, F5, Splunk, Openshift… ).

Conditions are regular expressions on the familiar datatypes. The most common actions are: Running an ansible module (run_module), running a playbook (run_playbook) or triggering an AWX / AAP Controller job template (run_job_template).

Install

For using EDA, you need to install ansible-rulebook, the ansible.eda collection and OpenJDK 17. Java is needed because ansible-rulebook uses the decision making framework drools (written in Java). As of June 2023 it seems to be a good idea to use Fedora 36 and above. There where unmet dependencies on other operating systems like Rockylinux 9 and Ubuntu 22.04 LTS and you would have to compile stuff on your own. Be warned.

$ pip install ansible-rulebook
$ ansible-galaxy collection install ansible.eda
$ dnf install java-17-openjdk

The Rulebook

Let’s write a rulebook: We want to check every 10 seconds if a webpage is available, and trigger the re-provisioning of the webserver (webserver.yml playbook) if the site is down. The rulebook might read as follows:

---
- name: rebuild webserver if site unavailable
  hosts: webserver
  sources:
    - ansible.eda.url_check:
        urls:
          - http://webserver_url:80/
        delay: 10
  rules:
    - name: rebuild webserver if site down
      condition: event.url_check.status == “down”
      action:
        run_playbook:
          name: webserver.yml

Use ansible-rulebook to start the rulebook in verbose mode:

$ ansible-rulebook --rulebook webserver_rulebook.yml -i hosts -v

Now whenever the website turns unavailable, the rulebook daemon triggers the re-provisioning of the webserver, and the website becomes available again. Ta-da!

My thoughts

There are some steps that I always tend to do while investigating an issue: Gathering some pieces of information about the faulty system, entering them into a ticketing system and so on. It could be a nice use case for Event Driven Ansible to automate manual tasks, and speed up the debugging of the issue. “Ops as Code” is the related buzzword.

At the moment, I somewhat doubt that using it for selfhealing is a good idea. In my opinion, automatically restarting a failed service might encourage to paper over an issue, rather than properly investigating the underlying problem. But there are other use cases where EDA could come in handy for certain, like scaling infrastructure when resources get scarce, or triggering a failover of a failed service.

In any case, we are looking forward to see how EDA is developing, and how it gets adopted in the Ansible world. Let’s stay tuned!