Configuration Management Week: Ansible

Today’s guest post is by Luke Seelenbinder. View the full Configuration Management Week schedule here.

About Luke

Hi! I’m Luke. I write code and design architecture for Spensa Technologies, a precision
agriculture
company in West Lafayette, Indiana.

Intro to Ansible

Overview

ansibleThe 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.

  1. Setup a target machine. If you only want to test, a VM is the way to go. Make
    sure the user ansible has SSH access, preferably with a key-pair.
  2. 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.
  3. 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:

[targets]
192.168.33.10

(Be sure to substitute whatever IP the VM is assigned.)

  1. 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
    sudo: yes
    remote_user: ansible
    hosts: targets
    tasks:
  • name: Set Hostname
    hostname: name=”ansibletest”
  1. 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]`.

  2. If all went well, your VM’s hostname should be ansibletest.

Coolest Features

Batteries Included

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).

Adjustable Wrenches

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.

Parallel Action

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.

Biggest Drawback

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
script.

Further Reading

Configuration Management Week: Ansible

One thought on “Configuration Management Week: Ansible

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s