If you have been writing scripts to install and configure things, then this post is for you. Ansible is at it’s heart an automation tool to ease the burden of deploying, configuring and managing your infrastructure, services and associated config. In this short post I will go through some of the basics that will hopefully get you started on your ansible journey.

Why ansible?

I have been using ansible for a couple of years and prior to that I also spent time with puppet and chef. So why did I like Ansible so much?

Couple of reasons:

• ansible leverages “ssh” to communicate with nodes, and is based on python, so no agents to install! In my book this is a major positive.
• The sheer volume of high quality documentation available.
• The number of modules already written to do things. Do you want to use LVM to configure some disks? Well ansible has a module for it!
• Finally, it is very easy to install and easy to learn.

In fact I was so blown away by it I even restorted to twitter when I first started using it back in 2016! Yes, I am still just a popular on social media :)

Install

For the debian folk out there installing ansible is a breeze.

sudo apt-get update
sudo apt-get install software-properties-common
sudo apt-add-repository ppa:ansible/ansible
sudo apt-get update
sudo apt-get install ansible

Alternatively and probably preferably, you can use “pip” (pip install ansible) to get a more current release.

Once installed on the node which is going to be your administration point, simply distribute your ssh keys to all the nodes that you want to configure/interact with and you can get started. I’m a big fan of ssh-agent and ssh-add, but I am assuming that everyone knows how to use those utilities.

Inventory

An inventory is simply a way of grouping together a collection of IP Addresses and giving them a name. The default location for the inventory is /etc/ansible/hosts

Below is an example, but the default inventory file has some great documentation and examples (ansible documentation is awesome).

[opscenter]
10.1.0.19

[cluster]
10.1.0.183
10.1.0.54
10.1.0.80
10.1.0.117
10.1.0.193
10.1.0.65

[Datacenter-1]
10.1.0.183
10.1.0.54
10.1.0.80

[Datacenter-2]
10.1.0.117
10.1.0.193
10.1.0.65

So how do I use it?

Once you have your inventory defined and your ssh keys configured, then you can start running some simple commands. First thing to note is an particular IP address can be listed many times in the inventory as it might be in different groups. To find out what IP addresses are in a particular group you can :

ansible --list-hosts opscenter
    10.1.0.19

or

ansible --list-hosts cluster
    10.1.0.183
    10.1.0.54
    10.1.0.80
    10.1.0.117
    10.1.0.193
    10.1.0.65

Then you can use this list and execute a particular module against your selected inventory. This sounds more complicated than it is, so probably best to just have an example. Let’s start with the shell module. This is a module I’m actually not a fan of, as the whole purpose of ansible is to distance yourself from writing and debugging shell scripts. Say I want to execute a grep on a configuration file, on all the nodes that make up my Cassandra cluster (Did I mention I was a Cassandra fan?). Then with ansible you could :

ansible cluster  -m shell -a "grep cluster_name /etc/dse/cassandra/cassandra.yaml"
10.1.0.80 | FAILED => SSH encountered an unknown error during the connection. We recommend you re-run the
command using -vvvv, which will enable SSH debugging output to help diagnose the issue
10.1.0.117 | success | rc=0 >>
cluster_name: killrvideo-prod

10.1.0.183 | success | rc=0 >>
cluster_name: killrvideo-prod

10.1.0.193 | success | rc=0 >>
cluster_name: killrvideo-prod

10.1.0.65 | success | rc=0 >>
cluster_name: killrvideo-prod

10.1.0.54 | success | rc=0 >>
cluster_name: killrvideo-prod

The output is nicely colour coded in real life and provides meaningful error messages to help you understand what might have gone wrong. In this case it seems like the ssh key was not distributed to the node with the IP address 10.1.0.80.

The question I am not going to answer here, is why did we need to grep for the value in the configuration file in the first place? Did we not know what the value was? Which gets into the world of Playbooks and the power of the template module, which I will discuss in my next article on ansible.

My final takeaway, ansible just like it’s competitors works on the principle of defining what you want your endpoint to look like. For example you might want to have a configuration file with some values in it and have a service up and running using that configuration. Obviously, if you change the values in the configuration file, you will need to restart that service. Trying to put that logic into a script is complex and error prone. In contrast, using ansible pre-defined modules (e.g. template and service) it is easy or to put it another way

if you find yourself using the “shell” module to do things in ansible, you are doing it wrong!