We hope that 2019 will be a great year and the Ansible team is here to start it off right. We're happy to announce that Red Hat Ansible Tower 3.4 is now generally available. In this release, there are several enhancements that can help improve automation practices. Engineering has been working hard to enhance Red Hat Ansible Tower. We're most excited about workflows enhancements, job slices, and some other nifty features. Let’s dive a little deeper into what we’re excited about in this release.


Workflow Enhancements

The enhancements to workflows in Red Hat Ansible Tower 3.4 are a combination of internal and customer requested features. This is designed to bring needed hybrid cloud management capabilities to engineers and administrators around the globe.

Workflow Convergence

Workflow convergence enables a convergence step that tracks the completion of multiple workflow jobs before continuing. For example, when deploying application updates there might be a need to wait until a group of nodes drains from a load balancer pool before having a service stopped on any node in the group. This helps enable a more complete dependency chain for jobs inside workflows.

Ansiblt-Tower-Covergence-Workflows

Nested Workflows

Workflows have been able to have job templates and inventory/project sync operations for quite some time. Now, we have added the ability to have workflows within workflows. As systems become larger and more complex (or smaller but numerous and distributed), it is likely that workflows with their existing business logic and organizational requirements could become reusable, modular components on their own. The ability to nest workflows allows for even more complex operations to occur as desired with the same ease of use Ansible is known for.

Workflow-level Inventory

One of the great things about Ansible is its modular nature. Ansible Modules extend Ansible’s capabilities beyond core functionality. Ansible Galaxy distributes Ansible Roles as modular infrastructure as code. But, workflows in Red Hat Ansible Tower have depended on the Inventory from job templates. This is no longer the case. Specifying an inventory for a workflow that can then be used by every job template in that workflow continues the Ansible way.

Workflow Always Job Templates

The ability to have workflows execute jobs on success or failure is important when, for example, chaining together workflows. But, what if there are automation steps that should always occur during a workflow (like cache warming or service management)? Workflow always job templates enables execution regardless of success or failure. If a dependent service needs to be running regardless of the exit status of a workflow then a workflow always job template should be a welcome feature.

Job distribution via Job Slicing

Our quality engineers said it best when stating, “When running a job across a large number of hosts, an appropriate fork count is issued, and cycling occurs until the job is done. Job distribution will slice a job into separate executions on a subset of Ansible Inventory that can be scheduled in parallel.” In a nutshell, Red Hat Ansible Tower users are now able to parallelize jobs across nodes in the Ansible Tower cluster with auto job slicing.

Additional Improvements

There are a few others noteworthy features in Red Hat Ansible Tower 3.4 that merit a mention. This release shepherds in support for running Red Hat Enterprise Linux in FIPS compliant mode. This enables organizations working within NIST Federal Information Processing Standard guidelines to use Red Hat Ansible Tower’s abilities to integrate, control, and scale automation across hybrid cloud environments.

The settings menu in Red Hat Ansible Tower has also been modified. The premise is to group settings with their most likely to be used counterparts under separate tabs. Options used most in day-to-day automation processes are grouped. Menu items most used by folks making things for others to use in Ansible Tower are another grouping. The final grouping is options for the management and operation of Ansible Tower itself. We hope this organization improves the experience for every user.

Red-Hat-Ansible-Tower-Menu

As with most Ansible Tower releases Red Hat Ansible Tower 3.4 features its own smattering of bugs that have been vanquished, performance tweaks, and technical debt management. Happy automating!

Try Red Hat Ansible Tower Today

You can try the latest version of Red Hat Ansible Tower via local install, Vagrant, or Amazon AMI.

Also, please join us for our What's New webinar on Jan 23 at 11AM EST to hear about the latest update to Red Hat Ansible Tower. We'll discuss and demo some of the new features in Ansible Tower 3.4.
 

 


About the author

Chris Short has been a proponent of open source solutions throughout his over two decades in various IT disciplines including systems, security, networks, and DevOps engineering and advocacy across the public and private sectors. He currently works on the Ansible team at Red Hat. Chris is a partially disabled US Air Force veteran living with his wife and son in Greater Metro Detroit. Chris writes about DevOps and other topics at chrisshort.net. He also runs the DevOps, Cloud Native, and open source focused newsletter DevOps’ish.

Read full bio