Configuration management is a hot topic with our customers. One of the most popular tools is Ansible. Ansible is an open-source automation platform that helps with configuration management, application deployment, and task automation. It allows you to run tasks in sequence and create a chain of events that must happen on several different servers or devices. For example, if you have a group of web servers behind a load balancer, Ansible can upgrade the web servers one at a time. While doing the upgrading, Ansible can remove the current web server from the load balancer and disable it in your monitoring system. After the upgrade, Ansible can reenable the web servers.

What Is NetApp Service Level Manager?

NetApp® Service Level Manager (NSLM) software is a management tool that can help your organization optimize storage operations for predictable service levels, simplifying data management. With this capability, you can define service-level objectives that accelerate the transition to storage-as-a-service offerings and implementation of private clouds.

What Is OnCommand API Services (API-S)?

NetApp OnCommand® API Services (API-S) help IT organizations address today’s complex IT management challenges. Using representational state transfer (REST) APIs, you can integrate disparate software tools to simplify how you manage your on-premises and cloud storage. IT organizations gain a view of the entire infrastructure with a single tool and can continue using their vendor-provided tools as needed to troubleshoot issues.

 

Ansible consists of the following two main components:

  • Playbooks. Playbooks are Ansible’s configuration, deployment, and orchestration language. They can describe a policy you want your remote systems to enforce or a set of steps in a general IT process. A playbook makes use of modules to get a command executed.
  • Modules. Modules (also referred to as “task plug-ins” or “library plug-ins”) do the actual work in Ansible. They are what gets executed in each playbook task. You can also run a single module using the ‘ansible’ command. Each module supports taking arguments. Nearly all modules take ‘key=value’ arguments, space delimited. 

NetApp Modules for Ansible

NetApp has also created, and contributed upstream into Ansible itself, a set of Ansible modules that allow for the management of ONTAP®, SolidFire®, and E-Series storage systems directly. Whereas those modules provide you with a native approach of talking to storage systems, the NSLM- and API-S-based Ansible modulesadvanced RESTful API tools NSLM and API-S. This approach provides the advantages and intelligence of service level–based management through NSLM and heterogeneous platform storage system management through API Services, respectively.

API-S and NSLM Ansible Modules Make Storage Consumption Easy

NetApp has created two types of Ansible modules that enable the consumption of API-S and NSLM APIs natively:

  • Element-based (such as volumes, qtrees, and so on) storage management using OnCommand API Services
  • Service level–based (such as storage service levels and so on) storage consumption using NetApp Service Level Manager

 

The functionality of these modules is to act as an interface between Ansible and either OnCommand API Services or NetApp Service Level Manager. The commands given at the Ansible server through these modules are translated to RESTful API calls to OnCommand API Services or NetApp Service Level Manager.

 

These modules are publicly available for use on our NetApp GitHub page:

They can be downloaded on your Ansible server. (Note: These modules must be downloaded from the GitHub page; they are not part of upstream Ansible libraries.) After these modules are configured, they can be used in custom-written playbooks according to specific use cases or requirements.

To help you understand how to use the two types of Ansible module, let’s consider an example of NFS share provisioning and mounting the NFS share to an RHEL host, illustrated in the following playbook.

Sample Playbook Using the Preceding Modules

Fetch any storage VM details and find the key:

- hosts: <<host-ip>>

  tasks:

    - name: Get all Storage VMs (e.g. filter Storage VMs with name “<<your-svm-name-here>>”)

      StorageVMModule:

host=<<nslm or apis server-ip>>

port=8443

user=<<admin>>

password=<<password>>

action=get

name=<<your-svm-name-here>>

      register: jsonResultforSVMs



    - name: print the SVM key

      debug: msg="{{ jsonResultforSVMs.meta.result.records[0].key}}"

Fetch any storage service level details and fetch the key:

    - hosts: <<host-ip>>

  tasks:

- name: Get all Storage Service Levels (e.g. filter SSLs with name ‘Extreme Performance’)

      StorageServiceLevelModule:

host=<<nslm or apis server-ip>>

port=8443 user=<<admin>>

password=<<password>>

action=get

name='Extreme Performance'

      register: jsonResultforSSLs



    - name: print the SSL key

      debug: msg="{{ jsonResultforSSLs.meta.result.records[0].key}}"

Provision a file share:

    - hosts: <<host-ip>>

  tasks:

- name: Provision File Share (use SSL key and SVM key derived from above tasks)

      FileShareModule:

                host=<<nslm or apis server-ip>>

                port=8443

                user=<<admin>>

                password=<<password>>

                action=post

                name=ansibleFileShare1

                size=204803008

                storage_vm_key="{{ jsonResultforSVMs.meta.result.records[0].key}}"

                storage_service_level_key="{{ jsonResultforSSLs.meta.result.records[0].key}}"

      register : jsonResult



    - name: print the job key

      debug : msg="{{ jsonResult.meta.result.records[0].key}}"

Fetch any job details:

    - hosts: <<host-ip>>

  tasks:

- name: loop for status (wait for the job to complete)

      JobScheduleModule:

host=<<nslm or apis server-ip>>

port=8443

user=<<admin>>

password=<<password>>

action=get

key={{ jsonResult.meta.result.records[0].key}}

      register : jsonResult

      until:  (jsonResult.meta.result.records[0].status == "COMPLETED") or (jsonResult.meta.result.records[0].status == "FAILED")

      retries: 5

      delay: 10

For a more detailed look, here is an end-to-end playbook example.

 

From the preceding code snippets, we can identify that the playbook uses existing modules such as StorageVMModule, JobScheduleModule, and so on accordingly, as indicated by boldface text.

Get More Information

So, go ahead and give it a try and let us know what you think about these modules. For more information and continuous updates, visit and star the GitHub projects described in this blog post. Also, if you encounter any issues or problems while using these modules, raise an issue at the GitHub page itself.

Akash Shukla

Akash is the Technical Marketing Engineer for storage automation products OnCommand API Services and OnCommand Workflow Automation. He also develops DevOps and other 3rd party automation and integration solutions with OnCommand Manageability automation products. He shares a passion for coding and open source technologies.