Review: Ansible shows the beef

Ansible 2 eases configuration management, while boosting playbooks, modules, and Windows support

At a Glance

At a time when the configuration management market was dominated by Puppet and Chef, an open source project called Ansible emerged with a simpler approach to automating IT environments. An agentless system that was easy to learn, Ansible quickly earned a name for itself. Before long, the developers behind the project formed a company to offer commercial support. That company -- first known as AnsibleWorks, then Ansible -- was acquired by open source leader Red Hat in October 2015.

Originally built as an execution engine, Ansible began by allowing Linux and Unix admins to remotely run arbitrary commands on one or more machines, but it has since evolved into a complete solution for automating and managing your entire IT infrastructure. With version 2.0, Ansible added more than 200 modules to improve and expand support for Amazon Web Services, CloudStack, OpenStack, VMware, Windows, and network infrastructure, among other targets. Version 2.1 improves Docker support, adds a bunch of modules for Microsoft Azure, and removes the beta label from Windows support.

Ansible 2.x also benefits from a major rewrite of the code that parses playbooks. Perhaps the most important new and useful feature here is task blocks, which lets you group related tasks and bring exception handling (think try-catch-finally) to playbooks with ease. But other improvements, such as dynamic include statements (think loops through inventory variables) and better error-checking, help increase the power and flexibility of Ansible playbooks, while preserving their simplicity and ease of use.

Ansible architecture

Instead of an agent that runs on your systems, Ansible pushes modules (scripts) to the remote systems and executes them. By default, modules are pushed to Linux machines via Secure Shell (SSH) and to Windows machines via Windows Remote Management (WinRM). Systems are configured with “playbooks,” which are simple YAML files, and each playbook contains one or more tasks (calls to a module) that will set the system to its desired state. Playbooks are written to be idempotent, which means they can be run repeatedly and will modify the system only when a change needs to be applied. Playbooks are applied to systems based on inventory; the inventory list can be stored in a simple text file or pulled from a dynamic source like a database or a web service.

Now that we've covered playbooks, let's take a quick look at a sample inventory file:

To continue reading this article register now

How to choose a low-code development platform