Introducing Ansible Tower 3.1

March 1, 2017 by Bill Nottingham

Ansible Tower 3.1

We're excited to announce the release of Ansible Tower 3.1. Our engineering team has been hard at work on enhancing Ansible Tower to allow teams to harness the power of automation across servers, applications, environments, and networks, and with Ansible Tower 3.1, we've brought together a variety of enhancements that allow your teams to automate more processes, more frequently, and more easily analyze the results of your automation across the enterprise.

Model complex processes with multi-Playbook workflows

Ansible brought simple, agentless automation to IT. But some IT processes don't lend themselves to being automated in a single Playbook - if you're provisioning environments, you may want to handle basic provisioning, default configuration, and application deployment differently. And once you've automated those tasks, you want to reuse those tasks in different ways, or in different environments. Plus, what if a deployment goes wrong? You may need to back your environment out to the last known good state.

To solve these issues, we developed Tower workflows. With Tower workflows, you can chain together any number of Playbooks together into a workflow, with each workflow step potentially using a different Playbook, inventory, set of credentials, and more. Easily launch one or more tasks after any step in the workflow, or run a cleanup Playbook on failure if needed. Utilize the new `set_stats` feature of Ansible to pass information between Playbook runs.

Ansible Tower workflow

Just like any other piece of automation in Tower, workflows can be delegated to other users and configured with Tower surveys, Whether you're trying to provision, configure, deploy, and scale your environments or build, test, promote, and verify in your CD pipeline,  Tower workflows allow you to automate complex processes with ease.

Scale out automation with Tower clusters

As automation becomes more common in your environment, you need extended availability and increased capacity for your automation. We've designed Tower clusters with this in mind.

With Ansible Tower 3.1, multiple Tower nodes become a Tower cluster, where each node provides additional redundancy and job running capacity. Jobs will run on any available node, and users can connect to any node (or to their load balancer) to view the status of their automation. Easily add new capacity to your deployment by spinning up new Tower nodes to join the cluster.

Plus, if you're running multiple Tower nodes in a cluster, it's critical that the Tower configuration stays in sync. That's why we've moved Tower configuration into Tower itself, automatically synchronized across your cluster. Configure Tower via the in-Tower UI, or via the Tower REST API.

Analyze enterprise-wide with enterprise logging integrations

One of the key features of Tower providing an API around Ansible automation is to log who did what, where, and when. But automation shouldn't be its own silo of information. To truly understand and manage your infrastructure, you need not just knowledge of your automation, but knowledge of how your automation affects your environment.

That's why we built Tower integrations for enterprise logging. Ansible Tower 3.1 allows you to send any and all information from Tower - automation logs, audit activity, service logs, and system facts - to an external log aggregator for analysis with the rest of your environment. If your application starts showing increased response time, easily correlate it with the deployment that may have caused it, and then use Tower's REST API to automatically run a remediation playbook.

Ansible Tower 3.1 ships with logging integrations for Elastic, Splunk, Loggly, SumoLogic, and generic REST API endpoints.

Download free whitepaper: A Beginner's Guide to Control with Ansible Tower 

Easily find what you're looking for with Tower smart search

In Tower 3.1, we want to make it easier to find the templates, inventories, and jobs that you're looking for. Tower's new smart search allows for easy key:value searching of nearly any component of Tower.

Ansible Tower Search

Need to find all job templates that use a particular inventory, or look into all jobs that ran between 2AM and 3AM? No problem. Bookmark common searches in the browser to use later. 

Drill down into the details with enhanced job output

As part of this search across Tower, we've made job output even easier to filter for the actions and results that you're looking for.

Ansible Tower Job Output

Filter by host, by success/failure, by module, and more. Click on any task from the job run to get details.

Try the new Ansible Tower

Ansible Tower 3.1 is available today for Red Hat Enterprise Linux 7, CentOS 7, Ubuntu 14.04, and Ubuntu 16.04. Try the latest version of Tower now via local install, Vagrant image, or AMI.


Ansible Tower


Bill Nottingham

Bill Nottingham is a Product Manager, Ansible, Red Hat. After 15+ years building and architecting Red Hat’s Linux products he joined Ansible ... which then became part of Red Hat a year and a half later. His days are spent chatting with users and customers about Ansible and Red Hat Ansible Tower. He can be found on Twitter at @bill_nottingham, and occasionally doing a very poor impersonation of a soccer player.

rss-icon  RSS Feed