Ansible 2.0, the major code rewrite of the open-source IT automation and configuration-management platform, is on track for a July release.
The coming code refactoring milestone to the technology, which moved to a development branch on June 1, will implement a host of new features and updates focusing on modularity, better object-oriented programming (OOP) and customizability. Components such as YAML parsing were overhauled to add more classes and general-purpose OOP functionality.
(Related: Highlights from last year’s AnsibleFest)
At AnsibleFest NYC, Ansible CTO Tim Gerla said Ansible has become an equalizing technology, and he talked about how the 2.0 codebase represents a mature point where the community and contributors can become the stewards of Ansible.
“Now that we’ve gotten this refactoring out of the way, we don’t want to break anybody’s playbooks,” said Gerla. “At this point, Ansible is really stable and mature, and the community approach—especially in Ansible’s modules—are crucial, and we’re working on anything we can do to remove any kind of funneling restrictions on those contributions going forward.”
James Cammarata, Ansible’s director of core engineering, ran down the major new features and changes in Ansible 2.0 as part of a concerted effort to ensure 100% backward compatibility with Ansible playbooks. One of the biggest new features he mentioned was blocks.
Allowing for easier grouping of related tasks, blocks in Ansible 2.0 are a method for catching errors during task execution. Blocks enable try/except handling, Cammarata said, giving developers the ability to execute a set of tasks regardless of whether an exception has occurred, and to execute code cleanup at the end of a deployment.
Ansible 2.0 also rolls out a new execution strategy. Developers will be able to combine the traditional linear strategy of waiting for a host to complete all tasks with a new free strategy of running through task lists as fast as possible. The strategies exist as a playbook-level setting and, as Cammarata explained, act essentially as plug-ins.
“These are Ansible plug-ins,” he said. “A lot of the functionality in Ansible is based on plug-ins, and this is just another type you can write.”
Other noteworthy features in Ansible 2.0 include a dynamic “Include+” action for task evaluation, a new VariableManager class to better control the order and source of variables, and improved error messages that show any Ansible playbook error—even those unrelated tot syntax—with the file along with the line and column where the error occurred.
Cammarata said all these features play into Ansible’s focus on OOP to emphasize more modularized roles: Each class does one thing and does it well, leading to better unit testing and streamlined deployment.
“The end goal is to make things much easier to test with unit tests,” said Cammarata. “So when code changes come in, we can have Jenkins let us know immediately whether a change broke unit tests.”
Modules, API changes and beyond
Cammarata explained that while playbooks won’t change, the code overhaul did necessitate differences in internal Ansible APIs such as Connection and Action. Ansible is working on developing a transition class and plug-ins to make it easier to migrate and ensure Ansible 2.0 compatibility.
Ansible 2.0 also comes with 95 new modules. The most significant changes here are two new sub-modules: the “extras” module will become a separate package, while the “core” module will be absorbed back into the main Ansible GitHub repository to make it easier for contributors to make a single pull request.
“We’re trying to make it easier for people to contribute code back to us,” said Cammarata.
Beyond Ansible 2.0, he said the company’s next big focus is on “taking the beta sticker” off of Ansible’s Windows support. After the 2.0 release in July, the Ansible team plans to go back through the Windows code and audit open-source contributions to bolster alpha Windows compatibility.
A look at Ansible Tower 2.2
AnsibleFest NYC also brought a preview of the latest release of Ansible Tower, Ansible’s enterprise product that has a UI, dashboard and REST API for Ansible. Ansible Tower 2.2 has push-button functionality for Ansible deployments with standardized jobs, access and compliance controls, audit trailing, and security permissions.
“Tower 2.2 marks the beginning of a major effort for us to revamp the UI and the overall user experience,” said Gerla. “Tower is still a young product, so our focus is really on usability. We want to make it as simple to use as Ansible.”
Bill Nottingham, Ansible’s director of product, demoing Ansible Tower 2.2
Bill Nottingham, Ansible’s director of products, demonstrated some of the new capabilities in Ansible Tower 2.2. He described Tower as a service and REST API to layer more enterprise features atop Ansible to bring agentless automation and delegation to larger deployments.
The main features and capabilities coming in Ansible Tower 2.2 include:
- System Tracking: Ongoing recording and analysis of the characteristics of the machines under management by Ansible
- Remote Command Execution: Run simple commands and Ansible modules from Tower without writing playbooks
- Inventory support for OpenStack
- An easy backup and restore feature: “Ansible playbooks make it easy to do repeatable deployments, but your data is not always repeatable,” said Nottingham. The backup and restore feature provides that data repeatability
- Ansible Galaxy integration: More robust compatibility with the Ansible Galaxy website, a hub for Ansible content
- A more secure password policy.
More information about all the 2.2 features is available in the Ansible Tower API, and Nottingham said a live public beta will be available in the next few weeks.
