Getting Started with NetApp and Ansible: First Playbook Example

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. 

First Playbook Example 

Now that we have Ansible installed, and have reviewed what makes a playbook, we will create our first playbook.  In this example, we will cover the lifecycle of a volume.  Using a playbook to create, resize, and finally delete a volume. 

There are some bits of information we will need to create these playbooks.  We will need the ONTAP IP or FQDN, our admin username, and the password.  Additionally, the name of the vserver and the aggregate we use for this volume will be provided.  I am going to use the following. 

ONTAP Cluster:
Admin username: admin
Admin password: netapp123
Vserver: vserver1
Aggregate: aggr1

So, this will be a very simple playbook. We’ll cover more details about best practices in a later post. Here is what the playbook looks like.

The host section of this playbook, lines 1-10, should make sense since the last post.  The task section of this playbook, lines 11-25, contains a single task for this playbook to run.  The module that we are using is the ‘na_ontap_volume’ module in order to work with a volume.

There is one part of the hosts section that we need to call attention to.  Line 2 in the playbook defines ‘localhost’ as the host that this playbook will run against.  For most of Ansible this line calls out the systems that you want tasks to run against, however ONTAP (and Element software) can’t use ssh for module communication. Instead they use http or https initiated from…, you guessed it, the localhost.

Let’s look just at the module specific parts.

Remember from the previous post that the first line of a module section is the name of the module being run, everything within its section is options for that module. These options are specific to the module being run, in this case, na_ontap_volume, though many modules use the same name for options.

In the above, line 2 defines the state we want this volume to be in.  We are declaring ‘present’, which means that if the volume isn’t there it should be created, and if it is there, it should match most of the options specified.

Lines 3-11 are setting options for creating our volume.  We are defining the name of the volume to create or match and using a variable for it at that.  Additional options are setting the vserver this volume is a part of, the aggregate to create it on, its size and size units.  Also, being defined is the export-policy it will use and where it should be mounted to in the junction path.  If you are creating a template playbook for volume creation, you can set all the options that you want to be the same every time, and then set the options that will change to variables.  There are additional options that can be set with this volume, and they can be found in the documentation here

Lines 10-12 are used to define the ONTAP system we are running our task against, as well as the admin username and password to authenticate.  Take note that we are using the variables we defined in the host’s section.

Lines 13 and 14 are special because I am using https for my communication.  The ‘https: true” sets my module to use https instead of its default http.  The “validate_certs: false” is necessary if you are using the self-signed certs that come with ONTAP.  Since python version 2.7.5 or 2.7.9, TLS self-signed certificates are no longer allowed to validate. Since I am using the self-signed cert and not a CA cert, I have to disable the validation check.  Be aware that this will open the very small possibility of a man in the middle attack.  If you want to use http, be sure to enable it on your ONTAP cluster as it is disabled by default.

If I name this playbook file ‘volume.yml’ and have it in my current directory, I run this playbook from the command line with the following command.

Now that I have my volume created, I can edit this volume.yml file to resize that same volume.

Here is the task section, but with the ‘size’ option updated to 20.

Saving my changes and running ansible-playbook volume.yml again I can check and I will see that my volume is now 20 gigs in size.

I can also use this same playbook to delete this volume from my vserver.  By changing the state from ‘present’ to ‘absent’ I am telling Ansible that I don’t want this volume to exist.

Now when I run ansible-playbook volume.yml, Ansible connects to the ONTAP cluster and removes the volume.

Now you have seen how you can use a playbook to control the lifecycle of a volume.  Next time we will combine tasks to do more complex workflows as we begin to create a full process playbook.

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

You can see a video demonstration of these steps here.

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