Review: Ansible orchestration is a veteran Unix admin's dream

Ansible and AnsibleWorks AWX bring simplicity and power to Linux and Unix server automation

Many server automation and orchestration solutions, like Puppet and Chef, rely on a mixture of solution-specific coding, Web UIs, and command-line tools to make the magic happen. Ansible is different. Although a Web UI is available, Ansible plays very well on the Unix admin's home turf: general scripting and the command line.

Ansible is an extremely flexible open source toolkit that makes it very easy for Unix hands to get started with automated configuration management and orchestration. It uses a push method of configuring client systems, so everything stems from a master server. And to the powerful CLI, you can add a commercially licensed Web UI to provide for delegated administration and provisioning.

[ Review: Chef cooks up configuration management | Review: Puppet Enterprise 3.0 pulls more strings | Puppet or Chef: The configuration management dilemma | Subscribe to InfoWorld's Data Center newsletter to stay on top of the latest developments. ]

Installing Ansible

Installing Ansible is quite simple. You can either clone the Git repository and start from there, or you can use package management tools on your *nix of choice to download and install the packages. This will ensure that you have the required packages and Python 2.6 executables, and within a few minutes, you will have an Ansible master server configured.

In general terms, you'll deploy Ansible with a central server and with configured groups of clients to be managed, using hostnames in an Ansible hosts file. The configuration required on the managed hosts is minimal, requiring only a functional Python 2.4 or 2.6 build and configuration of SSH authorized_keys to allow for connections from the Ansible master server to each host.

There are many ways to go about this, as you can configure Ansible to connect to hosts as a certain user or as the user running the commands on the master server. You can go with root as the user, but many will prefer to connect using a normal user account and working with sudo on the target to run commands as root.

As an example, we might have a user named "ansible" on our master server; we would then add an "ansible" user to our managed hosts and give that user passwordless sudo capabilities. Alternatively, we could specify passwords for sudo on the hosts, or we could specify a different username to be utilized when connecting. The ultimate goal is to allow the Ansible control executable to be able to connect to each configured host via SSH and run commands. That's all there is to Ansible master and client configuration.

How Ansible works

Once the basic setup of our master and managed hosts has been done, we can start looking at what Ansible can do. Here's a simple example:

[ansible@ansible1: ~]$ ansible all -m ping -u ansible -sudo
ansiblecentos.iwlabs.net | success >> {
    "changed": false,
    "ping": "pong"}

ansibleubuntu.iwlabs.net | success >> {
    "changed": false,
    "ping": "pong"
}

Here we ran a simple ping command to make sure that our managed hosts are configured and answering. The result is that both targeted hosts are ready and waiting.

InfoWorld Scorecard
Scalability (20.0%)
Value (10.0%)
Performance (10.0%)
Interoperability (20.0%)
Management (20.0%)
Availability (20.0%)
Overall Score (100%)
AnsibleWorks Ansible 1.3 8.0 9.0 9.0 7.0 8.0 9.0 8.2
1 2 3 4 Page 1
Page 1 of 4