Ansible in 5 Minutes — Automating the creation and management of infrastructure

Frequently, developers take full responsibility for creating features and deploying them into production as quickly as possible in order to gain value from their changes. Whilst Operations will ensure that the current service provided is both reliable and secure. Because of this often times developers are tasked with the impossible and have to cut corners to meet release deadlines, therefore creating technical debt. I’m sure if you’ve ever spent time within any digital agency you’ll be familiar with this. The problem is as this technical debt mounts up over time, the time to market increases, work queues get bigger and product delivery cycles move slower.

Ideally, small teams of developers would independently implement features, test against preproduction environments, and have their code deployed automatically, quickly, safely, and securely. Therefore making deployments routine and predictable and avoiding the Friday 5 pm Panic when it's not gone your way.

Enter, DevOps … and more specifically, Ansible.

Ansible is a simple but extremely powerful Automation tool and one of the most important tools in the DevOps toolkit. It can be used to automate any infrastructure updates, deployments, or releases. It’s written in simple script format and can operate on not only a single host but on a whole network of computers at once.

Using ansible we can configure our own custom inventory files that dictate how a network of computers should be managed and what purposes they will serve. Then we can run ‘playbooks’ on these hosts to update them to their desired state. Let's run through an example where we have a network of three machines, two of which we shall update apache ( web-001, web-002), and on the other, we shall update Postgres ( db-001 ).

Firstly let's define our host lists, we’ll create a cluster group that contains all our hosts. A webservers group that will house our two apache hosts, and a databases group that contains just our PostgreSQL host.

inventory/hosts.yml:

cluster:
  hosts: 
    web-001 { ansible_host: 192.168.0.1 }
    web-002 { ansible_host: 192.168.0.2 }
    db-001 { ansible_host: 192.168.0.3 } 

web_servers:
  hosts:
    web-001:
    web-002:

databases:
  hosts:
    db-001: 

Great! Now we’ve got our inventory sorted let’s create a playbook to implement these.

playbook.yml

---
- name: Update Web Servers 
  hosts: webservers
  
  tasks:
  - name: Ensure Apache is at latest version
    yum:
      name: httpd
      state: latest
    
- name: Update DB servers
  hosts: databases:
  
  tasks:
  - name: Ensure PostgresSQL is at latest version
    yum: 
      name: postgresql
      state: latest
  
  - name: Ensure PostgresSQL service is running
    service:
      name: postgresql
      state: started

As you can see above we have now created a playbook and configured two sets of tasks. The first will run on the webservers host groups and install/update apache to the latest version using yum. The second set of tasks will install/update Postgres and ensure its service has started.

One of the great things about Ansible is that it can be idempotent, therefore we can run this playbook repeatedly and it will only make changes on servers that don’t match its desired configuration. So whether you’re running a playbook once or multiple times, the output should always be the same.

We can now run our new playbook and pass it our desired inventory file.

$ ansible-playbook playbook.yml -i inventorties/hosts.yml

This will now run and complete its tasks, giving you feedback on when a task has been completed with a state change, when the server already had the desired state configured so no work was done, or when the task was either skipped or failed.

And that’s how easy it is to use ansible to manage your hosts. As you can see as we scale up our network ansible can easily scale with it, by just modifying our inventory file we can add extra hosts and groups. Not only that, but if we wanted to create the same setup on a different site, we can just set up a new inventory file and run the same playbook. We can even use inventory-specific variables and inventory-specific secret credentials to ensure our playbook remains universal no matter what the environment.

Anytime we would like to add more configuration to our platform, we can simply add more tasks to our playbook, since the rest of it is idempotent it will ensure that wherever your stack is deployed, it will always reach the desired current state of implementation. If we want to scale this even more, we can use Ansible roles to separate out each of these groups of tasks into importable sets — see the documentation for more details.

Finally, since Ansible is a Redhat open-source platform it has a wide variety of community-made modules. This means we can utilize and automate a huge range of different applications. Using Ansible-galaxy we can import any of these modules right into our own codebase.

Personally, I think ansible is one of the most useful tools you can learn right now in the DevOps space but I might be biased as a Certified Ansible Developer myself. But I can tell you that this tool has saved me and my company hours and hours in deployment time over the years.

That’s all folks! If you enjoyed reading this I regularly post DevOps articles exclusively on Medium — If you would like to read more I recommend checking out the stories below.

Next week we’ll be doing an introduction on Terraform and Jenkins and working towards combing the tools together with Ansible for some automated deployment pipelines.

You can find links to my other work on Medium and follow me here. Thanks for reading!