How to build Ansible Playbooks and Automate

In our latest post about Ansible we discussed about Ansible’s basics, now we’ll teach you about Ansible playbooks

ABOUT PLAYBOOKS

Playbooks are simpler ways for using ansible to execute several tasks, simple configuration management and multi machine deployment system on the host/s.

Playbooks can declare configurations, but they can also orchestrate steps of any manual ordered process, even with different steps must bounce back and forth between sets of machines in particular orders. They can launch tasks synchronously or asynchronously.

ADDING HOST WITH AN INVENTORY

One of the first things to do to manage the host is to specify them on Ansible.

For this we will use a file named hosts with the following content:

$ web ansible_ssh_host=198.199.115.67

That’s it. Let’s just make sure this works. Run the following command::

$ ansible -i hosts all -m ping -u root -k -v

This file is called an inventory, it lists the hosts that you will be managing with Ansible.

This hosts should be on the folder you’ve created for storing your Ansible files, playbook and roles. We recommend to have this folder on /etc/ansible

ORGANIZING PLAYBOOKS WITH ROLES

Roles are ways to automatically loading certain vars_files, tasks, and handlers based on a known file structure. Grouping content by roles also allows easy sharing of roles with other users.

Roles are just automation around ‘include’ directives as described above, and really don’t contain much additional magic beyond some improvements to search path handling for referenced files. However, that can be a big thing!

Example project structure:

In a playbook, it would look like this:

---- hosts: webservers  roles:     - common     - webservers

In Ansible 1.4 and later you can configure the roles_path to search for roles. Use this to check all of your common roles out of one location, and share them easily between multiple playbook projects.

If any files are not present, they are just ignored. So it’s ok to not have a ‘vars/’ subdirectory for the role, for example.

Note, you are still allowed to list tasks, vars_files, and handlers “loose” in playbooks without using roles, but roles are a good organizational feature and are highly recommended.

STRUCTURE OF A PLAYBOOK

Playbooks are expressed in YAML format and have a minimum of syntax, which intentionally tries to not be a programming language or script, but rather a model of a configuration or a process which makes Ansible easier to manage.

The goal of a playbook is to map a group of hosts to some well defined roles, represented by things ansible calls tasks. At a basic level, a task is nothing more than a call to an ansible module, which you should have learned about in the previous post.

By composing a playbook of multiple ‘plays’, it is possible to orchestrate multi-machine deployments, running certain steps on all machines in the web servers group, then certain steps on the database server group, then more commands back on the web servers group, etc.

“Plays” are more or less a sports analogy. You can have quite a lot of plays that affect your systems to do different things. It’s not as if you were just defining one particular state or model, and you can run different plays at different times.

Playbooks may define several things depending on the complexity and structure of it.

LET’S CREATE OUR FIRST PLAYBOOK

Now we’re gonna create our first playbook! Let’s remember a playbook is a key concept in Ansible. It defines what needs to be configured and executed on your hosts.

First, let’s create a file named our_first_playbook.yml in the same folder as your inventory file with the following content, which is an example of a basic playbook structure.

---- hosts: example_hosts  tasks:    - name: Installs nginx web server      apt: pkg=nginx state=installed update_cache=true      notify:        - start nginx   handlers:    - name: start nginx      service: name=nginx state=started

Let’s analyze this playbook

The file starts with:

---

This is a requirement for YAML to interpret the file as a proper document. YAML allows multiple “documents” to exist in one file, each separated by —, but Ansible only wants one per file, so this should only be present at the top of the file.

YAML is very sensitive to white-space, and uses that to group different pieces of information together. You should use only spaces and not tabs and you must use consistent spacing for your file to be read correctly. Items at the same level of indentation are considered sibling elements.

Items that begin with a – are considered list items. Items that have the format of key: value operate as hashes or dictionaries. That’s pretty much all there is to basic YAML.

YAML documents basically define a hierarchical tree structure with the containing elements further to the left.

On the second line, we have this:

---- hosts: example_hosts

This is a list item in YAML as we learned above, but since it is at the left-most level, it is also an Ansible “play”. Plays are basically groups of tasks that are performed on a certain set of hosts to allow them to fulfill the function you want to assign to them. Each play must specify a host or group of hosts, as we do here.

Next, we have a set of tasks:

---- hosts: example_hosts  tasks:    - name: Installs nginx web server      apt: pkg=nginx state=installed update_cache=true      notify:        - start nginx

At the top level, we have “tasks:” at the same level as “hosts:”. This contains a list (because it starts with a “-“) which contains key-value pairs.

The first one, “name”, is more of a description than a name. You can call this whatever you want.

The next key is “apt”. This is a reference to an Ansible module, just like when we use the ansible command and type something like:
ansible -m apt -a ‘whatever’ all.

Next steps

Now that you step up the basic knowledge of Ansible’s basics (Playbooks, roles and inventories) we’re ready to do some cool things with Ansible. Please visit our next post with more Ansible tips and tutorials that will be available soon.

Here at ClickIT, we are experts providing Managed services with DevOps solutions such as Ansible, Chef and AWS Opswork. Our Agile Team also includes leading IT experts in application migration in the cloud, web security, web development, IT automation, clustering, scalability and near-shore support”.