Red Hat Ansible Aims to Simplify Automation with Tower 3
With several layers of processes now being considered part of a data center’s infrastructure, any company promoting a “new way to automate the data center” could be playing to the DevOps community, to data center managers, or to CIOs. On Wednesday, Red Hat announced an update to its Ansible Tower automation package — and if you’re immediately thinking, let’s notify the DevOps team, hang on a moment. That’s not the audience that Red Hat is aiming for this time.
As Tim Cramer, Red Hat’s senior director of Ansible engineering, told The New Stack, Ansible Tower version 3 is a play for all those IT managers and executives on the other side of the bridge from the typical DevOps users of Ansible Core.
“We typically see Ansible Core as a very bottoms-up kind of use,” said Cramer. “We have a lot of people who find it on the net; it makes their jobs easier, and as they get going with it, it catches fire within an organization. Tower seems to be a little more top-down on the sale, where it’s more about managers who come in and start putting a bit of control over how Ansible is used in their organization.”
To appeal to this managerial crowd, Ansible Tower has been packaged as a type of application. For version 3, the front end has been completely redesigned for a new usage model, amping up the dashboards and data summaries that have already made the real-time analytics market so popular with managers and execs.
“We rewrote our back end, and [added] a new visualization in the front end,” said Cramer. “It used to be kind of difficult to figure out, especially for a first-time user, how they could actually get access to a playbook and run it. So they would have to get access to the job template and to the inventory, you’d have to have these different permissions available, and you’d have to figure out how to give them those permissions — it was pretty confusing. If you got it down, it was great, but you had to get there.”
With the new visualization scheme, the old “wizard”-like scheme of traversing categories has been replaced, Cramer told us, by a two-pane layout that he admitted was partly inspired by the success of Amazon AWS. Categories are listed in a column on the left, and details are presented in a set of scrollable pages on the right. Graphics have been simplified and streamlined, such as in the example at top. He said it should also make life easier for operators who just want the stdout values from Ansible commands.
A new round of integration with Slack enables operations team members, their managers, and the Ansible platform to effectively collaborate together, responding to a newly formalized set of notifications as they happen, such as the example at right.
“On the successful or unsuccessful completion of a job,” explained Cramer, “you can have a notification that goes out via e-mail, HipChat, Slack, IRC, or a general web hook. So you can hook it into, say, BMC [Service Desk] or ServiceNow, and that can cause the kick-off of the next item in the process.”
For example, he went on, suppose a developer executes code that starts a round of automated tests. When those tests come back positive, Tower 3 can produce a message that may then be consumed by ServiceNow. This way, a production operator can be notified when tests are complete, so she can push that code to production.
You Can Read This
In recent months, Red Hat has been promoting Ansible Tower to customers’ executives by way of a use case involving specialty clothing retailer J. Crew. At the last few Red Hat events, including the recent Red Hat Summit and the preceding AnsibleFest, Red Hat made the case that Tower produces reports that are digestible by folks outside of operations.
A recent company blog post summarized this part of the use case, saying in part, “In their implementation of Ansible Tower by Red Hat, [J. Crew] found that the tool generated great reports. They created reports for managers, QA teams, etc. Through these reports, they were able to automate the mundane and got rid of meaningless work. After all, if you hire smart people, you want them to solve problems, not worry about things like copying files all day.”
But not unintentionally, Red Hat’s Colby Hoke immediately followed that sentence with a mention of tower-cli, a command line interface. You might think that any command line-based tool would be custom made for DevOps professionals only, by default. But Hoke made the point that the CLI tool enables Ansible to be integrated with an organization’s existing configuration management and automation frameworks, including Jenkins.
That message may be just as interesting for a CIO as the news that reports can be read aloud.
“For Chef, you really need to be able to program — you have to be a Ruby developer to really make the product do the automation that you require,” Ansible’s lead engineer explained. “With Ansible, you don’t. It’s a domain-specific language, YAML, and it’s made so that a person who writes shell scripts can easily pick it up. People will grab Ansible and start automating things within a few hours.”
Also for Tower 3, he told us, “we now have the ability to automate physical networking.” He’s referring to the ability to address networking switches and other appliances directly, including parts from Cisco, Juniper Networks, and Cumulus — a feature which was added to Ansible Core 2.1 last February.
Now, with the ability to address network appliances too old to include their own APIs, the physical networking automation feature helps Red Hat bolster its case in favor of integration — another watch-word that’s close to the heart of Tower’s target audience.
Red Hat is a sponsor of The New Stack.