Back in October, Red Hat acquired AnsibleWorks, making it the first major software company to buy out one of the four burgeoning players in the provisioning market. Today, Ansible released the first fruits of that acquisition in Ansible 2.0.

Chief among the changes in 2.0, said James Cammarata, head of the Ansible open-source project, was a good going over of the codebase. “Ansible had grown so fast and large over time that effort some technical debt had accumulated,” he said. “We took time and to take care of the parts of our code that were starting to get difficult to add features to.”

As a result, major changes were also possible with this release. Cammarata said that Ansible 2.0 introduces Blocks, a new section for developers’ Playbooks. While Playbooks list out the procedures and steps necessary to install everything desired on a target machine, they were previously unable to handle exceptions gracefully.

Now, however, using Blocks, developers can write instructions that only trigger when an installation fails. Thus, when an exception is thrown, an Ansible Playbook can now include a backup plan.

The other major change to Playbooks is that they are no longer pre-processed. This enables some new use cases and makes life easier for developers, as they can now reuse code more efficiently. This is enabled through the increased amount of execution strategies.

“The way Ansible has worked, if you have 100 hosts and 10 tasks, as you execute the first task in the list, it would wait for all 100 hosts in the list to execute before moving onto the second task,” said Cammarata. “Now, with additional execution strategies, each host will run through its task list as quickly as possible, without waiting for the others to finish that task first. If you’re adding one new host to your environment, you don’t have to wait for all the other hosts.”

This also means that Playbooks can now include operations that require a knowledge of the clusters’ hardware inventory. Previously, it was not possible to perform tasks that were dependent upon the state of the cluster being installed.

The future
The Ansible project is now focusing on a few of its road-map items for the next release. The most forthcoming release should elevate Microsoft Windows to a first-class citizen. After that, the team plans to work on its VMware integrations.

Docker’s on the road map as well, and it should get some attention in future releases. Greg DeKoenigsberg, director of community for Ansible at Red Hat, said, “We’ve got a lot of users who use Ansible as the mechanism to deploy Docker containers. Some people use Ansible to build their containers, some use it to deploy their containers. They do this because it’s a good way to deploy across infrastructure.

“As you move to microservices, the complexity moves from within the virtual machine to the relationships between containers. We have found the Ansible community does a lot of that. It puts our Docker modules to a lot of use, so we’ve got a lot of demand for bringing that stuff up to code, so to speak.”

Those modules are growing fast, too. As of the Ansible 2.0 release, there are more than 150 extension modules that add capabilities to Ansible. The Ansible team said there are another 100 waiting in the wings; this is why the they will be reworking its module review process to break the logjam between submitting a module and having it available for redistribution to other users via Ansible’s official channels.

Finally, networking should see some enhancements in future releases. According to DeKoenigsberg, “Network administrators have a pretty poor set of tools at their disposal, especially if they’re responsible for a wide variety of hardware. A lot of people in the networking space started picking up Ansible fairly early on because just about every switch has SSH on it. Even if it doesn’t have Python, you can still log in and run scripts.”

That means networking hardware can be provisioned in the same way as servers. “You can put together repeatable playbooks in a way that describes what you’re doing in the network on a repeatable basis,” said DeKoenigsberg. “Some folks in the Ansible community have worked on an Ansible-ish API to talk to network devices. We hired someone to work on the networking problem full time. Soon after 2.0 comes out, we’ll be talking about network functionality, what modules are going to exist there, and how we think that can be a game changer for a lot of folks in that space who haven’t had the chance to create DevOps-y processes in the networking world.”