Undeniably, Ansible helps you spend less time managing the configuration of your datacenter by grouping tasks together into a single playbook, configurations can be deployed across a variety of systems simply and easily. NetApp’s new and improved Ansible modules for ONTAP allow configuration management and automation of all ONTAP9 systems using Ansible.
NetApp and Ansible make it easier than ever before to create end-to-end workflows covering the entire process of provisioning and consuming storage. Complete application environments can be created and managed from a single playbook. In this example a complete workflow for creating and presenting an NFS export from an ONTAP system to a host is presented.
There are six tasks in this playbook.
- Create or verify and export policy
- Create or verify export policy rule
- Create or verify a volume, which is then junctioned and accessible according to the rules set in the export policy
- Create or verify the host fstabline to target hosts fstab file for new export
- Create or verify directory for mount location
- Mount or verify export volume on target host
--- - hosts: localhost name: Setup ONTAP vars: hostname: "172.32.0.182" username: "admin" volname: ansibleVolume vserver: vserver1 aggr: aggr1 policy: ansiblePolicy state: present vars_prompt: - name: "password" prompt: "Password:" tasks: - name: Create Policy na_ontap_export_policy: state: "{{ state }}" name: "{{ policy }}" vserver: "{{ vserver }}" hostname: "{{ hostname }}" username: "{{ username }}" password: "{{ password }}" - name: Setup rules na_ontap_export_policy_rule: state: "{{ state }}" policy_name: "{{ policy }}" vserver: "{{ vserver }}" client_match: 0.0.0.0/0 ro_rule: sys rw_rule: sys super_user_security: sys hostname: "{{ hostname }}" username: "{{ username }}" password: "{{ password }}" - name: Create volume na_ontap_volume: state: "{{ state }}" name: "{{ volname }}" aggregate_name: "{{ aggr }}" size: 1 size_unit: gb policy: "{{ policy }}" junction_path: "/{{ volname }}" space_guarantee: "none" vserver: "{{ vserver }}" hostname: "{{ hostname }}" username: "{{ username }}" password: "{{ password }}" - hosts: client tasks: - name: Update fstab file lineinfile: path: /etc/fstab line: "172.32.0.184:/{{ volname }} /mnt/ontap nfs defaults 0 0" - name: Verify mount directory exists file: path: /mnt/ontap state: directory - name: Mount nfs export mount: state: "{{ state }}" path: /mnt/ontap src: "172.32.0.184:/{{ volname }}" fstype: nfs
If you’re curious about all of the options available for the modules used in this playbook, links to the documentation are below:
Documentation for the non-NetApp modules used can be found here.
Ansible makes automation easy
If you want to start using the ONTAP modules, or just learn more about them, instructions for adding the ONTAP modules to an existing Ansible set can be found here and full documentation for the ONTAP modules is here.
Try using the Ansible playbooks to create and consume storage for your application! Or, create storage which implements your best practices: naming conventions, options, etc.
Be sure to check back at netapp.io often to see other examples of our Ansible modules, and if you are not on our Slack channel be sure to get an invite and join us to discuss configuration management, along with all our other developer projects.
I haven’t tested this yet, but what would happen if you ran the na_ontap_volume task and a volume was created, then an administrator increased the size of the volume in ONTAP, and then the playbook was run again.
Would ansible try and reduce the size of the flexvol back to what is specified in the playbook?
Yes. Ansible Playbooks are procedural but the modules are Declarative. They work to get a matching end state. So if the size: entry doesn’t match what the volume is, it will be adjusted to match. This is also how you can use the modules to resize volumes.