Let's talk about Ansible - Why and how to use it

Why

The server systems are the underlying foundation of our applications and thus, like our applications, they should be version controlled, tested and automated. As such we looked for a configuration management tool that could solve our automation needs. We started looking at products like Puppet and Chef. Puppet’s complexity was overwhelming and Chef’s architecture didn’t quite meet our use case. We needed to find something that worked well, didn’t take a lot of time to learn, could easily be version controlled, and didn’t require additional infrastructure. After some research, we came across Ansible.

Configuration management tools are not new, they have been around for some time, but their complexity always made their adoption a difficult process. This is where Ansible truly shines, it has lowered the learning curve enough so that it is easier to use Ansible than to do manual stuff or shell scripting, even for a local install and configuration.

We now use Ansible for any task or project that requires repeatable processes and a consistent environment, such as provisioning IoT devices and server infrastructure, installation and configuration of applications, and application deployment.

What

Ansible uses no agents and no additional custom security infrastructure. Essentially, the desired state of the entire IT infrastructure can be described in the form of Ansible Playbooks, which are files written in a very simple language, YAML.

By default, Ansible represents what nodes it manages using a very simple file which organizes the managed machines in custom groups. Rather than just managing one node or system at a time, Ansible will configure each node to the described state.

Ansible works by connecting to the nodes over SSH and pushing out small programs, called “Ansible Modules”, to them. Ansible then executes and removes them when finished. Because these modules are simple Python scripts, and Ansible is agent-less, the target hosts only require an SSH connection and Python installed. Besides simplicity, which is another advantage of using Ansible vs Chef or Puppet, there are no servers, daemons, or databases required - all that is needed is to install Ansible on the host, Python on the targets, and have SSH access.

How

Now that we know what Ansible is and why we need it, let’s dive in into how it works. As stated, Ansible hosts are defined in a file, organised by groups and Playbooks can be applied to individual groups. The addresses of these hosts can be described using ranges and other operations. Finally, each host can have custom variables, such as SSH and sudo passwords.

[webservers]
webserver.whitesmith.co
application.whitesmith.co

[devices]
192.168.0.[01:25] PASSWORD="****"
172.17.0.2 COMPANY="Whitesmith"

Playbooks are the core of Ansible and the basis for a really simple configuration management and multi-machine deployment system. Playbooks can declare configurations, but they can also orchestrate steps of any manually ordered process, even as different steps must bounce back and forth between sets of machines in particular orders. They can launch tasks synchronously or asynchronously.

---
- hosts: webservers
  tasks:
  - name: Ensure packages are installed
    apt: name= update_cache=yes state=latest
    with_items:
      - git
      - nginx

  - name: Ensure the nginx configuration file is set
    copy: src=/app/config/nginx.conf dest=/etc/nginx/nginx.conf

  - name: create /var/www/ directory
    file: dest=/var/www/ state=directory owner=www-data group=www-data mode=0700

  - name: Clone git repository
    git: dest=/var/www/app repo=https://github.com/whitesmith/app.git update=no

  - name: Ensure nginx is running
    service: name=nginx state=started

Playbooks are expressed in YAML format which makes them very simple and readable. Each playbook is composed of one or more plays in a list. The goal of a play is to map a group of hosts to some well-defined roles, represented by things Ansible calls tasks. At a basic level, a task is nothing more than a call to an Ansible module.

By composing a playbook with multiple plays, it is possible to orchestrate multi-machine deployments, running certain steps on all machines in the web servers group, then certain steps on the database server group, then more commands back on the web servers group, etc. Playbooks have the interesting characteristic of being idempotent, they ensure the system is in the desired state, and only run tasks if needed.

Conclusion

Neglecting the documentation, automation and control of the server systems can lead to serious issues when things go wrong, and recovery time can make or break a product. Besides speeding up the setup and recovery process, Ansible presents many other advantages. From lowering the costs of infrastructure management to increasing replication speed for scalability.

Until recently, the learning curve of such tools greatly diminished their appeal. Ansible, on the other hand, is so simple that using it is even easier than doing a manual install or a shell script.

Ansible also provides more advanced management flows, such as roles, which are a further level of abstraction that can be useful for organizing playbooks. For further reading we recommend the official documentation, it is very complete and accessible.