Ansible overview

Ansible in its simplest form has been described as a Python-based open source IT automation tool that can be used to configure\manage systems, deploy software (or almost anything), and provide orchestration to a process. These are just a few of the many possible use cases for Ansible. In my previous life, as a production support infrastructure engineer, I wish such a tool existed, so that I could have had much more sleep and a lot less grey hair.

One thing that always stood out to me in regards to Ansible is that the developer's first and foremost goal was to create a tool that offers simplicity and maximum ease of use. In a world filled with complicated and intricate software, keeping it simple goes a long way for most IT professionals.

Sticking to the goal of keeping things simple, Ansible handles configuration/management of hosts solely through Secure Shell (SSH) and absolutely no daemon or agent is required; the server or workstation where you run the playbooks from only needs Python and a few other packages, most likely already present, installed. Honestly, it does not get simpler than this.

The automation code used with Ansible is organized into something called playbooks and roles, which is written in the YAML markup format. Ansible follows the YAML formatting and structure within the playbooks/roles. Being familiar with YAML formatting helps you while creating your playbooks/roles. If you are not familiar with it, do not worry, as it is very easy to pick up (it is all about the spaces and dashes).

The playbooks and roles are in a non-complied format and making the code is very simple to read, if you are familiar with standard Unix\Linux commands. There is also a suggested directory structure to create playbooks. One of my favorite features of Ansible is enabling the ability to review and/or utilize playbooks written by anyone else with little to no direction needed.

Note

I strongly suggest that you review the Ansible playbook best practices before getting started at http://docs.ansible.com/playbooks_best_practices.html. I also find the overall Ansible website very intuitive and filled with great examples at http://docs.ansible.com.

My favorite excerpt from the Ansible playbook best practices is under the Content Organization section. Having a clear understanding of how to organize your automation code proved very helpful to me. The following is the suggested directory layout for playbooks:

group_vars/
   group1            # here we assign variables to particular groups
   group2            # ""
host_vars/
   hostname1         # if systems need specific variables, put them here
   hostname2         # ""

library/             # if any custom modules, put them here (optional)
filter_plugins/      # if any custom filter plugins, put them here (optional)

site.yml             # master playbook
webservers.yml       # playbook for webserver tier
dbservers.yml        # playbook for dbserver tier

roles/
   tasks/            #
       main.yml      #  <-- tasks file can include smaller files
   handlers/         #
       main.yml      #  <-- handlers file
   templates/        #  <-- files for use with the template resource
       ntp.conf.j2   #  <------- templates end in .j2
   files/            #
       bar.txt       #  <-- files for use with the copy resource
       foo.sh        #  <-- script files for use with the script
   vars/             #
       main.yml      #  <-- variables associated with this role
   defaults/         #
       main.yml      #  <-- default lower priority variables for this role
   meta/             #
       main.yml      #  <-- role dependencie

It is now time to dig deeper into reviewing what playbooks, roles, and modules consist of. This is where we will break down each of these components according to their distinct purposes.