Does simplicity give Ansible an edge over similar tools?

What took me three blog posts for Chef, I can describe in one for Ansible. Like Chef and Puppet, Ansible is a configuration management tool that helps us with automating repetitive tasks like deploying packages or applications to groups of servers. Ansible was released in 2012 and is relatively new compared to Puppet, released in 2006, and Chef, released in 2009.

A few years makes a big difference in technology nowadays. For a frame of reference, consider how many new tools have come out recently. In this week’s New York Cloud Expo, a speaker from CoreOS described 18 new and potentially very useful tools that have become available in the past two years. With so many cloud tools available, which ones will gain traction? This post discusses Ansible, which may gain in popularity because of its simplicity.

About Ansible
I first became interested in Ansible after meeting with a research university that had questions about using Ansible’s dynamic inventory feature with different OpenStack clouds. Dynamic inventory allows one to programmatically inventory all the servers in the cloud using APIs like OpenStack. Last year, Ansible also started gaining traction among OpenStack vendors, with a few choosing to migrate their installation processes to Ansible because of its simplicity and easier learning curve.

Unlike Chef, which requires setting up a server and a workstation, Ansible can be administered on any instance in the cloud. Whereas Chef requires agents on each client, Ansible only requires SSH to work. Ansible has just a few prerequisites, such as SSH and a working installation of Python 2.5+. One can automate repetitive tasks by creating Ansible “playbooks”. Playbooks are similar to Chef “recipes”. One difference is that playbooks are written in a very simple language called YAML. The underlying language is Python and one might want to program Python to create a module or a dynamic inventory script.

Getting Started with Ansible – In half of a blog post
The fastest way to learn Ansible might be to try it. So here are instructions on how to install Ansible, use the CLI (command line interface), and create a playbook. Note that these instructions are for Enterprise Linux.

Install the Ansible CLI on a (virtual) server

sudo yum install ansible

That’s it! The Ansible CLI is installed.

Getting started with the CLI

In this example, we will manually setup an Ansible inventory instead of using dynamic inventory. Edit /etc/ansible/hosts so it looks something like this.

[myservers]
10.130.52.213     ansible_ssh_user=opc
10.130.52.210     ansible_ssh_user=opc

In this example, “opc” is the username used to SSH to the servers, which have IP addresses 10.130.52.213 and 10.130.52.210.

To avoid re-typing passwords, setup an SSH agent as follows:

ssh-agent bash
ssh-add ~/.ssh/.pem

Now ping the nodes

ansible all -m ping

Ansible ships with a module library that allows many commands to be executed from the CLI. Follow the hyperlinks to learn more.

Create a Playbook

Like in the Chef example from my previous posts, let’s automate the deployment of an nginx web server. Create a file, e.g. nginx.yml, and edit is as described below

vi nginx.yml
- hosts: webservers
  remote_user: opc
  sudo: yes
  
  tasks:
  - name: Install Nginx
    yum: pkg=nginx state=installed update_cache=true
    environment: proxy_env
    notify:
      - start nginx

  handlers:
  - name: start nginx
    service: name=nginx state=started

Note – If you require a proxy to get packages and/or need to setup the Extra Packages for Enterprise Linux (EPEL) repository in an instance before installing Nginx, see the playbook example in Appendix A.

Run the Playbook

  ansible-playbook -s nginx.yml

Nginx is now setup on hosts listed under [myservers] in the /etc/ansible/host inventory file.

Compare these steps to the ones in my Chef blog posts. If you were just getting started with configuration management, which tool would you choose?

Conclusions and Commentary on Simplicity vs. Complexity

Many of us work in environments where engineering managers are often impressed by complexity, things like graduate degrees. In a world where there are so many new innovations, it is easy to end up with complexity. The big challenge now is simplicity. Managers must recognize the value of simplicity. Tools that are simple and have a short learning curve will have an advantage. As Steve Jobs once said, “Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple.” Simplicity gives tools like Ansible an advantage and will be a key enabler for their adoption.

Appendix A. Example Playbook that sets up a Proxy and the EPEL Repo

Here’s a modified version of the above playbook that accounts for a proxy and installs an EPEL repo.

hosts: webservers
  vars:
    http_proxy: 
  remote_user: opc
  sudo: yes
  
  tasks:
  - name: get epel-repo rpm RHEL6
    get_url: url='http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm' dest=/tmp/epel-release.rpm
    environment: proxy_env
  - name: install epel-repo rpm
    yum: pkg=/tmp/epel-release.rpm state=installed
    environment: proxy_env
  - name: replace https with http in epel.repo
    replace: dest=/etc/yum.repos.d/epel.repo regexp='https' replace='http' back up=yes
  - name: Install Nginx
    yum: pkg=nginx state=installed update_cache=true
    environment: proxy_env
    notify:
      - start nginx

  handlers:
  - name: start nginx
    service: name=nginx state=started

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