Review: Ansible shows the beef

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:

192.168.3.1

[webservers] doc.ansible.com blog.ansible.com

[dbservers] db0.ansible.com db1.ansible.com

You can use Ansible to manage Windows as well as Unix and Linux systems, but the Ansible control node must run on Unix or Linux. Ansible can be installed on Linux systems using Yum or Apt and on OS X using Pip. The modules, which are written in Python, are divided into two categories: core and extras. Both the core and extras modules ship with Ansible, but the core modules are maintained by the core Ansible team while the extras modules are maintained mostly by the community.

Ansible Tower

In the initial days of Ansible, there was no proper graphical user interface (GUI) for users, many of whom complained the GUI tool that was available showed different results than the command-line interface (CLI). To complicate matters, the GUI tool was capable of performing only a few tasks. Taking this feedback into consideration, Ansible developed Ansible Tower: a web-based user interface that delivers a graphical representation of everything happening within the environment. With Ansible Tower, real-time monitoring of nodes became easy and reliable.

Today, Ansible Tower shows the same results as the CLI except they are in a web UI. Tower also provides separation of duties; for example, a developer can run a play on a development system with a simple click of a button and system administrators can deploy an entire stack as quickly. In a large environment, Ansible is run on a “master” server that can access all of the servers within the infrastructure, and system admins shell into the master server and run their playbooks against the remote systems. Tower basically “webifies” that process while also providing a layer of governance and audit support.

Ansible Tower comes with a useful dashboard that provides a quick summary of the entire infrastructure, and the fully documented REST API enables you to integrate Tower into your existing automation processes. You can easily create teams and users and assign roles to provide role-based access control, and job scheduling can be done with little effort. The portal view simplifies operations for new users and lets you work directly with your managed nodes on Amazon EC2, Rackspace, Azure, and other clouds that Ansible integrates with. At the same time, tasks such as creating playbooks are efficiently done in the CLI.

Playbooks vs. programming

While tools such as Puppet and Chef are popular in the market, Ansible developers considered two important aspects when creating their solution. First, there isn’t a need to learn a programming language. Ansible playbooks are simple YAML files, so no programming knowledge is required to create them. However, you’ll need to understand what each module is doing and use them appropriately. In contrast, Puppet and Chef use Ruby, so they require some programming knowledge and can be harder to learn.

Second, whereas Puppet and Chef rely on agents running on managed nodes, Ansible uses the tried-and-tested SSH and WinRM network protocols to deploy modules to nodes, eliminating agent overhead.

Because Ansible uses simple YAML files, it may be easier for administrators to create and work with Ansible modules than the Ruby-based modules that comprise Chef and Puppet. As it turns out, Ansible modules are actually Python modules written in an Ansible-friendly manner. Because Ansible modules are “idempotent,” they can be executed on a node any number of times and will always produce the same result (that is, the desired state of the machine the module describes).

Ansible is designed around a push-based system — where the control machine pushes a set of instructions or tasks to the managed nodes — but also supports pull. In either case, an agent is not needed. Ansible pull amounts to fetching playbooks on a schedule — using Cron, for instance. However, pull mode requires installing Ansible on the remote system, which means having one more package to manage on the node.

In contrast, Puppet and Chef have a pull-based configuration management setup, which means all nodes contact the control system on a regular interval to receive instructions or tasks. When something goes wrong, the node informs the controller and updates itself when it contacts the master.

Let’s take a look at an example. This playbook sets up a simple web server listening on port 80:

- hosts: webservers   become: yes   vars:    - http_port: 80   tasks:    - name: Verify web server dependencies are installed      yum: name = {{ item }} state=present      with_items:       - httpd      tags:       - application    - name: Open http port in the firewall for RHEL 6      lineinfile:       dest: /etc/sysconfig/iptables       state: present       line: "-A INPUT -p udp -m state --state NEW -m tcp --dport {{ http_port }} -j ACCEPT"       insertafter: '^:OUTPUT ACCEPT'       backup: yes      when: ansible_distribution_major_version == "6"      tags:       - base       - firewall    - name: Open the http port in the firewall for RHEL 7      firewalld: port = {{ http_port }}/tcp state=enabled immediate=true permanent=true      when: ansible_distribution_major_version == "7"      tags:       - base       - firewall

