Tower 2.2 is Here

July 23, 2015 by Bill Nottingham

We’re happy to announce that Ansible Tower 2.2 is now available.

Ansible Tower is the console and service that builds on the solid foundation of Ansible’s simple automation to bring the control, security, and delegation you need to spread automation across your IT infrastructure. We’ve worked hard to update Tower to bring new capabilities to our users.  I’ve talked about these some when I discussed how Tower 2.2 was coming soon - now I’d like to go into a little more detail.

Refreshed UI with Setup Mode

dashboard.png

We’ve talked to many of our customers who use Tower on an everyday basis. And the continuing refrain is:

“Foreground the stuff we need every day. Background what we don’t.”

We’ve started that process with Tower 2.2.  First, you’ll notice the changes on the dashboard, where we’ve removed extraneous graphs so you can concentrate on the important information - are your hosts OK, and are your jobs succeeding. Plus, you’ll see lists of both recent completed jobs, and recently used playbooks.

We’ve also added sparklines to the display of job templates so that wherever you’re seeing your job templates, you have an easy visual display of how that job template has been performing recently. Combine this with the dashboard graph and the new simplified completed jobs screen, and now administrators can easily check on the health of their infrastructure and deployments.

Screen_Shot_2015-07-23_at_8.23.31_AM

Across the top of Tower, you’ll see that now we only display the important items you need for your everyday deployments - your projects, your inventories, your job templates, and your completed jobs.  If you need to add or edit users, teams, credentials, or other Tower administration details, these are now accessible via Tower’s setup menu, available via the setup icon on the top right of the display.

We’re going to be doing more work in future versions of Tower to make it even easier to run the automation you need. Stay tuned!

System Tracking

system-tracking-select-one-host-one-date-module-expanded.png

 

Automating your configurations and deployments is great. But sometimes you need more information on top of that. Sure, I’ve applied updates every week, but how do I know when I applied a particular security fix without reading all the playbook events?

One server in your cluster is misbehaving - did someone change it by hand since the last playbook run?

With Tower’s new System Tracking feature, we aim to give administrators the rich source of data and the views they need to answer these sorts of compliance questions.  We’ve done this by creating a new job type, called ‘Scan’ jobs, tied to a particular inventory.

By default, we ship a scan job that, for each machine, tracks the packages, services, and Ansible facts for that machine, plus information on any files that the administrator wants to track.  We also allow you to extend this, so anything you can write an Ansible fact module for, you can track with System Tracking - whether it’s detailed hardware information, or the state and version of your custom deployed application.

Once you’ve run these scan jobs (either in a push-button manner, or scheduled just like any other Tower job), you now have a detailed, updated snapshot of your environment. If you go into Tower’s inventory view, and select a host or two, you’ll see the new ‘’ icon to enter the System Tracking view.  From here, you can view how a host compares to an earlier version of itself, or how a host might compare to other hosts in a cluster.

Plus, this data is available through Tower’s REST API. We’re excited to see the new use cases and applications unlocked by this System Tracking data.

Remote Command Execution

 

ad-hoc-commands-inventory-run-command.png

Ansible playbooks are great for automating your configuration, automating your deployments, or even for automating complex provisioning rollouts or rolling upgrades. But there still are times when you need to do a simple task on a host or group of hosts, whether it’s adding a user, restarting a misbehaving service, or doing a quick update for a security fix. Or maybe you haven’t gotten all your playbooks written yet for full automation, and still need to get some simple things done. Ansible users have long been able to do one-off ansible commands from the commandline to do this. With Tower 2.2, you can now do it even easier from Tower.

Just go to Tower’s inventory view, pick a host, or group of hosts, and click on the ‘Launch’ button to run a remote command. Here you’ll be able to pick what ansible module to use for the command from a list of commonly used modules (administrator customizable and restrictable, as always), pass whatever arguments to the command you need, and launch the command.

As always, this is tracked in Tower’s database for easy auditing and review later. Plus, since great power comes with great responsibility, it's tied to a new permission in Tower, so you can restrict this ability to only those users who need it.

Galaxy Integration

To build out repeatable, reliable infrastructure, you must have standardization. You want as few points of difference as possible. Ansible has long had Ansible roles for easy reuse of Ansible content between playbooks and between environments, and the Galaxy site for sharing them.

Now Tower makes it easy to share roles between your playbooks and your projects, whether you keep your roles on Ansible Galaxy or just in a git repo such as on GitHub.  Just create a ‘roles’ subdirectory and add a ’requirements.yml’ file to that directory.

For example, to pull a role named ‘frobozz’ from github

Or to pull it from Ansible Galaxy:

  • src: someuser.frobozz

For more information on the requirements format, see http://docs.ansible.com/galaxy.html#advanced-control-over-role-requirements-files

Inventory Support for OpenStack

We’ve built Tower so you can have a common deployment pipeline whether you’re using baremetal servers, on-premise VMware, or public cloud infrastructure like Amazon AWS. With Tower 2.2, we’ve added the ability to pull inventory from OpenStack as well, so you can easily catalog all the machines and environments you have running on your private cloud, and deploy to them just like any other part of your infrastructure. Just create a new inventory group, select ‘OpenStack’ as the source, and use your OpenStack user/key/project credentials, and you’re good to go.

Tower 2.2 Demo

 

 

Expanded Documentation

To help everyone be successful with Tower, we’ve split and expanded our Tower documentation. You can find our guides at http://docs.ansible.com/, and linked below.

Quick Install Guide

Quick Start Guide

Tower User Guide

Tower Administration Guide

Install and Reference Guide

Share:

Topics:
Configuration Management, IT Automation, Ansible Tower, OpenStack


 

Bill Nottingham

Bill Nottingham is the Director of Product at Ansible. He came to Ansible from Red Hat, where he spent 15+ years building and architecting Red Hat’s Linux products. His days are spent chatting with users and customers about Ansible and 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

Ansible Tower by Red Hat
Ansible In-Depth Whitepaper
Ansible Tower by Red Hat
Learn About Ansible Tower