Getting Started with NetApp and Ansible: Understanding Playbooks

Automation and Configuration Management are indispensable to an efficient DevOps driven environment. NetApp supports Ansible modules for ONTAP and Element software .  So, let’s get right to it and see how all this works.

Understanding Playbooks

Now that we have Ansible installed, let’s understand the special file that makes things happen.  This file is called a ‘playbook’.  The playbook is written in yaml, which is itself a simplified version of json.

A playbook is composed of one or more sections, which each can contain one or more tasks to run.  I will refer to these as the ‘hosts’ section and the ‘tasks’ section

Here is a sample playbook, that we will look at.

The host section is used to declare some common information that can be used by all tasks associated with it.  Here is the host section

Let’s look at each line in order.  Line 1 is three dashes, all Ansible playbooks need to start with these three dashes. Line 2 contains our first section dash. A section dash helps designate a series of lines or settings that are designated with a top level.  The actual data on line 2 is the entry for “hosts”. In this example we have set hosts to equal ‘databases’.  This means that all of the systems defined in the databases section of our Ansible inventory file would be acted on by this play.

Line 3 sets the ‘name’ option.  Here name is set to “Main Play Title”.  It is usually a good idea to give this an entry that defines what the entire play will do.  For example if I were creating a playbook that would backup my databases, I would probably set name to “Database Backups”.

Line 4 starts a variable section.  The variables are name/value pairs that are accessible by all tasks referenced under this hosts section.  In my example I would be able to reference my first name by using the variable call “{{ name_first }}”.

Line 5 designates the end of the hosts section and the start of our tasks.  Now, there are many more options that can be used in the hosts section and I will cover some of them in future posts.

Now we look at the task section.

Line 1 of this section (which would be line 8 of the playbook) is another “name” entry and defines the start of another dash section.  This name entry will be shown when the playbook is run for this step to help you keep track of what is happening.  Line 2 is the actual module we will be running, in this case “mount”. This line must always end with a ‘:’. You can get a full list of modules that Ansible has here.  Lines 3-6 are options that are set for the mount module, they will be unique to each module/task you run.  Do notice the “{{ name_first }}” and “{{ name_last }}”.  That is an example of calling a variable in a task entry .

The last thing to see about a playbook is the formatting.  Each section is two spaces indented from the previous.  So, hosts is top level with no leading space indents  Each top level key is indented by two spaces.  A – indicates an item in a list.  Under tasks, we expect a list of tasks.  Each – name: xxx (at the same level of tasks, counting the -) start a new task section (a dictionary).  In this example ‘mount’ could have a four space indentation.

More information about playbooks can be found from the Ansible support documentation here.

If you have any questions or comments join me on our Slackworkspace in the #configurationmgmt channel.  Also keep an eye on for all new information on what we are doing around Ansible.

Part 1. Install Ansible
Part 2. Update NetApp Modules
Part 3. Understanding Playbooks
Part 4. First Playbook Example
Part 5. Complete Workflow


David Blackwell on Linkedin
David Blackwell
Technical Marketing Engineer for OpenStack at NetApp
David is a twenty year IT veteran who has been an admin for just about every aspect of a DataCenter at one time or another. Currently he is the Technical Marketing Engineer for OpenStack at NetApp. When not working, or tinkering with new software at home, David spends most of his free time on his hobby of 3D printing.

Leave a Reply