The process of executing Ansible playbooks is slower than executing remote tasks with agent-based tools like Puppet and Chef because Ansible has to make calls out to the clients and work more with the network stack. However, even if you’ve never seen a playbook before, it’s not difficult to grasp what one is doing. Playbooks are not only easy to set up and execute, but they’re easy to understand when you come back to them weeks or months later.

An Ansible overview

Ansible brings many capabilities to a growing number of management targets. Let’s take a look at some of the core components.

Provisioning. Ansible allows you to quickly provision machines within your infrastructure — from servers and firewalls and networks to virtual infrastructure and public clouds. By provisioning the operating system with a kick-start script, then relying on playbooks for further configuration, you can automate infrastructure provisioning and manage those configurations in real time using the Ansible Tower.

Configuration management. With Ansible, configuration management becomes straightforward. Using simple YAML files, you can create Ansible playbooks to manage the infrastructure. Hundreds of modules in the core distribution can be used to build automation, and as an agentless system, Ansible is easy to set up and manage. It is simple, consistent, and secure — relying on a simple password and/or an authentication protocol such as an SSH key or Kerberos. Whether you use an SSH key in a cloud environment or Kerberos within an enterprise environment, you would need SSH to connect and a privileged account to run your plays.

App deployment. Ansible enables businesses to quickly deploy multitier applications from a common framework. All you need to do is describe the desired state of the system in the playbook, and Ansible brings that state to the node — regardless of the state the system is currently in.

You can easily automate repeatable tasks like installations, upgrades, and other app-related activities using playbooks. You can even deploy and manage a multitier app as a single unit. For example, you could configure a load balancer, a web tier, an app tier, and a database tier — along with all of their interdependencies — in a single playbook. In other words, you can have a playbook that contains all of the Ansible roles (remote systems) in your stack. Each system would be classified in an Ansible role (database, web server, load balancer) and have specific playbooks associated with them. For example, the following playbook could be used to provision an entire application environment.

# Common configuration - hosts: all   become: yes   roles:   - linux_common

# Set up database servers - hosts: dbservers   become: yes   roles:   - db

# Set up web servers - hosts: webservers   become: yes   roles:   - webserver

# Set up load balancers - hosts: loadbalancers   become: yes   roles:   - haproxy

Continuous delivery. Ansible facilitates continuous delivery and allows you to slice thousands of servers into manageable groups, allowing painless updates to hundreds of machines at a time — all you need is a playbook. To keep it straight, source control is recommended for managing playbooks to ensure an audit trail of the changes. With multitier and multistep orchestration, you gain fine-grained control over operations — regardless of monitoring systems, load balancers, or web services. Ansible also has a module for managing plugins for the Jenkins continuous integration server.

Security and compliance. Because Ansible uses SSH to connect to nodes, security comes down to the SSH protocol and client configuration. You can connect a single host with multiple nonroot users, and because Ansible supports sudo and other forms of privilege escalation, you can run modules as root. To provide additional security, Ansible has partnered with MindPoint Group so that Ansible roles comply with DISA STIG (the Defense Information Systems Agency’s Security Technical Implementation Guide, a government standard for secure systems). Tools such as STIGMA and OpenSCAP are available for compliance — allowing you to verify the security configuration and track deviations.

Orchestration. Ansible helps you combine and coordinate different processes, environments, and methodologies by creating a common framework and language. You can easily weave together interlocking services such as network, storage, computing, and identity, or you can describe your multitier production application in a playbook. Ansible will ensure that the right configurations are applied to the right resources in the right order. As it turns out, OpenStack giants like HPE, Cisco, and IBM all use Ansible to orchestrate their OpenStack deployments. This is due in part to the large number of modules that allow Ansible to talk to OpenStack services.

Public cloud deployments. Drawing on 75 modules supporting Amazon Web Services, Ansible allows you to dynamically provision workloads to the AWS cloud, manage and secure those cloud deployments, and easily migrate apps to AWS. You can leverage devops in the cloud to harness the full potential of AWS, and once your AWS environment is described in Ansible, you can scale out your deployment to hundreds or even thousands of machines using the same modules and playbooks.

AWS has the lion’s share of Ansible’s cloud modules, but you’ll also find good support for OpenStack, CloudStack, and Rackspace, as well as rapidly improving support for Azure, with 18 modules and counting.

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.