What Ansible is and what it isn’t

Ansible can be categorized as a Devops Automation Tool and a Configuration Management Tool. Redhat defines it as:

Ansible delivers simple IT automation that ends repetitive tasks and frees up DevOps teams for more strategic work. — Ansible website

I’m assuming that you’re familiar to the concepts of devops, infrastructure as code and configuration management, so I’m not going to detail them here.

I see Ansible as a way to create and configure environments. It’s mostly used to configure than to create them though.

Ansible uses a set of modules to compose the final state to the desired configuration. So, for example, if you want to configure a Linux VM installing packages, downloading software and executing some shell scripts, you will need to compose this task using a group of modules. You will have to use the apt or yum module to update and install packages, then you will use the get_url to download software and finally you will use the command component to execute some shell commands.

Using Ansible you can:

• Provision new environment (like Terraform) using AWS, GCP or Azure modules
• Configure new environments to make them ready to be used
• Configure and maintain (upgrade) existing environments

What makes Ansible different from Chef and Puppet

When I was introduced to Ansible, the first thing that came to my mind was: ok, how is this different (or better) from the configuration management tools that I already use (chef and puppet).

And I can tell you that after learning a little bit more about Ansible, I can say that it’s definitely my first choice.

It’s easier

As I said before, Ansible uses a module approach, so you compose your jobs as a set of module tasks. This is not that different from the existing tools; however, the way that Ansible requires you to build the jobs makes it easier to understand and maintain those tasks. It uses a more natural language to describe the final desired state.

Here’s an example: this task is responsible for updating the yum packages and install a few others.

It uses the push model

This is the most important feature for me. Usually, Configuration management tools require you to install an agent in your target server. Thus, if you want to configure a server to have pre-installed software, you will have to install the agent first. In a scenario that we have permission to customize the base image or container, this won’t be a bit deal. However, in most enterprise architecture scenarios, the technical team doesn’t have permission to update the base image or even permission to install the agent manually. That is the best scenario for Ansible because it just needs you to have ssh access to the server. Instead of requiring an agent to pull configuration from a server, Ansible uses a push approach. It creates a temporary runnable app in the master server and them pushes this runnable through SSH to the host servers. This runnable is responsible for executing and configuring the server to the desired state. Therefore, no software or agent is installed, everything is executed just using the SSH user’s permission.

It can provision infrastructure

Another good Ansible feature is its ability to provision infrastructure. It has modules to connect to famous public clouds (AWS, GCP and Azure) and then provision VMs, containers, services and etc. This is really useful because you don’t have to pull out a Terraform to create your infrastructure, you can just use Ansbile to do it. With Ansible you can have everything from provision to configuration in just one place.

Why you should be using it

For me, there are four main reasons to use Ansible. Two of them I have already covered in the last section: it’s really easy to create and maintain scripts and you don’t have to install agents.

In addition to that, there is two more that you should be considering:

You can leverage it to create your local environment

I know that you can use shell scripts or anything else to create your local environment, I had done that myself before I got Ansible, but not anymore. Using tasks and jobs made it really easy to debug issues and transform a shell execution in a more reproducible set of steps. I was able to reduce my local environment setup from a few hours to minutes.

The Red Hat Factor

It’s important to notice that Ansible is an open-source project sponsored by Red Hat. If you have a small infrastructure or a small cloud, you won’t be missing anything using the plain open version. However, in a more complex cloud (a couple of thousand servers), you can leverage the corporate power of Ansible Tower. This Red Hat product provides you with visual dashboard, role-based access control, job scheduling, integrated notifications and graphical inventory management.

How to start using it

As I said, you can start using it right now in your local environment. Of course, if you already have servers to configure and maintain, it’s more fun to use Ansible to do that; however, you don’t need servers to practice your Ansible skills, you can do it just using your localhost as the target host.

Here’s an example of my local environment set up using Ansible:

https://github.com/zamariola/local-environment

There is an official Red Hat course about it: https://www.redhat.com/en/services/training/do007-ansible-essentials-simplicity-automation-technical-overview

And a Quick start video:

Good luck!

• development
• devops
• architecture
• stack
• ansible