Level up your automation with Event-Driven Ansible and Red Hat Consulting

In today’s fast-paced, highly competitive world that is driven from “digital business”, organizations are being asked to do more with less. At the same time, key applications and IT services are more critical than ever and so must be up and running to drive revenue, productivity and more. To be able to be successful and not succumb to the Day 2 operational pressures you face, the need to automate is clear. By incorporating Red Hat Ansible Automation Platform as the common automation solution, at enterprise scale, organizations have begun to realize benefits, including a reduction of manual actions, centralization of automation assets and highly flexible cross-team collaboration.

However, organizations are continuing to struggle in several areas, which challenges the effectiveness of the incorporation of these technologies and processes:

• Responding to changing conditions that occur throughout the enterprise
• Proactively addressing situations before they become critical issues
• Resolving issues in a timely fashion

Each of these items can be time consuming and repetitive. Sound familiar? Yes, this is indeed yet another opportunity where automation can play a role to aid in common challenges faced by organizations. This is exactly what Event-Driven Ansible, part of Ansible Automation Platform,  is positioned to solve for.

Event-Driven Ansible represents the next phase in automation maturity, as it is designed to automatically activate automation based on events -- all within a single solution. For example, instead of a ticket appearing and requiring investigation “from scratch”, you can set up the automated end-to-end actions you desire. This may start with automatically generating a service ticket when the issue appears, to automatically gathering facts to expedite ticket resolution when someone receives the ticket, to doing remediation steps automatically. The choice is yours – you may choose to start with simple automated actions and increase in sophistication as you gain more experience with event-driven automation.

The result: faster response and freeing up of resources so individuals can instead work on items that deliver business value. All the while, users can leverage the catalog of automation that has been previously developed and even used as part of a standard response process within a new paradigm.

Solving common challenges with Event-Driven Ansible

Consider the typical types of activities that occur in an organization and where Event-Driven Ansible can play a role.

Automated remediation

Understand actions that occur throughout the enterprise. Instead of issues going unnoticed or tasked within traditional ticketing systems, they can be addressed in an automated fashion. In addition, resolve them prior to becoming a full-blown issue that has a bigger or longer impact. With items that would traditionally require manual invention, teams are able to innovate and focus on higher priority items which provide greater business benefits.

IT resilience

Proactive monitoring (through observability and monitoring tools) coupled with a  response (through event-driven automation) allows organizations to have a greater understanding of the ongoing operations within the business. This enables continuous operations with diminished  impacts, such as service interruptions or outages. Organizations can invest in technology initiatives that innovate rather than sustain.

Amplifying automation practices

The adoption of automation introduces several paradigms that benefit development teams, operations personnel and the business itself. Infrastructure as Code (IaC) takes operational knowledge out of the heads of skilled team members and codifies it for consistent use. This in turn makes it more discoverable and increases the awareness of the tasks that keep the business running. Incorporating version control ensures the codified processes are effectively tracked as part of a standard Software Development Lifecycle (SDLC).

How does Event-Driven Ansible work?

Event-Driven Ansible comprises three components working in tandem: Event Sources, Rules, and Actions. This delivers an end to end solution connecting events occurring within an operating environment, intelligence on whether to act upon the condition, and the automation to remediate if necessary. While a playbook is the driver behind traditional Ansible automation, Event-Driven Ansible makes use of a rulebook to drive the execution. This YAML formatted document defines how the three components are tied together. The following is an example of an Event-Driven Ansible Rulebook:

- name: Hello Events
 hosts: localhost
 sources:
   - ansible.eda.kafka:
       host: kafka
       port: 9092
       topic: orders
 rules:
   - name: Say Hello
     condition: event.target_os == "linux" and event.tracking_id == 345
     action:
       debug:
         msg: “{{ event }}”

To further understand the composition of a rulebook, let’s break down the three key components in further detail:

Event Sources:

Event Sources provide a bridge between Event-Driven Ansible and the activities that occur in a dynamic organization. These plugins are purpose built integrations with specific intelligence for the particular entity to capture events and provide them in a format that can be processed and assessed.

 sources:
   - ansible.eda.kafka:
       host: kafka
       port: 9092
       topic: orders

Several event sources are available by default from the ansible.eda collection and include Kafka (as shown in the example above), Prometheus Alertmanager, and more. They will typically include details related to how to integrate with the component and influence how the event is formatted. Alternate options are also available from Red Hat’s partner ecosystem and more. . If a plugin is not available for a desired system integration, Event-Driven Ansible includes a framework for developing your own custom Event Source plugins , making it easy to integrate and ingest events from any resource.

Rules:

Events, once captured into Event-Driven Ansible, require processing to determine whether action should be taken or not. A decision engine, provided by the Drools framework in Event-Driven Ansible, is used to assess the activity, filter events using conditional logic in an “if-this-then-that” style, and then trigger a related activity when a condition is met. Note that existing Ansible Playbooks can be called as part of your rule – so you are able to extend use of existing trusted Ansible automation content you already have. 

The following is an example of a rule that assesses whether an event matches multiple conditions:

condition: event.target_os == "linux" and event.tracking_id == 345

The use of a rules engine enables complex logic to be applied based on the types of events that have been captured. 

Actions:

