We are excited to announce the release of Red Hat Ansible Tower 3.2. Our engineering team has been working hard to enable Ansible Tower to provide the best platform for managing, executing, and delegating your Ansible automation throughout your entire enterprise, whether you’re managing servers, applications, networks, and more.

With Ansible Tower 3.2, we’re continuing to innovate in two main areas:

making automation more powerful and more flexible

enabling continued enterprise-wide deployment of automation

To do that, we’ve enhanced several areas of Ansible Tower, and I’m happy to talk about them today.

Enhanced Integration with Red Hat Insights







With Ansible Tower 3.1, we built the first step of our integration with Red Hat Insights - allowing you to sync Insights remediation playbooks to Ansible Tower for use as needed. We’ve continued to enhance this integration in Ansible Tower 3.2. Now, we bring the ability to view Insights Actions directly in Ansible Tower. With this, you can more easily see your minor, major, and critical issues, and with just a few clicks, schedule remediation with Insights Plans.

Built-in Fact Caching

Ansible facts give you powerful capabilities to adjust, branch, and conditionalize playbook execution based on discovered state on managed systems. However, gathering facts across all managed machines on each playbook run can be a time-consuming practice.

With Ansible Tower 3.2, we’ve added an integrated fact cache to Ansible Tower. Just check the ‘Use Fact Cache’ checkbox on a job template, and it will both read stored facts from Ansible Tower for that host, and store newly-found facts in Ansible Tower’s fact cache.

Smart Inventories

Ansible and Ansible Tower have long had the ability to pull inventory from whatever sources of inventory you may have - your public cloud, your private cloud, your local CMDB. However, sometimes you need to automate across your entire inventory - all machines tagged ‘public webserver’, or all machines running a vulnerable piece of software.

That’s why we created new Smart Inventories. Smart Inventories build off of Ansible Tower’s fact caching support, and allow you to create new inventories that contain all hosts that match your search criteria. This can be based on host attributes (such as groups) or gathered facts (such as manufacturer, installed software, services, and more). Plus, this inventory will automatically refresh to include all hosts that match the query whenever you use it.

SCM Inventories

Since the beginning, commandline Ansible users have taken to defining their infrastructure as code - not just in their playbooks, but in their inventory and variables as well. With Ansible Tower 3.2, we’ve worked to bring them into the fold, by supporting pulling inventory directly from source control.

To use this, just set a Project as your inventory source, and point to the file/directory you want to use for inventory. You can even use inventory scripts directly from source control.

Custom Credentials

Whether it's looking up secrets from a custom password vault, accessing a local CMDB, or connecting to a local infrastructure provider, we know that there are always going to be more things that users need credentials to access from their playbooks than we will be able to ship out of the box in Tower.

That's why Ansible Tower 3.2 introduces Custom Credentials. With custom credentials, you can define your own credential types to pass to both playbooks and inventory sources. So if you need to template out a file for your credential, or pass a key in an environment variable, you can still securely store these credentials in Tower and use them in your automation.

To create a new custom credential type, just go to Settings -> Credential Types. You'll define both the input (what fields make up your custom credential) and your injector (how these fields are exposed to the playbook/inventory). Once you've set up your new credential type, you can create any number of that new custom credential type... just as you would any built-in credential type.

Ansible Tower Instance Groups

Ansible Tower 3.1 introduced Ansible Tower Clustering. With Tower Clusters, you can have any number of Ansible Tower servers in a cluster, providing redundancy and increased job-running capacity.

With Ansible Tower 3.2 you can do all of this and more. We’ve introduced Ansible Tower Instance Groups. With Instance Groups, you can organize your Ansible Tower nodes into any number of groups. These groups can be dedicated to only serve particular organizations, inventories, and job templates. Want each organization in your Ansible Tower server to have their own capacity so they don’t DoS each other? Need to reserve capacity for your admin team to run emergency patching? With Ansible Tower 3.2, you can do all of this and more.

Ansible Tower Isolated Nodes

One of our goals with Ansible Tower is provide a deployment scenario to help end users, no matter how you need to automate, there is a Ansible Tower deployment scenario that can help. In Ansible Tower 3.2, we’ve built on top of Tower Clusters and Tower Instance Groups to introduce a new concept called Tower Isolated Nodes.

An Tower Isolated Node is a headless Ansible Tower node that can be used for local execution capacity, either in a constrained networking environment such as a DMZ or VPC, or in a remote datacenter for local execution capacity. All you need is SSH connectivity from your Tower Cluster to the Isolated Node. The Tower Cluster will send all jobs for the relevant inventory to the Isolated Node, run them there, and then pull the job details back into Ansible Tower for viewing and reporting.

Named URL

Even with Instance Groups and Isolated Nodes, you may decide to install separate Ansible Tower clusters for greater security, partitioning, or scale reasons. In that case, it can be tricky to have consistent access to automation via Ansible Tower’s REST API -- Tower job templates, inventories, and more are only accessible by their ID, which varies across separate clusters.

In Ansible Tower 3.2, we’ve introduced Named URL access to resources in Ansible Tower. For example, if I have a job template named ‘Deploy All The Things’, using project 'Deployment', in my organization ‘AppSquad’, I can access it via Ansible Tower’s REST API at:





https://tower.host/api/v2/job_templates/Deploy%20All%20The%20Things/



Try Ansible Tower Today

Ansible Tower 3.2 is available now for Red Hat Enterprise Linux 7, CentOS 7, Ubuntu 14.04, and Ubuntu 16.04. You can try the latest version of Tower via local install, Vagrant, or Amazon AMI.



Also, please join us for our What’s New in Tower 3.2 Webinar on Tuesday, October 10th at 2PM EDT.