Ansible Automation: A Comprehensive Guidebook

Published Feb 22, 2017Last updated Mar 06, 2017
Ansible Automation: A Comprehensive Guidebook

Table of Contents

What Is Ansible?

Ansible is an impressive tool that can help you deploy and configure any number of virtual machines with incredible ease. Ansible does not require an agent to be installed on the host and instead connects to a machine via SSH. This means that just about any modern flavor of Linux will be compatible with Ansible out-of-the-box. Ansible can automate anything you can do at the command line.

Ansible Basics

Ansible Playbooks, YAML, and Jinja2

Ansible uses YAML as the language for its source material — the Ansible playbook. YAML is human-readable, making Ansible playbooks incredibly easy to read and understand. However, this also means that you must be very careful with the formatting of your Ansible playbooks as one extra space is all it takes to send you on a wild goose chase. Ansible also incorporates Jinja 2 templating, which allows you to create incredibly expressive and powerful templates that you can apply to a large number of machines quite easily.

Ansible Modules

Ansible encapsulates all of the logic required to work with a platform in reusable code bits it calls modules. Ansible includes modules with every installation for just about anything that you might possibly want to do: copy files, execute an arbitrary command, install or remove packages, interact wih AWS or Digital Ocean, and more. The default modules are contributed by the community and the list is always growing. And, if you can't find a module that implements the functionality you are looking for, you can always write your own. Modules are written in one of the easiest languages in use today: Python.


As you work with Ansible, you will hear a great deal about idempotence. Essentially, idempotence is the property of certain operations that can be executed multiple times without changing the result of the initial application. In other words, if you tell Ansible to change something, and Ansible determines that there is no need to implement the change because it's already in the desired state, then nothing will be changed. I suppose you could say idempotence is a fancy word for 'knowing when not to do something'.


Variables are at the core of what Ansible does. How else would a tool like Ansible be able to handle the configuration of so many systems? Variables in Ansible are extremely easy to define. You simply need to write the variable name, follow it with an equal sign, and then assign it a value.

my_host =

In the example above, we created a variable called my_host and assigned it a value of Once you have defined a variable in your playboooks, you can easily reuse it anywhere in your playbooks by doing something like this:

ServerName {{my_host}}

Ansible replaces everything inside the moustache brackets with the value of the variable, whose name is contained within them. Therefore, taking the two above statements, we'll arrive at the conclusion that:


There is one very important thing to keep in mind about variables in Ansible:

The Ansible Playbook

When you're working with Ansible, chances are that you will be working with playbooks. Playbooks are where the Ansible magic happens. Playbooks are nothing more than text files and look like this:

# Example Ansible Playbook by Jorge Vazquez from
- hosts: webservers
    http_port: 80
    https_port: 443
    home_directory: /var/www/html
  - name: Install Apache
    yum: name=httpd state=latest
  - name: Configure the Web Server
    template: src=/files/httpd.j2 dest=/etc/httpd/conf/httpd.conf
    - restart apache
  - name: Start Apache and enable it to run at boot
    service: name=httpd state=started enabled=yes
    - name: restart apache
      service: name=httpd state=restarted

In the above example, we have a playbook that will install the latest version of Apache, apply a predetermined configuration to the web server, ensures the web server will start at boot, and restarts the service.

Playbooks can contain multiple plays. This means that you can target your web servers for certain tasks, then target your database servers, and then target your load balancers, or something else.

It is entirely possible to write a playbook with a very long list of tasks - this is how most of us learned the basics. However, it won't take long before you will want to reuse code and begin to get yourself organized.

Including the Roles of Reusability

Including task files allows you to break up playbooks into smaller files. Task includes 'use tasks' defined in other files. Handlers are tasks, too, so you can also include handler files from the ‘handler’ section! Playbooks can also include plays from other playbooks. The plays are inserted into the playbook to form a list of plays.

As you begin to understand these concepts, you will realize that the true purpose of Ansible is not to make your computing environment look a certain way but rather to model your computing environment into something you define.

Until Next Time

In the second part of this primer, we will talk about roles with greater detail, and we will see how easy it is to craft playbooks with them. We will also cover conditional statements, task handlers, and will talk about the Jinja2 templating system as implemented by Ansible.

The third and last part of the series will cover the Ansible Inventory, Ansible Vault, and Ansible Galaxy. At the end of the series, I am confident that you will be able to leverage what you have learned to write your own playbooks to automate much of your deployment and configuration tasks.

Here are a few links for those of you who just can't wait for the next installment!

If you'd like to communicate with me, you can always send a note to my Gmail account.!

Discover and read more posts from Jorge Vazquez
get started