Review: Ansible shows the beef

Docker. Ansible offers modules for building and running Docker containers, orchestrating containers across a Swarm cluster, and managing Docker images. There are advantages to building Docker images from Ansible playbooks instead of Dockerfiles. When you build an image from a Dockerfile, the application or environment can only be deployed in a  Docker container. But when you build an image using Ansible playbooks, the environments can easily be replicated on any infrastructure -- bare metal, cloud instance, virtual machine, or Vagrant.

Windows. Ansible has supported Windows nodes since version 1.7, providing the same agentless, simple management of Windows infrastructure as it originally brought to Linux. Just as Ansible works like Linux when managing Linux machines, it works like Windows when managing Windows machines, achieved through Windows PowerShell Remoting. This means you can write your own modules in Windows PowerShell to extend the functionality of Ansible. However, you'll need to make sure you're running PowerShell 3.0 or higher and Windows Server 2008 at a minimum. If you need them, Ansible offers modules for VMware as well.

Evaluating Ansible

Capability. I’ve noted that Ansible initiates connections using SSH or WinRM. However, Ansible can also use Paramiko, which is an SSH2 implementation that offers an accelerated mode for faster communication while working within large environments. Still, it’s important to note that the average runtime of a playbook is entirely dependent on the module. For example, if you have a module that sets up to a large partition, it could take a few minutes. However, the second time the playbook is run, it would take Ansible only a second to check if the partition had been created. The play would then return an “OK” and proceed to the next task.

Because Ansible supports orchestration, a playbook can be split into smaller groups so that each group matches a host group. Each group is then executed in chronological order. Because you are able to run tasks over a window of machines, you can make sure a particular service is always available. When you have a lengthy list of tasks in a playbook, however, it takes a significant amount of time to execute them, as Ansible operates remotely over SSH. A simple workaround is to break up the tasks into multiple playbooks or eliminate unnecessary tasks to quicken the process.

Unlike Puppet, Ansible is not stateful. This means the system does not keep track of dependencies. Sequential tasks are run in chronological order, and the execution terminates whenever it encounters an error. Thus, troubleshooting is easier because you know exactly where the playbook stopped. However, you need to check whether the machine reached its desired state.

Thanks to a number of new features introduced in Ansible 2.0, it's much easier to handle errors. Task blocks not only enable explicit exception handling, but the last block in a playbook is now guaranteed to execute whether errors were encountered or not. Plus, a new “any errors fatal” option allows you to ensure “all or nothing” upgrades. That is, if one host in a group throws an error, then all hosts in the group will be rolled back to the original state. You don’t end up with hosts running different configurations.

Ansible’s push paradigm has advantages beyond simplicity. It is especially useful when you have to roll out a critical security policy, for example. With Ansible, when a critical security update fails, it immediately informs the control machine, which means that mitigation steps can be immediately applied. With pull-based CM tools like Puppet and Chef, you have to wait until the agent contacts the master for orders.

With Ansible push, it's similarly easy to execute a limited set of instructions on a small set of nodes, which is useful when you want to run a quick test before applying a configuration to the entire network. Even better, Ansible lets you tie these steps together in a workflow: If the first operation is successful, the system moves on to update the next set of nodes. For example, if you want to update a particular web server after successfully doing so on the database server, you can group the servers together based on policies and dependencies, and Ansible will push tasks according to this workflow.

In short, by combining a push approach with orchestration capabilities, Ansible lets you quickly identify errors and stop the execution to troubleshoot and resolve those errors. With other CM tools, the entire environment would suffer due to the outage until the issue was identified and fixed.

Scalability. Push-based CM tools typically deliver the best performance when there are fewer than 1,000 nodes in the environment. However, within a large enterprise, the push-based method can limit the scalability of the system due to all connections to clients initiating from a single source. Although Ansible was designed for push, it also offers a pull-based mode to accommodate large networks.

Ansible pull is a script that grabs configurations from a Git repo and executes them locally. Pull removes the Ansible control machine as a potential bottleneck. On the downside, pull requires Ansible and its dependencies to be installed on the managed nodes. Of course your Git server (or servers) need to be up to the task.

Even with push, Ansible lets you easily organize configuration tasks across groups of nodes and control machines to distribute the load. You can split a playbook into groups of tasks for specific groups of hosts and execute them in a specific order. With Ansible 2.0, you gain a little more flexibility in how playbooks are executed as well. In the past, Ansible had a single, “linear” execution strategy: It would run each task on all hosts before moving on to the next task. With Ansible 2.0, the new “free” execution strategy allows each host to process a list of tasks as quickly as it can, without waiting for other hosts. Ansible 2.0 also paves the way for more execution strategies to be added via plugins.

Initially, Ansible was considered a useful tool for small and medium-sized environments but not ideal for large enterprises because it lacked the advanced features offered by competitors like Chef and Puppet. However, that picture is changing rapidly, as Ansible continues to add features and modules to support larger and more complex environments. Today, Ansible can scale to support tens of thousands of nodes. A good example of a large Ansible deployment is Rackspace, which uses Ansible to manage its OpenStack public cloud.

Operating system and application coverage. Ansible has roots in the Linux/Unix world, and it supports Red Hat, CentOS, Debian, Ubuntu, BSD, and OS X both as control machines and managed nodes (and many other flavors of Linux/Unix). The control machine requires Python 2.6 or 2.7, as well as managed nodes Python 2.4 or later.

Starting with version 1.7, Ansible began supporting Windows nodes, and with Ansible 2.1, Windows support exits beta status. Windows admins now have 40-odd new and improved Windows-related modules to draw on. To connect with Windows machines, Ansible uses native PowerShell Remoting instead of SSH, but you need a Linux control machine to manage Windows hosts. Further, while support for Windows itself is getting stronger, Ansible doesn’t offer much support for various Microsoft products. To review the current list of modules, visit the Windows module link on the Ansible website.

