Ansible? Playbooks? Modules? Confused? Don’t worry, we’ve all been there…
Alright, let’s start off with the basics. What is Ansible? In a nutshell, Ansible is an open-source IT automation tool that can help you simplify complex configuration, management, and application deployment.
There are quite a few good reasons for Ansible’s rise in popularity, such as its agentless architecture and easy-to-use (and learn) approach. Here’s the official quick start guide: https://www.ansible.com/get-started. Now if and when you’re ready to take things to the next level, there’s also a paid version called Ansible Tower – but that’s outside the scope of this blog post.
Ok so we’re now going to try and define some basic Ansible concepts. First of all, a single action or activity that you want to execute through Ansible, is called a ‘Task’. A collection of one or more tasks makes a ‘Play’, and a collection of plays makes a ‘Playbook’!
So how does Ansible know how to perform a specific task (or a group of tasks) in a Playbook? For example, if you wanted to create a Playbook with tasks for creating a user, setting up the volumes, etc., Ansible needs a way to be able to communicate with your NetApp storage, right?
That’s where Ansible modules come into picture. Think of Ansible modules as the drivers that enable Ansible to communicate with the target environments. Ansible comes with a library of modules. For example, there’s a ‘service’ module, a ‘yum’ module, and if you wanted to create volumes on NetApp ONTAP, you’d use the ‘ontap_volume’ module.
So for example, you would use the ‘service’ module if you wanted to ensure that the Apache service was running on a remote server. Here’s what part of your Playbook would look like:
tasks: - name: Ensure Apache is running service: name=httpd state=started
In the above example, we define the action through the ‘state’ variable. Every module comes with its own set of supported parameters and options that you need to specify in your Playbook. You can read a module’s associated documentation by running the “ansible-doc MODULE_NAME” command.
Now if you’re still confused between modules and playbooks, here’s how I usually describe the difference – think of the Playbook as the piece where you define WHAT your target environment should look like, and then modules help take care of HOW Ansible will execute the necessary changes.
So to reiterate, each module implements specific functionalities, and we use these functionalities in tasks of a Playbook.
Writing your Playbook:
Ok so once you have installed Ansible on your Client (remember, since Ansible is agentless you don’t need to configure anything on the server!), you will need to add the hosts that you want to manage to your ‘/etc/ansible/hosts/’ file. For example, if you wanted to manage a CDOT cluster with 3 nodes, your hosts file would perhaps look like:
[my_cluster} nodeA nodeB nodeC
An Ansible Playbook is a YAML file, and is pretty easy to understand and write.
Let’s assume that you want to write a Playbook to create new volumes on all 3 nodes of your cluster. Here’s how you can do it.
# Create your yml file vi my_ansible_playbook.yml # Define your target hosts --- hosts: my_cluster # Target host(s) tasks: - name: Create a new volume # Name of the task na_cdot_volume: # Name of the module state: present # State of the volume name: ansibleVolume # Name of the volume ... # Other parameters
As you’ll notice, we have defined 1 task in the ‘tasks’ section, and this task is utilizing the ‘na_cdot_volume ’ module. We also added other parameters to configure this task as required.
Now let’s say you want to add a second task of creating a 5 GB LUN on this volume that we just created. Your yml file may look like:
--- hosts: my_cluster # Target host(s) tasks: - name: Create a new volume # Name of the task na_cdot_volume: # Name of the module state: present # State of the volume name: ansibleVolume # Name of the volume ... # Other parameters - name: Create a new LUN # Name of the task na_cdot_lun: # Name of the module state: present # State of the LUN flexvol_name: ansibleVolume # Name of the FlexVol vserver: ansibleVServer # Name of the SVM size: 5 # Size of the LUN size_unit: gb # Size of the LUN ... # Other parameters
That’s it! All that you need to do now is run your Playbook!
Now if you run the same Playbook again, you’ll notice ‘changed=0’ in your console output which indicates that no changes had to be made to get the target environment to the desired state.
Now that you know what Playbooks and Modules are, go ahead and think of things you can automate! In a future blog post, I’ll also talk about how you can write your own modules, if one doesn’t already exist for a functionality that you seek.
If you’re interested in looking at some sample Playbooks for the NetApp modules, you can find them here: https://goo.gl/UhAFj2.