Ansible - An Introduction to the Swiss Army Knife of Automation

Posted on 12/19/2015 by Brian Carey

Ansible is a systems automation tool that has proven to be very powerful to our day to day work.  It allows us to build more consistent environments as well as manage configurations using a much more structured approach.  No more connecting to 10 web servers in a pool to make a configuration change.  Make the change in the template and deploy it to all 10 of the servers using Ansible.  

I intend on this being the first of what will be a series of posts covering various aspects and examples of how we use Ansible on a daily basis at KISS.  In this introductory post I will cover some of the features and use cases of Ansible as well as the basic installation and configuration required to get running.  All instructions are specific to CentOS 6.x, however, would be similar for all Unix based OS's that are supported.

Features

While by no means a complete list of features, these are a few that we consider most important.

  • Agent-less: Previous tools considered a must for configuration management and automation required an agent to be installed on each client.  Ansible however functions utilizing the same SSH connections we already have in place and requires no footprint on a client system aside from a key that allows the controlling machine to connect without a password.
  • Power out of the box: While there are add-ons available for specific functionality as well as the ability to create your own, for the most part all functionality needed is included out of the box.
  • Templates: Ansible uses the Jinja2 template engine providing one of the most powerful features in our opinion...the ability to define configuration templates that are then used to build configuration files on the fly based on a given host being managed.
  • Cloud support: Most all major cloud vendors are supported both in terms of managing resources via their API as well as dynamic inventory support.  This is very important for large, dynamic environments so as to not have to manually manage the inventory used by Ansible.

Use Cases

  • Server configuration management & automation: This is what we consider the primary use case.  Managing one or two servers by hand isn't a problem, but trying to do so with 50 servers is much more tedious not to mention error prone.  By defining the various configurations as templates and deploying them based on the role(s) of a given host, configuration changes take a fraction of the time and are made consistently across your entire environment.
  • Cloud automation: Ansible allows us to automate deployment of services in the cloud and then turn around and use the configurations already being managed to configure these services automatically saving much time and again resulting in a consistent environment.
  • Code deployment:  In certain cases, Ansible also is a good choice for code deployment automation.  We still use Capistrano in some cases but others lend themselves more to Ansible.

Installation

On CentOS 6, installation is as simple as the following.  Note that since Ansible is part of the EPEL repository we pull that in first.

yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm
yum install ansible

Start with the proper layout

At this point you are ready to start your Ansible project.  This can be done in various ways, however, starting out correctly can make a big difference in ensuring your project easily grows with you.  We recommend the same format covered in the Best Practices documentation provided by Ansible:

inventory/   - Here we'll define one or more inventory files or install a  dynamic cloud inventory script
  production  - Production hosts & groups
  development - Development hosts & groups
  ec2.py - The dynamic inventory script for AWS
  ec2.ini - The configuration file for ec2.py
group_vars/  - Here we'll assign variables to specific groups of hosts
  group1
  group2
roles/
    common/  - This will be the location of tasks and configuration shared by all hosts
        tasks/ 
        handlers/
        templates/
        files/
    role1/  - This will be the location of tasks and configuration specific to role1
        tasks/ 
        handlers/
        templates/
        files/
site.yml - This is the primary playbook.
playbook1.yml - Playbook specific to a given set of tasks

Whats next?

In this introductory post we covered some of the features and use cases of Ansible as well as how to install it and define a project directory following best practices.  Stay tuned for the upcoming posts in this series which will cover Ansible Inventory (Both static and dynamic), common configuration management examples, common build examples, and other advanced topics.