Bookmark this page

Chapter 1.  Getting Started with Event-Driven Ansible

Abstract

Goal

Create Ansible automation that can run playbooks based on events delivered from various supported sources.

Objectives
  • Explain what Event-Driven Ansible is, why it is important, and describe its architecture and some of its key use cases and benefits.

  • Read, write, and test basic Ansible Rulebooks that react to events from various sources.

Sections
  • Introduction to Event-Driven Ansible (and Quiz)

  • Creating and Testing Ansible Rulebooks

  • Acting on Webhook Events (Guided Exercise)

  • Acting on System Journal Events (Guided Exercise)

  • Acting on Results from the URL Check Plug-in (Guided Exercise)

Introduction to Event-Driven Ansible

Objectives

  • Explain what Event-Driven Ansible is, why it is important, and describe its architecture and some of its key use cases and benefits.

Event-Driven Ansible

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 Components

Event-Driven Ansible works by using rules to connect the events it might receive with the corresponding actions to take.

Figure 1.1: How Event-Driven Ansible Works

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-inDescription
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.

Event sources

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.

Rules

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.

Conditions

An event of interest that is used to match a rule. Conditions use operators to compare Booleans, numerical data, and strings.

Actions

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.yml

Rulebooks are discussed in more detail later in the course.

Running Ansible Rulebooks

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

Running Ansible Rulebooks from the Command Line

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 register
  • Use 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-runner

Running Ansible Rulebooks with Event-Driven Ansible Controller

The 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:

Figure 1.2: Architecture of Red Hat Ansible Automation Platform 2.4

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.

Content for the Event Source Plug-ins

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

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-inProvided byDescription
redhat.insights_eda Red HatContains the event source plug-in for receiving events out of Red Hat Insights
crowdstrike.falcon CrowdStrikeReceives events from CrowdStrike Falcon Event Stream
dynatrace.event_driven_ansible DynatraceCaptures all problems from your Dynatrace tenant
ibm.instana IBMProvides the ability for Instana event data to be consumed by Event-Driven Ansible
logicmonitor.integration LogicmonitorIncludes the required plug-ins to interact with the infrastructure monitoring platform
paloaltonetworks.panos Palo Alto NetworksEnables automation of operational tasks on Palo Alto Networks Next Generation Firewalls

Ansible Validated Content

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.

Getting Content from Private Automation Hub

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 1

[galaxy]
server_list = rh-certified_repo, validated_repo 2

[galaxy_server.rh-certified_repo]
url=https://hub.lab.example.com/api/galaxy/content/rh-certified/
token=c4f21af7090f0f9cb74d3c3f9e1748884ecdc180 3

[galaxy_server.validated_repo]
url=https://hub.lab.example.com/api/galaxy/content/validated/
token=c4f21af7090f0f9cb74d3c3f9e1748884ecdc180

1

Ansible looks for collections in the collections_paths directive defined in the ansible.cfg configuration file. That directive specifies a colon-separated list of paths on the system where Ansible looks for installed collections.

2

Ansible looks for both the Red Hat Ansible Certified Content and the Ansible validated content in this example configuration file.

3

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/

Event-Driven Ansible Use Cases

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

Fact and Ticket Enrichment

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.

High Occurrence of Low-complexity Issues

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.

Security and Compliance Automation

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.

Revision: do274-2.4-65daa25