Red Hat announced the general availability of its Ansible Tower 3.3 release, which provides new automation capabilities for organizations.
Among the new features in Red Hat Ansible Tower 3.3 is an updated user interface that provides more information to users. Scalability is another area where Red Hat has improved Ansible Tower, with new ways to organize clusters. Additionally, Red Hat now finally enables its Ansible Tower users to run on its OpenShift Container Platform.
“Running on OpenShift was not a supported configuration prior to this release,” Justin Nemmers, general manager of Ansible at Red Hat, told eWEEK. “We’ve now made this a point-and-click effort by pre-packaging Tower as an OpenShift Container application pod.”
Red Hat acquired the Ansible, DevOps automation and configuration management technology in October 2015 and has continued to evolve the technology capabilities ever since. Ansible Tower is the management platform for Ansible Engine automation activities. The Ansible Tower 3.3 release includes Ansible Engine 2.6, which was released on July 17.
OpenShift is Red Hat’s Kubernetes-based container orchestration platform that in recent years has become the core platform for Red Hat’s application delivery efforts. Although Ansible Tower now supports OpenShift, Nemmers noted that Red Hat will also continue to support Tower in other environments that are either virtual machine or bare-metal based.
Scalability
Scalability has been improved in Ansible Tower 3.3 in a number of ways. Nemmers explained that Ansible Tower 3.3 builds on Instance Groups, which allow for reserving Ansible Tower cluster capacity for specific organizations, inventory, or jobs. He added that with Ansible Tower 3.3, users can now create Instance Groups to manage capacity directly from the Tower UI and API. Additionally, Instance Groups can be defined by percentage of total cluster capacity.
“These new features in instance groups improve how to manage capacity in Ansible Tower without having to restart the cluster,” Nemmers said. “Plus, Ansible Tower when deployed in OpenShift can be easily scaled via the OpenShift CLI, API, or UI.”
Customization
Ansible Tower 3.3 also enables organizations to run customized Ansible automation environments. Prior to the 3.3 release, Ansible Tower could only make use of only one version of Ansible Engine to execute its automation.
“For those organizations that have different teams that have standardized on different versions of Ansible, or customized sets of Ansible modules, we’ve enabled Tower to accommodate their use cases, too,” Nemmers said. “Each Ansible Tower Job Template can be told to use a specific underlying Ansible environment, provided by the customer.”
One area of customization that isn’t in Ansible Tower 3.3 is integration with the Ansible Galaxy repository. Ansible Galaxy 3.0 was released at the time of the Ansible Engine 2.6 update in July, providing organizations with a public-facing repository to share Ansible content. Nemmers said to “stay tuned” for future news on Ansible Galaxy and Ansible Tower integration.
“We’re going to continue to focus on scalability and performance, while working to further lower the barriers that prevent teams for fully embracing and extending automation,” Nemmers said. “We’ve got a lot of really cool things we’ll be highlighting at AnsibleFest Austin the first week of October.”
Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com. Follow him on Twitter @TechJournalist.