Getting Started with Event-Driven Ansible Guide

Red Hat Ansible Automation Platform 2.4

Learn about the benefits and how to get started using Event-Driven Ansible.

Red Hat Customer Content Services

Abstract

Event-Driven Ansible is a new way to enhance and expand automation by improving IT speed and agility while enabling consistency and resilience. This feature is designed for simplicity and flexibility.

Preface

Thank you for your interest in Event-Driven Ansible. Event-Driven Ansible is a new way to enhance and expand automation. It helps teams automate decision-making and improve IT speed and agility.

This guide provides the conceptual framework of Event-Driven Ansible and links you to information on installing and using Event-Driven Ansible controller.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright’s message.

Providing feedback on Red Hat documentation

If you have a suggestion to improve this documentation, or find an error, please contact technical support at https://access.redhat.com to create an issue on the Ansible Automation Platform Jira project using the docs-product component.

Chapter 1. Event-Driven Ansible Automation

Event-Driven Ansible is a new way to connect to sources of events and act on those events using rulebooks. This technology improves IT speed and agility, and enables consistency and resilience.

1.1. Event-Driven Ansible benefits

Event-Driven Ansible is designed for simplicity and flexibility. With these enhancements, you can:

  • Automate decision making
  • Use many event sources
  • Implement event-driven automation within and across multiple IT use cases
  • Achieve new milestones in efficiency, service delivery excellence and cost savings

Event-Driven Ansible minimizes human error and automates processes to increase efficiency in troubleshooting and information gathering.

This guide helps you get started with Event-Driven Ansible by providing links to information about understanding, installing, and using Event-Driven Ansible controller.

Chapter 2. Ansible rulebooks

Event-Driven Ansible controller provides the interface in which Event-Driven Ansible automation performs. Ansible rulebook provides the framework for Event-Driven Ansible automation. Ansible rulebook is essentially a collection of rulesets, which in turn, consists of one or more sources, rules, and conditions.

2.1. Decision Environments

Event-Driven Ansible includes, by default, an ansible.eda collection, which contains sample sources, event filters and rulebooks. All the collections, ansible rulebooks and their dependencies use a Decision Environment, which is an image that can be run on either Podman or Kubernetes.

In Decision Environments, sources, which are typically Python code, are distributed through ansible-collections. They inject external events into a rulebook for processing. The rulebook consists of the following:

  • The python interpreter
  • Java Runtime Environment for Drools rule engine
  • ansible-rulebook python package
  • ansible.eda collection

You can use the base Decision Environment and build your own customized Decision Environments with additional collections and collection dependencies. You can build a Decision Environment using a Dockerfile or optionally you can deploy your CA certificate into the image.

2.2. Rulebook actions

A rulebook specifies actions to be performed when a rule is triggered. A rule gets triggered when the events match the conditions for the rules. The following actions are currently supported:

  • run_job_template
  • run_playbook (only supported with ansible-rulebook CLI)
  • debug
  • print_event
  • set_fact
  • post_event
  • retract_fact
  • shutdown

Additional resources

Chapter 3. Installation of Event-Driven Ansible controller

Similar to the automation controller and automation hub components, the setup for Event-Driven Ansible controller includes default settings for specific variables in the inventory files.

Important

Event-Driven Ansible controller must be installed on a separate server and cannot be installed on the same host as automation hub and automation controller.

Note

If you are running Red Hat Enterprise Linux 8 and want to set your memory limits, you must have cgroup v2 enabled before you install Event-Driven Ansible. For specific instructions, see the Knowledge-Centered Support (KCS) article, Ansible Automation Platform Event-Driven Ansible controller for Red Hat Enterprise Linux 8 requires cgroupv2.

3.1. Installing Event-Driven Ansible controller on Red Hat Ansible Automation Platform

To prepare for installation of Event-Driven Ansible controller, review the following information in the Red Hat Ansible Automation Platform Planning Guide:

When you are ready to install the Event-Driven Ansible controller, see the procedures in the Red Hat Ansible Automation Platform Installation Guide beginning with Chapter 3. Installing Red Hat Ansible Automation Platform. For a specific code example related to Event-Driven Ansible controller, see the Single Event-Driven Ansible controller node with internal database scenario.

To further assist you in getting started with Event-Driven Ansible, review the following existing installation scenarios that include code examples and variables that are required to install Event-Driven Ansible controller:

Lastly, see Appendix A. 5. Event-Driven Ansible controller variables in the Red Hat Ansible Automation Platform Installation Guide to view predefined variables for Event-Driven Ansible controller.

3.2. Deploying Event-Driven Ansible controller with Ansible Automation Platform Operator on OpenShift Container Platform

Event-Driven Ansible is not limited to Ansible Automation Platform on VMs. You can also access this feature on Ansible Automation Platform Operator on OpenShift Container Platform. To deploy Event-Driven Ansible with Ansible Automation Platform Operator, follow the instructions in Deploying Event-Driven Ansible controller with Ansible Automation Platform Operator on OpenShift Container Platform.

After successful deployment, you can connect to event sources and resolve issues more efficiently.

Additional resources

Chapter 4. Using Event-Driven Ansible controller

After you have successfully installed the Event-Driven Ansible controller, you can access the interface to manage your IT responses across all event sources. Since Event-Driven Ansible controller is integrated with automation controller, you can automate a combination of processes, including issue remediation, user administration tasks, operational logic, and the like.

4.1. Event-Driven Ansible controller tasks

Depending on your role, you can use Event-Driven Ansible controller for any of the following tasks:

  • Configuring a new project
  • Setting up a new decision environment
  • Creating a new authentication token
  • Setting up a rulebook activation

Next steps

Legal Notice

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.