Once a condition has been triggered, an action can be applied to perform an associated activity. These activities are where traditional Ansible automation can be applied. This includes invoking a module or playbook, or triggering a job template from within Ansible Automation Platform. Actions can also tie into the Drools framework to influence how future decisions are applied.

The following are some of the most common actions that can be used to trigger activities:

• run_playbook - executes an existing Ansible Playbook

• run_job_template - executes a job template found within Ansible automation controller

• set_fact - inserts information about an event into Event-Driven Ansible for subsequent event/action processing

• debug - prints user provided details or information related to the event

What are Decision Environments and when are they needed?

Once a rulebook has been created, it can be executed using the ansible-rulebook command-line interface. However, similar to traditional Ansible development, the automation being implemented may require additional dependencies, such as collections, packages and other tools. Decision Environments (DE) build upon the same concepts as automation execution environments by packaging the necessary components and dependencies into an executable container image. The result is a portable environment for running Event-Driven Ansible Rulebooks.

Each of these components, coming together, provides the baseline for a whole new realm of automation opportunities.

Managing Event-Driven Ansible with ease

The tooling included as part of Event-Driven Ansible consists of a series of command-line utilities and supporting components. Starting with version 2.4 of Ansible Automation Platform, support was added to include the Event-Driven Ansible ecosystem to simplify the management of Event-Driven activities. Benefits include:

Lowering the barrier of entry

Organizations come in all shapes and sizes, and automation activities should not be performed as bespoke operations. Ansible Automation Platform with support for Event-Driven Ansible provides a way to organize all of the components and activities in a single user interface, making it easy to set up, configure and operate. There is no longer a need to run command-line operations or set up and install tooling on individual machines in order to achieve the same functionality provided by Event-Driven Ansible.

Familiar workflow for Ansible Automation Platform users

For users who have prior experience working within Ansible Automation Platform, Event-Driven Ansible features many of the same constructs, so getting up to speed is a breeze. Resources, such as Projects and Credentials, have the same meaning, while others have their own Event-Driven Ansible construct. Instead of Execution Environments, Event-Driven Ansible executions are performed within Decision Environments. This provides an operating environment for Event-Driven Ansible Rulebooks and includes any of the dependencies that they require.

Operating with a security first mindset

“Shadow” development and operations are real struggles in many organizations. Instead of each individual working in their own environment with their own tooling and development processes, Ansible Automation Platform provides a centralized management and execution plane for Event-Driven-Ansible. The centralization of Event-Driven Ansible components, including Decision Environments and Rulebooks, ensures that only sources from trusted contents can be used while applying Role Based Access Control (RBAC) paradigms to increase security and reliability. 

Expected outcomes

In addition to these benefits, impactful business outcomes will include:

• Reduced event response time for tracked event sources
• Reduced overall number of tickets/event responses
• Automated decision making for repeatable and known tasks
• The ability to create further rulebooks and enhance automation processes

Automation has greatly reduced the time necessary to complete tasks, but still these tasks often require manual identification, intervention and execution to resolve issues. This can cause reduced productivity through constant context-switching, or worse, after-hours or on-call work to resolve. Event-Driven Ansible can help fill that gap, analyzing event sources and automatically running automation to resolve issues, no human input required. To help ease this integration, organizations have sought the knowledge and experience of Red Hat Consulting to leverage the possibilities that Event-Driven Automation can offer.

Red Hat Consulting can help organizations get started

Red Hat Consulting has helped organizations develop an automation journey built around Ansible and Ansible Automation Platform to transform their business by assessing current processes, identifying areas of focus, and implementing solutions. Event-Driven Ansible represents the next step in this journey, taking advantage of advanced automation approaches and intelligent operations.

As Event-Driven Ansible is a new feature released with Ansible Automation Platform 2.4, it might be challenging to jump right in and understand how to use these new features. Red Hat Consulting brings real-world expertise and hands-on mentorship to help break down complex use cases and ease teams into this technology.

Red Hat Consulting provides a 3-step approach to help organizations with Event-Driven Ansible implementation:

Analyze

In this phase, Red Hat Consulting conducts a discovery and analysis of use cases and available source plugins. These source plugins are vital to provide the events required to make decisions on. It is important to involve any teams that would be affected by this automation to obtain early input on requirements. We categorize any events and define workloads that will be automated.

Design

This phase will be where the business logic required to take actions on specific events will be defined. This logic is defined in Rulebooks, which are documents that are similar to Ansible Automation Platform Playbooks. The syntax is slightly different, but still defined as YAML.  It is also how the Red Hat Consulting team identifies any existing automation that will be executed on a matched event.

Integrate

This is the phase where integration and implementation of the Event-Driven Ansible Controller and associated Rulebooks are configured. Validation of all Rules and Actions via Playbooks are also tested.

Batteries included

Event-Driven Ansible is a “batteries included” solution and contains a number of source plugins by default. To view what is included, refer to the EDA Collection ansible.eda. Additional plugins are available as part of certified and validated collections in Automation Hub. The latest list can be viewed here. Don’t see something you can use? Consider building your own source plugins.

Interested in learning more?

Read the datasheet to learn more about the Red Hat Consulting Event-Driven Ansible solution and how organizations can get started.