Getting Started with NetApp and Ansible: Complete Workflow

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 worksby building a complete workflow while adding in some fancy features.

Complete Workflow

If you have been following along in the series so far, you should have a good grasp of the basics.  With that in mind, this post is really going to ramp up in terms of features, and function.  The workflow for the complete onboarding of an NFS vserverby using a playbook will be covered.

The playbook made here, will also be a template file so that it can be used over and over for all my vserver onboardings.  A separate file containing the inputs will be passed in as a variable file.  In this way, my variable file can serve as the documentation for this vserver’s onboarding

First, we create a playbook YAML file to be our vserver template.

I want to explain two new concepts being introduced here.  One can be seen in the workflow, and one will be added at the command line.

The ones you can see are lines 4-10, 20, 36, 48, 58.  This is the setup and use of a YAML alias.  This is not specific to Ansible, this is a YAML feature.  It is created in a variable section and its format is as follows.

This makes ‘alias_name’ represent all the variable:value pairs that are setup in it.  It is referenced with the following line.

I am using an alias called ‘login’ and you can see how this will save me a lot of typing.

The second concept is that of a variable file.  Variable files allow you to keep a simple YAML list of variables in a separate file and reference it by any of your playbooks.  You can define a variable file within a playbook in the hosts section like this.

Multiple files can be named in one vars_file section, just like you can name multiple variable pairs in a vars section.  However, you will see that I do not have a vars_files section.  I am doing this because I want this to be a template, and I want to be able to pass in that file path at the command line.  Let me show you my variable file.

That’s it.  I have entered all the other options I want to always use right into the playbook so everyone using it will stick to the defaults. For my defaults, I will always make vserver root volumes on aggr1 and put my first data LIF on node 1 port e0d.

The vserver and LIF naming conventions will also always be followed.  I could make these things variables also and add them to my variable file, but a good template uses as few user inputs as possible.

Using this variable file allows me to set the variable ‘hostname’ in my playbook to what ‘hostname’ from my variable file is set to, and likewise for username and password.

Now for what this playbook is doing.  I am using the following modules, and they all link to their documentation so you can learn more about them.

na_ontap_svm

na_ontap_interface

na_ontap_nfs

na_ontap_export_policy_rule

This allows me to create a new vserver, create its data LIF with management access allowed (line 31 of the playbook), setup and start the NFS service, and modify the default export-policy so that read-only access exists across the root of the junction path so that my future export-policies will allow proper access to my volume exports.

I have saved this playbook as vserver.yml and in the same directory I have a vars.yml file that is my variable file.  I run this playbook like this.

The @vars.yml lets Ansible know that it’s a variable file.  If I just wanted to pass in variables I can do that like this:

By instead naming my variable file ansibleSVM.yml I know that it is the unique configurations for that SVM and could have my documentation chain that way.

Now you begin to see the power that Ansible gives you, and it’s not limited to just what ONTAP or Element can do.  You can use Ansible to provision storage, and then present that share to a host all in one playbook.  I encourage you to experiment with what can be done.  If you are a NetApp customer (and really you should be 🙂 ) you can download the ONTAP virtual simulator from here  There are even PDF guides to help you do it.

Finally, as a last gift, I also have a Docker container that I build weekly with a CI/CD process that builds with the most current Ansible and the most current NetApp modules.  If you like Docker and want to use this container to test out Ansible with, you can get it from https://hub.docker.com/r/schmots1/netapp-ansible/

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

The video demo of this playbook being used can be seen here.

Part 1. Install Ansible
Part 2. Update NetApp Modules
Part 3. Understanding Playbooks
Part 4. FirstPlaybook 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