On Call

The Ansible automation platform does not require an agent on the systems to be managed, which is both a curse and a blessing. Without a client, Ansible can control any system directly by SSH and Python, or even Windows Remote Management (WinRM) and PowerShell, whereas other platforms like Puppet or Salt need their agents. On the other hand, tools with agents can react quickly to incidents on the managed system because the client is in constant communication with the automation tool.

These applications also take a "reactive" approach, which Ansible has been unable to do thus far because of its push-only architecture. The community's new Event-Driven Ansible (EDA) [1] project now aims to change this situation, while still doing without an agent.

Modular Architecture

Red Hat first introduced the concept of EDA as a Developer Preview at the AnsibleFest user and developer conference in Fall 2022. EDA adapts the "state machine" concept as used by ManageIQ, among others, wherein the state machine is triggered by an event (e.g., a log message with error ). It then checks one or more conditions (e.g., if alerting.service=dns) and then initiates appropriate actions (e.g., restart named.service).

EDA listens for events from one or more sources. Like regular Ansible, EDA is modular and can handle different sources. As of today, very few of these source plugins are around; then again, EDA is still in its infancy. The EDA website documents how you can program your own source plugins [2]. Therefore, the number of available sources should increase steadily now that EDA has been officially released [3]. Spoiler: This article is based on a developer pre-release version of EDA. Some of the procedures described here may have changed in the official release.

The plugins already available include, for example, ansible.eda.webhook, which lets Ansible tap into web applications such as GitHub. A Git commit in a web repository can therefore trigger a playbook in the data center. The powerful ansible.eda.kafka source plugin lets EDA tap into the Apache Kafka message bus. I use this plugin in one of the examples here.

Additionally, some initial plugins from commercial manufacturers have already been made available, such as ansible.eda.dynatrace, ansible.eda.aws_cloudrail, and ansible.eda.azure_service_bus.

Others under development as of May 2023 were not in the beta build I used when I wrote this article, such as ansible.eda.journald for listening to systemd log messages. However, by the publication date of this article, this plugin should be usable.

Ruleset

EDA introduces a new variant of Ansible's YAML-based programming language for playbooks in the form of rulebooks, in which you describe the sources to which you want EDA to listen and how it will react to events. They are executed by a program that was also newly developed: ansible-rulebook [4]. Rulebooks are not launched like playbooks. A rule runs permanently, like a daemon, because it permanently monitors the specified source.

In practice, users are likely to use rulebooks in containers. In addition to the rulebook runtime, the containers also have ansible-runner to execute the defined action playbooks in the active container. Alternatively, the rulebook addresses the API of an Ansible controller (AWX instance) to launch a job template there. As of writing, EDA still worked separately from these web user interface (UI) instances. Integration was planned to take place after the official release.

Numerous Dependencies

The regular Ansible playbook gets by with Python plus some Python libraries, but the current pre-build of EDA took me into entirely different realms of code and runtime dependencies. Because Python (from version 3.9) alone is not sufficient for EDA, it uses the free Drools [5] business rules management engine. Besides Python, the EDA container also required version 17 of the Java runtime for Drools.

For the Python part of EDA to be able to communicate with its Java part, the Java-to-Python bridge jpy [6] is also required. To compile jpy in the container, you then need the Maven software project manager, whose RPM package in Enterprise Linux 8 (EL8) requires the old Java 1.8 runtime instead of 17. In other words, the EDA Developer container came with Python 3.9 including the GCC development environment, make, and two Java runtimes. This was also to change before the official release.

Fortunately, at the time of writing, a ready-made container image for EDA testing was already on quay.io/ansible/ansible-rulebook:main. The main tag is important here; the image with the latest tag used an even older version.