Getting started with Ansible Playbooks can be addictive! Here’s how you can get yourself hooked!

Ansible? Playbooks? Modules? Confused? Don’t worry, we’ve all been there…

Alright, let’s start off with the basics. What is Ansible? In a nutshell, Ansible is an open-source IT automation tool that can help you simplify complex configuration, management, and application deployment.

There are quite a few good reasons for Ansible’s rise in popularity, such as its agentless architecture and easy-to-use (and learn) approach. Here’s the official quick start guide: Now if and when you’re ready to take things to the next level, there’s also a paid version called Ansible Tower – but that’s outside the scope of this blog post.

Basic Concepts

Ok so we’re now going to try and define some basic Ansible concepts. First of all, a single action or activity that you want to execute through Ansible, is called a ‘Task’.  A collection of one or more tasks makes a ‘Play’, and a collection of plays makes a ‘Playbook’!

So how does Ansible know how to perform a specific task (or a group of tasks) in a Playbook? For example, if you wanted to create a Playbook with tasks for creating a user, setting up the volumes, etc., Ansible needs a way to be able to communicate with your NetApp storage, right?

That’s where Ansible modules come into picture. Think of Ansible modules as the drivers that enable Ansible to communicate with the target environments. Ansible comes with a library of modules. For example, there’s a ‘service’ module, a ‘yum’ module, and if you wanted to create volumes on NetApp ONTAP, you’d use the ‘ ontap_volume’ module.

So for example, you would use the ‘service’ module if you wanted to ensure that the Apache service was running on a remote server. Here’s what part of your Playbook would look like:

In the above example, we define the action through the ‘ state’ variable. Every module comes with its own set of supported parameters and options that you need to specify in your Playbook. You can read a module’s associated documentation by running the “ ansible-doc MODULE_NAME” command.


Now if you’re still confused between modules and playbooks, here’s how I usually describe the difference – think of the Playbook as the piece where you define WHAT your target environment should look like, and then modules help take care of HOW Ansible will execute the necessary changes.

So to reiterate, each module implements specific functionalities, and we use these functionalities in tasks of a Playbook.

Writing your Playbook:

Ok so once you have installed Ansible on your Client (remember, since Ansible is agentless you don’t need to configure anything on the server!), you will need to add the hosts that you want to manage to your ‘ /etc/ansible/hosts/’ file. For example, if you wanted to manage a CDOT cluster with 3 nodes, your hosts file would perhaps look like:

An Ansible Playbook is a YAML file, and is pretty easy to understand and write.

Let’s assume that you want to write a Playbook to create new volumes on all 3 nodes of your cluster. Here’s how you can do it.

As you’ll notice, we have defined 1 task in the ‘tasks’ section, and this task is utilizing the ‘ na_cdot_volume ’ module. We also added other parameters to configure this task as required.

Now let’s say you want to add a second task of creating a 5 GB LUN on this volume that we just created. Your yml file may look like:

That’s it! All that you need to do now is run your Playbook!
ansible-playbook first_playbook.yml


Now if you run the same Playbook again, you’ll notice ‘changed=0’ in your console output which indicates that no changes had to be made to get the target environment to the desired state.

Now that you know what Playbooks and Modules are, go ahead and think of things you can automate! In a future blog post, I’ll also talk about how you can write your own modules, if one doesn’t already exist for a functionality that you seek.

If you’re interested in looking at some sample Playbooks for the NetApp modules, you can find them here:

Sumit Kumar on Twitter
Sumit Kumar
Sumit joined NetApp as a Technical Marketing Engineer for OpenStack in May 2015. He has been an active participant in various Openstack meetups, and has presented sessions on various topics in multiple OpenStack forums. He is very excited about the future and potential of OpenStack, Docker containers, and various infrastructure and DevOps tools!

Leave a Reply