Abstract
| Goal |
Create Ansible automation that can run playbooks based on events delivered from various supported sources. |
| Objectives |
|
| Sections |
|
Explain what Event-Driven Ansible is, why it is important, and describe its architecture and some of its key use cases and benefits.
Red Hat Ansible Automation Platform 2 provides tools and features to deploy automation quickly and reliably. It offers flexibility to automate across geographically distributed platforms and integrates with hybrid cloud deployments. Red Hat Ansible Automation Platform 2 simplifies the transition from developing playbooks to running them in production. Up until now, all these automation benefits were focused on manually triggering playbooks or automation controller jobs. Even though this model is highly efficient, it lacks a method of automatically responding to a change in your environment.
Event-Driven Ansible is a new technology, introduced with the release of Red Hat Ansible Automation Platform 2.4, which enables Ansible to run automation code without manual intervention when it receives notification of events in your environment.
For example, a system outage in your environment can send an alert to Event-Driven Ansible, which then automatically runs automation code that you previously prepared. Event-Driven Ansible might run a playbook or launch an automation controller job that:
Raises a ticket to inform the necessary support team about the situation
Gathers data that assists in troubleshooting an outage
Reboots the affected systems
All actions can take place quickly, consistently, and effectively, without the need for manual intervention.
Event-Driven Ansible works by using rules to connect the events it might receive with the corresponding actions to take.
Event-Driven Ansible collects events that it receives from supported event sources and matches those events to rules. Rules evaluate the events based on conditions that you define. Events that match conditions trigger actions.
An event is a notification of an interesting occurrence. Events come from event sources. Event-Driven Ansible supports various types of event sources by using a system of plug-ins. The event source plug-ins are distributed in Ansible Content Collections.
For example, you might be interested in performing an action every time a file is created in a certain directory on the file system of a server.
In this case, the event would be the creation of a file in that directory.
You can use the ansible.eda.file_watch event source plug-in from the ansible.eda Ansible Content Collection to process an event whenever it detects a new file in that directory.
The following table shows some event source plug-ins that are included in the ansible.eda Ansible Content Collection:
| Event source plug-in | Description |
|---|---|
alertmanager
| Receives events via a webhook from alertmanager |
aws_sqs_queue
| Receives events via an AWS SQS queue |
azure_service_bus
| Receives events from an Azure service |
file_watch
| Watches for file system changes |
journald
| Monitors the systemd journald logs |
kafka
| Receives events from an Apache Kafka topic |
range
| Generates events with an increasing index in a range |
tick
| Generates events with an increasing index that never ends |
url_check
| Polls a set of URLs and sends events with their statuses |
webhook
| Provides a webhook and receives events from it |
To define expected events and how to react to them, Event-Driven Ansible uses Ansible Rulebooks. An Ansible Rulebook is similar to an Ansible Playbook. A rulebook is a text file written in YAML and is composed of a list of rulesets. An Ansible Playbook contains a list of plays, but an Ansible Rulebook contains a list of rulesets.
Similar to plays in a playbook, you provide a name to the ruleset to identify it, then specify the hosts to run against, and optionally you establish whether the ruleset collects facts from hosts by defining the gather_facts parameter.
Instead of tasks, rulesets define a list of event sources to monitor and a list of rules that specify what actions to take when certain conditions are met.
Define the event source plug-ins to use. You can use fully supported event source plug-ins provided by Red Hat and its partners. You can also use event source plug-ins developed by the Ansible community, or even event source plug-ins that you create yourself.
Define the conditions to watch for and the actions to take if those conditions are met. You can define more than one rule for the same source and you can evaluate multiple conditions.
An event of interest that is used to match a rule. Conditions use operators to compare Booleans, numerical data, and strings.
Define what you need to happen when the condition is met. For example, the action might run a playbook, run a module, set a fact, define a post event, run a job template, perform debugging, and so on.
The following is an example of an Ansible Rulebook composed of a single ruleset:
---
# Define the hosts the ruleset is going to run against
- name: Review webservers status
hosts: web
# Define the source of events
sources:
- name: URL to review
ansible.eda.url_check:
urls:
- http://web01.lab.example.com
# Define the list of conditions to look for and the corresponding actions
rules:
- name: Webserver is up
condition: event.url_check.status == "up"
action:
run_playbook:
name: play_up.yml
- name: Webserver is down
condition: event.url_check.status == "down"
action:
run_playbook:
name: play_down.ymlRulebooks are discussed in more detail later in the course.
After you create the rulebook, you use a rule engine to run the rulebook.
Red Hat Ansible Automation Platform provides two ways to run a run engine:
By using the ansible-rulebook command-line tool
By using the Event-Driven Ansible controller, a web service that is similar to automation controller
To run an Ansible Rulebook, you can use the ansible-rulebook command from the ansible-rulebook RPM package.
The ansible-rulebook command is a command-line rule engine.
To install the RPM package and its dependencies you need a valid Red Hat Ansible Automation Platform subscription. The installation process is as follows:
Register your system using Red Hat Subscription Manager:
[root@host ~]# subscription-manager registerUse the subscription-manger command to enable the Red Hat Ansible Automation Platform 2.4 repository:
[root@host ~]#subscription-manager repos \--enable ansible-automation-platform-2.4-for-rhel-9-x86_64-rpms
Install the ansible-rulebook and ansible-runner RPM packages:
[root@host ~]# dnf install ansible-rulebook ansible-runnerThe Event-Driven Ansible controller component of Ansible Automation Platform provides a web UI and a central point of control for Ansible Rulebooks and automation projects. You can use Event-Driven Ansible controller as an enterprise rule engine to run your Ansible Rulebooks.
The following diagram shows the components of a Red Hat Ansible Automation Platform 2 deployment that includes an Event-Driven Ansible controller node:
The arrows in the preceding example show how Event-Driven Ansible controller connects to the same database as automation controller and private automation hub, and that you can integrate Event-Driven Ansible controller with them.
By integrating Event-Driven Ansible controller with automation controller, actions in a rulebook on your Event-Driven Ansible controller can interact with job templates or workflows on your automation controller.
The integrations between Event-Driven Ansible controller, automation controller, and private automation hub are carried out by using authentication tokens.
Event-Driven Ansible controller is covered in more detail later in the course.
As mentioned before, event source plug-ins are distributed within collections, and Red Hat maintains a fully supported Ansible Content Collection system distributed from the public automation hub (https://console.redhat.com/ansible/automation-hub).
You can use Red Hat Ansible Certified Content and Ansible validated content for the event source plug-ins in your Ansible Rulebooks.
Red Hat Ansible Certified Content is a set of Ansible Content Collections that are created and tested by Red Hat and a wide and constantly growing network of partners.
This content is fully supported and maintained by Red Hat and follows a versioning and release strategy documented in a Knowledgebase article at https://access.redhat.com/articles/4993781.
You can download and install Red Hat Ansible Certified Content Collections from automation hub.
The following table shows some examples of Red Hat Ansible Certified Content related to Event-Driven Ansible:
| Event source plug-in | Provided by | Description |
|---|---|---|
redhat.insights_eda
| Red Hat | Contains the event source plug-in for receiving events out of Red Hat Insights |
crowdstrike.falcon
| CrowdStrike | Receives events from CrowdStrike Falcon Event Stream |
dynatrace.event_driven_ansible
| Dynatrace | Captures all problems from your Dynatrace tenant |
ibm.instana
| IBM | Provides the ability for Instana event data to be consumed by Event-Driven Ansible |
logicmonitor.integration
| Logicmonitor | Includes the required plug-ins to interact with the infrastructure monitoring platform |
paloaltonetworks.panos
| Palo Alto Networks | Enables automation of operational tasks on Palo Alto Networks Next Generation Firewalls |
On the other hand, Ansible validated content consists of Ansible content that provides expert-led guidance on how to perform operations and tasks on Red Hat or partner platforms. This content is provided in automation hub, and is digitally signed so that you can confirm it came from a trusted source. You can use it, customize it, and learn from it. This content is not supported or maintained by Red Hat.
By using Ansible validated content, you are using code in which:
The use cases are based on successfully deployed customer examples.
The content creators are trusted and verified subject matter experts.
The content follows best practices and guidelines issued by Red Hat.
The content is ready for use in production environments.
The network.interfaces and network.telemetry collections provided by Red Hat are examples of Ansible validated content.
The latter collection manages telemetry configuration on network devices and enables you to set up a Telegraf - Kafka stack to seamlessly integrate with Event-Driven Ansible.
Even though Ansible validated content does not have support from Red Hat, you can make this content available in your private automation hub and it can help you complete important automation tasks.
The Knowledgebase article at https://access.redhat.com/support/articles/ansible-automation-platform-certified-content provides more information about the Red Hat Ansible Certified Content and Ansible validated content that is available.
You can create an ansible.cfg file in your project directory to configure your Ansible project to retrieve collections from your private automation hub, and enable either Red Hat Ansible Certified Content, Ansible validated content, or both.
The following is an example configuration in the ansible.cfg file:
[defaults] collections_paths = ./collections:/usr/share/ansible/collections[galaxy] server_list = rh-certified_repo, validated_repo
[galaxy_server.rh-certified_repo] url=https://hub.lab.example.com/api/galaxy/content/rh-certified/ token=c4f21af7090f0f9cb74d3c3f9e1748884ecdc180
[galaxy_server.validated_repo] url=https://hub.lab.example.com/api/galaxy/content/validated/ token=c4f21af7090f0f9cb74d3c3f9e1748884ecdc180
Ansible looks for collections in the | |
Ansible looks for both the Red Hat Ansible Certified Content and the Ansible validated content in this example configuration file. | |
Ansible uses the private automation hub API token to authenticate and download content. Private automation hub users generate their own tokens. |
Use the ansible-galaxy command to install a collection.
Use the --collections-path (or -p) option to install collections into a specific directory in your system.
The following example uses the ansible-galaxy command to download and install the ansible.eda collection into the collections/ directory:
[user@host ~]$ ansible-galaxy collection install ansible.eda -p collections/Like Red Hat Ansible Automation platform, Event-Driven Ansible has many use cases. The following are some examples of what you can use Event-Driven Ansible for:
Perform data collection to enrich the content of information you have in a security event
Realize basic network troubleshooting tasks
Remediate application deployment issues
Escalate infrastructure issues for human intervention
Automate action for security incidents
Maintain compliance for your infrastructure
Trigger application redeployments
Perform cloud state checks
Update your CMDB infrastructure records based on changes from events
By integrating Event-Driven Ansible with an IT service management such as ServiceNow, you can automate the creation, updating, and escalation of tickets from events in your IT domain.
The following is an example scenario:
You create an Ansible Rulebook that detects the state of the ports in your network infrastructure.
After receiving an event that the status for a port on a network device is down, Event-Driven Ansible collects additional data that might be relevant to the issue.
Depending on the event, Event-Driven Ansible might create a ServiceNow ticket with the gathered data, escalate an existing ticket after adding the gathered data, or run a workflow job template to remediate the issue.
If you automate the remediation of known issues in your IT domain, then Event-Driven Ansible can enable your team to spend more time on tasks that add value to your organization. This type of automation also improves your company average remediation time to solve issues.
For example, you can create an Ansible Rulebook capable of restarting services, redeploying applications, or carrying out non-complex tasks in your environment. By defining the correct conditions, you can enable Event-Driven Ansible to remediate system issues without interrupting your technical engineering staff. Event-Driven Ansible can help you build a self-healing infrastructure.
You can use Red Hat Insights as a source of events. The Red Hat Insights service can identify issues with your managed systems. By using this event source, you can enable Event-Driven Ansible to proactively correct potential security or compliance issues.
For example, by gathering all recommendations from Red Hat Insights, you can filter the recommendations that are relevant to your infrastructure, and then create actions to remediate any security issue, or configure your systems to the Red Hat-recommended standard.