Agentless automation with Event-Driven Ansible
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
...Buy this article as PDF
(incl. VAT)