Why use Ansible for automation and orchestration

If there were an award for “most improved IT orchestration and configuration management tool,” Red Hat’s Ansible would be a top contender. Since its initial development by Michael DeHaan in 2012, it has grown from a simpler way to automate Linux systems than Puppet, to a widely applicable automation platform with particular strengths in devops and network automation.

Ansible’s developers describe Ansible as a “radically simple IT automation platform that makes your applications and systems easier to deploy. Avoid writing scripts or custom code to deploy and update your applications—automate in a language that approaches plain English, using SSH, with no agents to install on remote systems.”

And it’s true. Ansible makes server automation significantly less complicated than competitors. 

Ansible playbooks

Instead of writing scripts for Ansible, you write YAML playbooks, although some would say that’s becoming a distinction without a difference. The subsets of Ruby now used for scripts in some of the competing products are not much more complex than YAML; there’s just a little bit of syntax to learn, that is if you have a developer’s temperament. Ansible’s counterargument is that everyone in the organization should be able to read scripts and understand what they do. Certainly much of Ansible’s initial popularity stemmed from the simplicity of playbooks, along with adoption in the Fedora Linux distro.

Agentless automation

Instead of installing agents on Ansible clients, you connect to the existing SSH daemon on Unix-like systems (Linux and MacOS), to WinRM (Windows Remote Management) on Windows systems, or to APIs on cloud systems and network devices. Native OpenSSH has become available on Windows, and you can use it from Ansible, but it’s still a beta feature as far as Microsoft is concerned.

On constrained systems without an SSH daemon, you can connect to Paramiko, a Python library for SSH2. Ansible is implemented in Python.

Other configuration management and orchestration systems that use agents on their clients report that agents are faster and more useful than their own agent-less options. Ansible criticizes agents, with some validity, as requiring that you “manage the management” by installing the agents on clients before using them and updating them when versions change. Ansible touts its agent-less architecture as putting less load on the central server, being more secure, and avoiding the CPU and memory load on clients that can be caused by agents.

If you really want to run Ansible nodes in “pull mode,” you can. Unfortunately that requires installing Ansible on the nodes and scheduling Cron jobs (or the equivalent) to download and run playbooks from a Git repository.

Ansible Tower

Ansible Tower (“mission control for Ansible”) enhances Ansible with a visual dashboard, role-based access control, job scheduling, integrated notifications, and graphical inventory management. It also provides a REST API and CLI for programmability as well as for integration with other products. Following Ansible parent Red Hat’s model, Ansible AWX is the upstream open source project for Ansible Tower.

IDG

Ansible modules

Ansible’s capabilities have greatly expanded since its acquisition by Red Hat in 2015. For example, Ansible now ships with over 450 modules, which are small pieces of code for performing specific tasks, and the Ansible Galaxy public repository contains about 1,600 modules.

Of those 1,600 modules, about 360 are for networking, and cover about 33 networking platforms. Network automation is a big deal for Ansible—the company has customers who use another orchestration tool for most purposes, but run Ansible for network automation.

Another improvement has to do with scalability. If you use Ansible Tower, you can cluster your servers for capacity and redundancy, and deploy remote execution nodes for additional local capacity and for access across network zones. The “1,000-node limit” for push mode is a thing of the past.

Ansible and devops

Devops is another big deal for Ansible. Because playbooks are easy to understand even for non-programmers, roles across the organization—developers, operations, QA, and management—can all read and use the same scripts.

In basic open-source Ansible, you manage your node inventory by listing systems in a file. In Ansible Tower, you can also pull your inventory from AWS, Azure, GCP, OpenShift, OpenStack, VMware, Red Hat Satellite, or Red Hat CloudForms, among others. Ansible Tower’s provisioning callbacks allow nodes to request configuration on demand, enabling autoscaling, and Tower’s credential delegation allows developers to provision their own dev and test environments.

You can easily integrate Ansible Tower with Jenkins or another CI/CD tool using the Tower CLI, or integrate Tower with your build tools using the Tower REST API. Ansible doesn’t have its own dedicated CI/CD, but OpenStack includes the Zuul CI/CD system.

Ansible orchestration

One of the use cases that Ansible Tower can handle is a rolling update. The script for that would divide the servers for a particular application into groups, then pull one group at a time out of load balancing, update the nodes in the group, check the status of the updates, put the group back into load balancing, and go on to the next group. Within each step, the scripts run across nodes in parallel, but the steps run sequentially.

If you can’t find the module you need in the 1,600 available in Galaxy, you can extend Ansible with a new module. While the modules that ship with Ansible are written in Python and PowerShell, modules can be in any language, as long as they output JSON.

Ansible and Docker

Ansible Container enables you to build Docker container images and orchestrate them using only Ansible playbooks—the playbooks will generate the necessary Dockerfiles. Ansible integrates with Kubernetes on OpenShift, and playbooks can generate a Kubernetes specification from a template. The docker_service module can orchestrate containers on a single Docker daemon or on Swarm.

Unlike most of its competitors, Ansible has extensive support for serverless architectures. There are modules for AWS CloudFormation, AWS Lambda functions, and the provider-agnostic Serverless Framework. You can even run a playbook in AWS Lambda.

Ansible and Windows

Windows support in Ansible is mostly separate from Linux support. Ansible modules for Windows are usually written in PowerShell rather than Python. While there are over a dozen core modules that have Windows support, there are also over a hundred modules specifically for Windows, covering Windows functionality such as IIS management, event logs, and registry editing. Ansible has customers with all-Windows infrastructure except for a few RHEL servers running Ansible Tower and Ansible.

Ansible installation and setup

Installing an open source Ansible control machine is dead simple as long as you have a Linux or BSD machine with up-to-date Python. You can use system module managers such as Yum or APT, the Python package manager Pip, or install from source.

Ansible Tower installation is only a little bit harder. You need Red Hat Enterprise Linux 7.2 or later 64-bit, CentOS 7.2 or later 64-bit, Ubuntu 14.04 LTS 64-bit, or Ubuntu 16.04 LTS 64-bit. The Yum or APT installation process installs all the dependencies, including Ansible, PostgreSQL, Django, and Nginx. There’s a prerequisite on RHEL to enable the extras repositories for Yum. You can also install Tower from online repositories, and on AWS from an AMI.

—

Cost: Ansible community edition: free. Ansible Engine Standard, $5,000/year up to 100 nodes; Engine Premium, $7,000/year up to 100 nodes. Ansible AWX (open source upstream version of Tower): free. Ansible Tower Self-Support, $5,000/year up to 100 nodes, $10,000/year up to 250 nodes. Ansible Tower Standard, $10,000/year up to 100 nodes, $13,000/year with Ansible Engine. Ansible Tower Premium, $14,000/year up to 100 nodes, $17,500/year with Ansible Engine. Contact Ansible for Ansible Networking and for higher numbers of nodes. 

Platform: Ansible controller machine runs on Linux, BSD, MacOS, or Windows 10 WSL Bash shell, with Python 2 or 3. Nodes run on all of the above plus native Windows. Ansible Tower requires RHEL 7, CentOS 7, Ubuntu 14.04 LTS, or Ubuntu 16.04 LTS.