Today’s guest post is by Luke Seelenbinder. View the full Configuration Management Week schedule here.
Intro to Ansible
The Ansible Team developed Ansible to meet five design principles: 1) simply clear, 2) simply fast, 3) simply powerful, 4) simply efficient, 5) simply secure.
Those five principles were a result of a common frustration. If a developer writes a deployment script, moves on to other projects, and then returns to it in six months to add a new deployment directive, the complexity of many tools easily make the task impossible. Michael DeHaan wanted to avoid this. (Paraphrases taken from http://www.ansible.com/about.)
Ansible is designed to address the problem of
deployment without the need of complex management tools, servers, or daemons.
It’s written in Python and manages every interaction with a vanilla SSH connection. Since Python can be found on nearly every platform, it makes Ansible ideal for light-weight systems, both as deployment and target machines.
Getting Started with Ansible
Ansible boasts an incredibly simple stack: a local script run on your deployment
machine and SSH. Getting started requires a target machine (any VM or VPS will
do) and installing Ansible on your local machine.
- Setup a target machine. If you only want to test, a VM is the way to go. Make
sure the user
ansiblehas SSH access, preferably with a key-pair.
- Create an Ansible project directory. This will hold your Ansible
configuration and any supporting files. The directory structure will
eventually look something like the official suggestions, but for now an empty directory will do.
- Create an inventory file called
hosts. Eventually, you will follow the
instructions in http://docs.ansible.com/ansible/intro_inventory.html#hosts-and-groups, but something like this will do:
(Be sure to substitute whatever IP the VM is assigned.)
- Create a playbook file called
ansible_test.yml. Playbooks are the meat of
Ansible and are composed of tasks, roles, or groups of roles. Let’s make
a playbook that sets the hostname of the target machine:
- name: Setup an Ansible Test Environment
- name: Set Hostname
- Run the playbook via
ansible-playbook -i hosts ansible_test.yml. You will
probably need to define the Ansible key via a command line argument:
--private-key=[path to key]`.
If all went well, your VM’s hostname should be
Ansible’s lack of a required daemon on either the target or deployment machine
makes it very easy to implement. This allows a machine to be completely setup
with Ansible, without any need of other tools or setup scripts. Even though it
requires no additional modules, Ansible ships with tasks to support almost every
standard server software (e.g., apt, postgres, yum).
Ansible is built on an extensive variable system. This allows variables to be
defined at the global, group (of hosts), role, task, and a few other levels. By
using various override mechanisms, a generic system of tasks can be almost
infinitely customized to match a specific use case. In my case, I use two
playbooks to deploy and provision machines for two similar apps. One of the
playbooks depends on much fewer libraries, so each of the machines has custom
variables defining their respective libraries, and the actual task of installing
the libraries is common to both playbooks.
Perhaps the killer feature in Ansible, is the ability to simultaneously deploy
across multiple platforms, and by using the power of variables, with customized
nuances. It’s possible to deploy dozens of machines using the same playbook, and
Ansible will handle all the connections, commands, and details of keeping the
process in sync.
Ansible is powerful when it comes to deploying, but the one significant drawback
is what happens when it fails. Inevitability the day will come when your script
fails. While Ansible provides tools to restart a playbook at an arbitrary task,
it does not provide the ability to roll back any changes. So, unfortunately, to
recover from such a failure can require as much work as making the original