When popular IT automation framework Ansible was acquired by Red Hat, the question had to be asked: What's going to change? Would Ansible be geared to support Red Hat's products?
It didn't seem that way with Ansible 2.0 when it debuted back in January with a host of generic improvements to its scripting handling. Version 2.1, though, brings broader support for containers, Microsoft Windows, and Microsoft Azure, technologies Red Hat has either invested itself in heavily or partnered with. But the changes remain high-level, not coupled to anything Red Hat does.
The Azure-specific additions include support for Azure Resource Manager, which uses templates and RBACs to consistently and repeatably deploy resources for applications. It's the kind of work Ansible itself might do, so having Ansible leverage Azure's methods makes plenty of sense.
With Windows generally, Ansible can now manage other parts of the OS, such as Windows file sharing and the firewall, and it can use NTLM directly, instead of Kerberos, to manage machines joined to a domain. A new action, win_reboot, makes it easier to script workflows that require restarting a system, which is hard to avoid if you're performing multiple software or kernel-driver installations.
Ansible 2.1 also overhauls container support -- another field where Red Hat has been heavily involved. The existing Docker modules have been rewritten, and a new docker_service module allows Docker Compose to be embedded into Ansible playbooks. This means Ansible now has more control over the deployment infrastructrure used to run containers, as well as the ability to interface closely with how containers are built and managed.
A third major addition to Ansible 2.1 is networking automation for using Ansible to control networking platforms like Cisco, Juniper, Cumulus, Arista, and OpenSwitch.
So far, Red Hat has provided Ansible with features that are at least a partial reflection of Red Hat's own interests, but on a high level -- such as support for containers generally, rather than OpenShift or RHEL specifically. That's a good direction to take, as it does justice to existing Ansible users and their use cases, rather than putting the brunt of new and future Ansible features into supporting Red Hat infrastructure. Let's hope it stays that way.