Why Ansible and ONTAP Deserve a Look for Storage
Ansible is an open source software provisioning, configuration management and application-deployment tool. Years ago, Ansible (owned by Red Hat) partnered with NetApp to create open source modules to use with NetApp systems, especially with its flagship operating system ONTAP. In the time since that partnership began, NetApp has created over 75 modules free of charge and infrastructure management has never been easier.
Sometimes, however, things can get complicated if you’re running multiple modules individually rather than grouped together in what’s called a playbook. As the name implies, a playbook is how code executes modules in a coordinated fashion. Generally, the makers of the modules are “responsible” for building playbooks, but those vendors might not have the time or inclination to create their own playbooks.
Fortunately, Ansible has a solution that can ease this issue, called “Roles.” An Ansible Role is a collection of playbooks, templates and variables that can be hard coded by the end user. In this post, we discuss one of the Ansible Roles that have been created to make the management of ONTAP easier.
Cluster Configuration
With the release of Ansible 2.8, changes to some modules allow for optimized Role creation and are merged on GitHub for Ansible. In this Role, here is what is possible:
- Apply license codes.
- Assign disk ownership.
- Create aggregates.
- Setup SNMP.
- Setup DNS.
- Setup a MOTD login message.
- Setup NTP.
- Modify port MTU.
- Create interface group.
- Modify broadcast domains.
- Create VLANs.
- Create Intercluster LIFS for SnapMirror.
NetApp keeps all Roles we produce on GitHub. Working with the NetApp Roles is simple. To prepare your Ansible system for Roles, you need to be sure you have an /etc/ansible directory:
|
1 |
# mkdir /etc/ansible |
Next, using Git, download the modules to a content folder in the /etc/ansible directory.
|
1 |
# git clone <a href="https://github.com/netapp/ansible.git">https://github.com/netapp/ansible.git</a> /etc/ansible/content |
These commands will create a content folder in /etc/ansible and allow for access when Roles are updated: Roles are released or are updated:
|
1 2 |
# cd /etc/ansible/content # git pull |
There is still one last step to make using these Roles in playbooks stress-free. You first create or modify a configuration file for Ansible in /etc/ansible. You will use that file to tell Ansible where these Roles are so that you can use their short names in playbooks.
|
1 |
# vi /etc/ansible/ansible.cfg |
Now that you are finished with the setup, using this Role to configure an ONTAP cluster is easy.
The first thing you will need is a playbook to call this Role:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
- hosts: localhost gather_facts: no vars: input: &input hostname: "{{ netapp_hostname }}" username: "{{ netapp_username }}" password: "{{ netapp_password }}" file: globals.yml vars_files: - "{{ file }}" tasks: - name: Get Ontapi version na_ontap_gather_facts: state: info <<: *input https: true ontapi: 32 validate_certs: false - import_Role: name: na_ontap_cluster_config vars: <<: *input |
The playbook will either read in a file in the same directory called globals.yml or you can specify an extra-vars for file to specify on a per-run basis which file to use. The playbook also uses the gather_facts module to look up the version of ONTAP so that all the tasks run in that version of the API calls for the most efficiency. The tasks in this Role require the information from that gather_facts module, so it cannot be excluded. All the information for what configuration settings you want to use are read from the passed in the file. You can have a single file to read in per cluster, or you could have one file that has the defaults — such as MOTD, DNS, NTP and SNMP — and the file for a cluster, simply by specifying both variable files in the vars_files section.
This is just one of the many Roles available to condense the workloads into a manageable format. There are always new Roles created, such as Vservers, NAS and SAN volumes (shares, exports, LUNs) and a Role for creating SnapMirror relationships, including verifying peer settings. This highlights the value of NetApp engaging and supporting in an open source community. NetApp wants the process of using ONTAP simplified to the point that it would be considered difficult to use anything else.
This dedication is constantly at play in the NetApp Slack Workspace. Join other developers working with Ansible in the #configurationmgmt channel. The freedom of Simplicity, Automation and Orchestration is available and closer than you might think.