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