An Introduction to Ansible Playbooks

Ansible is an open-source tool that uses playbooks to enable configuration management, software provisioning, and application deployment. It is primarily written in Python and was released in 2012. Ever since then, it has saved countless hours of often menial work of deploying and maintaining IT infrastructure. Overall, Ansible is very consistent, secure, reliable, and it requires a minimal learning curve. Simply put, Ansible is a powerful tool for automating apps and infrastructure. You can read more about general Ansible information in our recently published article.

What Are Ansible Playbooks?

Ansible Playbooks are sets of “directives” (or plays) that a user can send to a single target server or multiple servers. They are at the heart of Ansible itself and enable automating infrastructure management. Ansible Playbooks offer excellent repeatability and re-usability in managing and deploying simple or complex applications, often on a significant amount of machines. As an analogy, imagine an NBA team using various playbooks they created for specific situations on the game day. Things are similar to IT departments within the company. Ansible Playbooks enable them to deploy multiple “plays” for particular purposes.

Basic Ansible Syntax

Ansible Playbooks are expressed (written) in YAML (Yet Another Markup Language). Ansible creators opted for YAML since it is relatively easy for humans to write it, read it, and understand it (compared to XML or JSON, for example). It is important to note that YAML is a space indented format for representing data. YAML is a strict language, and the file starts with --- (3 hyphens). 

Overall, the Ansible playbook is a single YAML file. Inside the playbook, we have individual plays (we can have one or multiple plays in a single playbook file), which define a set of tasks that will be run on servers. In conclusion, a task is an action that will be performed on the target hostname/s (executing a command, installing a package, etc.)

Basic YAML tags

• name: The name tag defines the name of a specific Ansible Playbook. In plain English, it explains what the play will be doing. 
• hosts: hosts tag enables us to specify specific hostnames or groups to use in the playbook (defined in the inventory file). This tag is required in the playbook.
• tasks: tasks are specific actions that will be performed. It usually has a name field that describes the task. 
• vars: this tag enables us to define variables that we will use in our playbooks. Variables in Ansible help us in bridging the differences between various systems. Usage is similar to programming languages.

Adjusting the inventory file

In this article, we will not cover installing Ansible, as we wrote about it here. However, before creating and executing Playbooks, we need to edit the inventory file inside our Ansible directory. Default inventory location is /etc/ansible/hosts. However, we can create a custom inventory using the following command.

touch inventory 

Additionally, note that we can specify whatever inventory file we would like to use with the -i <path> option when running the playbook. 

Inside the inventory file (whichever one we decide to use), we can add our hostnames so that Ansible understands the hosts where the playbook is executed. Ansible offers great additional flexibility with defining hostnames in the inventory. We can add them one by one, but we can also create a group for easier targeting inside the playbook. Let’s take a look at an example inventory file.

mainserver.test.com

[webservers]
web01.test.com
web02.test.com

[dbservers]
db01.test.com
db02.test.com

[apps]
app01.test.com
app02.test.com

Playbook Examples

Let’s look at the following simple Ansible playbook example:

---
    name: install and start HTTPD
    hosts: mainserver.test.com
    remote_user: root
    tasks:
    - name: Install HTTPD
         yum:
                name: httpd
                state: present
         
    - name: Start HTTPD
         service:
                 name: httpd
                 state: started

As noted in the example above, we would run this playbook only on one hostname - mainserver.test.com. It is also important to note that the host we are targeting is defined at the play level inside the playbook. If we wanted to run this playbook on our webservers, we could replace the mainserver.test.com entry with a group of web servers. This way, all the web servers in that group noted in the inventory file would be selected. 

In this simple example, this playbook would install and start-up httpd. Even though it is obvious and logical, we made the first task installing httpd, not starting it up. YAML syntax is tightly regulated, and accuracy is essential, especially when it comes to executing tasks. It is critical to pay attention to the indentation and order of tasks we have created in our playbooks as they are executed one after another. 

Script to Playbook

To expand on our previous example of installing Apache, imagine installing Apache web server on 100 different servers without automation that Ansible provides. This task would have to be done manually, which is not productive, nor is it efficient. If sysadmins had to do this manually, they would probably use a script like this.

#!/bin/bash
# Install Apache.
yum install --quiet -y httpd
# Copy configuration files.
cp httpd.conf /etc/httpd/conf/httpd.conf
cp httpd-vhosts.conf /etc/httpd/conf/httpd-vhosts.conf
# Start Apache and configure it to run at system boot.
service httpd start
chkconfig httpd on

One of the best attributes of Ansible Playbooks is that it’s relatively easy to transform shell scripts into Playbooks, which is written in YAML. To avoid the menial labor of running this script on one server at a time, we can create the following Ansible Playbook and run it from the same dir in which the playbook is located using the following command.

root@host:~# ansible-playbook playbook.yaml

 ---
     name: Install and configure Apache
     remote_user: root
     hosts: webservers     

     tasks:
       - name: Install Apache.
         command: yum install --quiet -y httpd httpd-devel
       - name: Copy configuration files.
         command: cp httpd.conf /etc/httpd/conf/httpd.conf
         command: cp httpd-vhosts.conf /etc/httpd/conf/httpd-vhosts.conf
       - name: Start Apache and configure it to run at boot.
         command: service httpd start
         command: chkconfig httpd on

This task would install and configure Apache on all our servers within the [webservers] group noted in the inventory file.

Conclusion

In this article, we provided an overview of Ansible Playbooks on a fundamental level. Playbooks more advanced functions can be used to deploy multi-tiered applications, running updates on clusters of servers and load balancers, and other specific monitoring servers, such as Prometheus or Nagios. Ansible has transformed the industry in the last eight years since it was released. It is one of the critical components of modern technology firms that rely on a large number of machines or servers they need to maintain in their daily business.

Get Started Today!

Contact us today at 1.800.580.4985 to speak to a knowledgeable Solutions Provider who can get you the info you need, to make an informed decision right away.

Too busy to talk? Click HERE to open a quick chat with us to find out more.

Want more info in an email you can review at your leisure? Email us today to get handy advice on which product would best suit your needs.

We look forward to hearing from you!