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 by 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 vserver by 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.

---
- hosts: localhost
  collections:
    - netapp.ontap
  gather_facts: false
  vars:
    login: &login
      hostname: “{{ hostname }}”
      username: “{{ username }}”
      password: “{{ password }}”
      https: true
      validate_certs: false
  name: Onboard SVM
  tasks:
  - name: Create SVM
    na_ontap_svm:
      state: present
      name: "{{ vserver }}"
      root_volume: "{{ vserver}}_root"
      root_volume_aggregate: aggr1
      root_volume_security_style: unix
      <<: *login
  - name: Create interface
    na_ontap_interface:
      state: present
      interface_name: "{{ vserver }}_mgmt_data_1"
      home_port: e0d
      home_node: vsim-01
      role: data
      protocols: nfs
      admin_status: up
      failover_policy: local-only
      firewall_policy: mgmt
      is_auto_revert: true
      address: "{{ address }}"
      netmask: 255.255.255.0
      vserver: "{{ vserver }}"
      <<: *login
  - name: change nfs status
    na_ontap_nfs:
      state: present
      service_state: started
      vserver: "{{ vserver }}"
      nfsv3: enabled
      nfsv4: disabled
      nfsv41: disabled
      tcp: enabled
      udp: enabled
      vstorage_state: disabled
      <<: *login
  - name: Setup default rules
    na_ontap_export_policy_rule:
      state: present
      policy_name: default
      vserver: "{{ vserver }}"
      client_match: 0.0.0.0/0
      ro_rule: any
      rw_rule: none
      super_user_security: none
      <<: *login

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 6-12, 22, 38, 50, 60.  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.

vars:
 alias_name: &alias_name
  variable: value
  variable: value

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

<<: *alias_name

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.

---
- hosts: localhost
  collections:
    - netapp.ontap
  name: example
  vars_files:
    /absolute/path/to/var_file.yml

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.

hostname: "172.32.0.182"
username: "admin"
password: "netapp123"
vserver: ansibleSVM
address: 172.32.0.183

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.  There documentation can be seen using ansible-doc.  See here for information on documentation in collections.

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 33 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.

$ ansible-playbook vserver.yml --extra-vars “@vars.yml”

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:

$ ansible-playbook vserver.yml --extra-vars “hostname=172.32.0.182, username=admin, password=netapp123, vserver=ansibleSVM, address=172.32.0.183”

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.

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.

Part 1. Install Ansible
Part 2. Understanding Playbooks
Part 3. First Playbook Example
Part 4. Complete Workflow