Ansible is ahead of other CM tools when it comes to integration with cloud APIs. Ansible cloud support includes a long list of modules stretching from KVM, VMware, XenServer, and Docker to Apache CloudStack, Google Cloud, Microsoft Azure, and Rackspace, with particularly strong support for AWS and OpenStack. Unlike Puppet, you won’t need a third-party tool for AWS integration, but you'll need to have Python's boto module installed on your control machine. 

Ansible can also be used to manage networking, storage, analytics, and database/big data environments such as Hadoop, Vertica, MongoDB, Redis, Riak, and Aerospike, not to mention MySQL and PostgreSQL.

Ease of use. The most striking feature of Ansible is how easy it is to use. You can quickly set up the infrastructure and manage it with little effort, and the process is straightforward: Install Ansible, establish a few variables you’ll need, and execute the playbooks. A simplified step-by-step guide would look something like this:

1. Install Ansible on a master server with Yum or Apt.
2. Create an inventory of the nodes to be managed with Ansible.
3. Create and run your playbooks to provision and configure the nodes; the master server communicates with the node using SSH or WinRM to perform the tasks.

By following the clear Ansible documentation, users can quickly learn the logic and workflow, and anyone new to Ansible can understand the main concepts within a few hours.

Ansible modules are written in Python, but you don’t need to know Python to use them; you only need to know how to make a YAML file. Thus, it’s quick and easy to start writing playbooks. While you don't need to write your own modules, you certainly can. If you decide to go that route, it’s helpful to know that Ansible modules can be written in any language -- but the data should be returned in the JSON format. For simple tasks like triggering an update or rebooting a machine, you can run Ansible directly from the command line instead of using configuration files.

Because Ansible is agentless, there are no dependencies and tasks are executed sequentially. Because execution stops when Ansible encounters an error, you can quickly troubleshoot problems. And because Ansible playbooks are written in YAML, reading, commenting, and referencing items is straightforward.

Perhaps the most unique aspect of Ansible is its agentless methodology. While reducing agent overhead, an agentless system also allows easy setup and management of your environment. At the same time, with the use of the SSH layer for transport, Ansible becomes a secure solution. It’s recommended that you have an inventory file containing a list of machines, hosts groups, and possibly the attributes of each group or user; multiple inventory files can be maintained as well. The code is clean and invariably straightforward, which allows for easy playbook navigation and maintenance.

Reporting. Evolving from a simple command-line tool in its initial release, Ansible has come a long way. The first GUI and REST endpoint -- formerly called AWX -- allowed users to efficiently manage the infrastructure from a central server. The next-generation GUI, called Ansible Tower, offers a significantly improved user interface with a team-based workflow option. With Ansible Tower, you can get a NOC-style display of the entire infrastructure and customize the view to show particular job and time ranges. The features and benefits of Ansible Tower include the following:

• A heads-up display of the processes running in the entire environment
• Detailed information on specific jobs and time ranges
• Real-time job status updates
• Centralized logging and auditing of all playbook runs
• Role-based access control, including read-only auditor role
• Easy tracking of entire inventory
• Easy delegation of automated job runs to users across the organization
• Remote command execution
• Role-based access to processes
• Scheduling of playbook runs
• Ability to override job configuration at runtime
• Comprehensive REST API and CLI tool

Community. Not only is Ansible easy to use, it comes with solid documentation. Ansible has a growing community that is very supportive, and thanks to its best practices documentation, it's quick and easy to get started. Ansible lacks the mature and robust communities you'll find at Puppet and Chef, but its community is slowing gaining ground. Currently, Ansible’s module library isn’t as extensive, but community members have provided some lightweight modules. For certain tasks, you might need to edit the modules, and for complicated automation tasks, you would need to write a lot of code. On the plus side, you’ll find that the Ansible folks respond quickly to all chat and email inquiries.

Ansible is a simple yet powerful tool for managing configurations and automating IT infrastructures and environments. To summarize some of its main advantages:

• Ansible is easy to set up and use. It doesn’t require an agent and uses only SSH or WinRM for communication.
• Ansible is written in Python, but there's no need to learn any programming languages. All playbooks use YAML files, which are easy to understand.
• Ansible comes with clear documentation and clean code, so it's easy for both newbies and advanced developers to quickly learn and use the tool.
• Ansible Tower is a web UI dashboard that lets you monitor and manage the entire infrastructure from a central location.
• Ansible combines push with workflow and orchestration capabilities to allow both simple and flexible automation.

While Ansible Tower allows users to visually monitor the infrastructure from a centralized location, you'll need to consider that Ansible is stateless. This means that if you want to maintain large numbers of managed nodes (say, thousands) you should add a pull-based setup as well. Fortunately, Ansible supports this.

Another note: Windows is a work in progress. If your organization runs thousands of Windows nodes or manages heterogeneous networks, you’ll want to take a close look at Windows interoperability. Enterprise support options for Windows need to be checked out too. On the plus side, because Windows playbooks use the same YAML syntax, managing Windows nodes with Ansible is essentially no different from managing Linux nodes.

Ansible has a well-deserved reputation as straightforward and easy to learn. If Ansible users could wish for anything, they would like to see more modules added to the repository and a stronger community. Many modules are available to help kick-start your projects, but Ansible’s repository is nowhere near as rich or complete as those of Puppet and Chef. Reporting features could be improved as well. While Ansible is quickly filling the gaps, it is currently best suited for organizations that require simple and quick automation of smaller IT environments. These organizations could hardly find an easier CM and automation solution to get started with.