Ansible – Part I

There are tons of config management / automation tools out there (puppet, salt stack, juju, rudder, CFEngine,.. just to name a few) all with their pros and cons and at the end of the day you have to choose the best fit for your job (if you’re lucky – sometimes you have to stick with the crap someone else has brought on board and make the best out of it, we’ve all been there) and/or combine some of them or extend them with some others. But one thing is for sure, there is no holy software grail out there that does it all.

A couple of years back I came across Ansible and instantly got hooked. But why?

• agentless
• simple
• flexible
• powerful
• extendable

If you’ve read the list and instantly thought “Hellyeah!, let’s get started” that’s awesome, because you don’t need much to get things rolling.

First things first you need to set up a Linux/macOS/BSD control machine/node. I use CentOS for 90% of my Servers in my lab, but you can use any other Linux distribution that is supported.

yum install -y ansible

…and Ansible is installed on your control machine. Pretty neat, right?

You can run everything from the default folder structure, or you can create a new directory structure and add it to your version control of choice. I did the latter and used this article as guideline for my structure. One of the positive side effects of this is that you can pull it from your repository onto any server with an Ansible installation and you’re ready to go.

Once the directory stuff is sorted out you need to create a file named ansible.cfg in your newly created directory (depending on setup there are 3 config files Ansible can use). This file holds the configuration settings for your setup.

[defaults]

inventory = /mydir

library = /mydir/library

module_utils = /mydir/module_utils

….

Next on your list is the inventory file “hosts” – you can list and group your servers, switches, firewalls, you name it – in this file. There are many ways you can organise/group your entries (i.e. by site, AZ, whatever does the job.

[ansible-testservers]

anstest00.homelab.local

anstest01.homelab.local

anstest02.homelab.local

anstest03.homelab.local

 

[anstest-az1]

anstest00.homelab.local

anstest01.homelab.local

 

[anstest-az2]

anstest02.homelab.local

anstest03.homelab.local

 

[anstest-dc]

anstest-az1

anstest-az2

From the authentication part there are several ways to do so, so if you want to just mess around with Ansible you could add the way of authentication (type/user/password) to your inventory, but like stated before, this is just for messing around. If you consider thinking about stuff like this for a production environment you are going to hell for this. What you should do is add the credentials to Ansible Vault and  point from your Playbook to the vault for credentials.

Everything you execute is done through a playbook. This can be everything from just simply updating a single vm through configuring an entire datacenter. So i.e updating 1 to n CentOS machines could look like this:

—

– name: update centos vms

hosts: ansible-testservers

tasks:

– name: update yum all

yum:

name: ‘*’

state: latest

Playbooks can be executed against the entire group of servers OR you could pick specific parts of your inventory. Let’s imagine your Environment (anstest-dc) has two AZs (anstest-az1, anstest-az2) and you want to update just one (anstest-az1), you could just point to that location in your inventory.

ansible-playbook -i anstest-az1 updatesomething.yml

This was just a little overview. Part II will cover how you can manage your vmware infrastructure.