In March 2022 Nutanix released the first generally available (GA) version of our Ansible module. This release allowed our customers and partners to easily integrate the Nutanix Cloud Platform configurations and changes into deployment workflows. For example, the March 2022 release provided access to the following Nutanix Cloud Platform entities (and others, that we’ll talk about shortly):
- VPCs
- Subnets
- Floating IPs
At the simplest level, it is easy to see how CRUD operations can be carried out against this small collection of entities alone, allowing workflow-based configuration at any stage of deployment.
Today’s article will show how to get started with the Nutanix Ansible module.
Installation
The steps in this document somewhat mirror the installation documentation from the Github repository, but with the addition of Ansible Vault. Please follow along with this article if you’d like start from scratch and end up with a basic working Ansible configuration for use with the Nutanix Ansible module. If you’d like to just download the complete results of this process, you may do so by cloning the demo repository.
These steps have been written for use with almost any Linux environment, but should work on OS X with very little modification. Some changes may be required for use in a Windows environment.
Prerequisites
To use these steps, you’ll need the following software installed:
- Git, to clone the Nutanix Ansible module from GitHub
- Ansible, to manage and run our Ansible playbook and manage our encrypted Ansible Vault data. Note: We will be working with a local configuration only; there’s no need to setup a dedicated control node in order to follow these steps. Ansible version 2.13.1 was used for this article.
- Once Ansible is installed, verify the ansible-galaxy, ansible-vault and ansible-playbook commands are available.
- A connection to a Nutanix Cloud Platform cluster. AOS version 6.0.2.4 was used for this article.
- A connection to a Nutanix Prism Central instance. Version pc.2022.1 was used for this article.
Installing the Nutanix Ansible Module
In July 2022 Nutanix released v1.4.0 of our Nutanix Ansible module; this is the version we’ll use throughout this article. The commands below were used to download, build and install the Nutanix Ansible module.
# enter home directorycd ~# optional, but recommended: change to an existing working directory for our projectscd Data/solutions/nutanix# download the Nutanix Ansible sourcegit clone https://github.com/nutanix/nutanix.ansible.gitcd nutanix.ansiblegit checkout v1.4.0 -b v1.4.0# optional, but recommended: create and activate a python virtual environmentpython -m venv venv. venv/bin/activate# build and install the collectionansible-galaxy collection buildansible-galaxy collection install nutanix-ncp-1.4.0.tar.gzThe screenshot below shows the above process.
Demo Configuration
Now that we have Ansible and the Nutanix Ansible module installed, we can continue with the build of our demo project.
Note: Ansible Vault has been used to work with local files in this demo. If you have an alternative and preferred Ansible Vault configuration you may wish to alter these steps to suit your environment.
The steps below assume your terminal’s current directory is still the same directory as the module’s downloaded source. However, you may wish to complete these steps in a dedicated directory.
- Create and enter a subdirectory for the demo files
mkdir democd demo- Create Ansible Vault password file
# change the command below so that your preferred password is usedecho 'your_password_here' > .vault_pass# ensure the .vault_pass file is never added to source controlecho .vault_pass > .gitignore- Create Ansible hosts file named hosts. This demo uses a host group named dev, but you may name the group anything you like. The hosts file contents should be as follows:
[dev]localhost ansible_connection=local- Create the Ansible configuration file named ansible.cfg. The contents of this file should be as follows:
[defaults]inventory = ./hostsvault_password_file = ./.vault_pass- Create a directory structure for our demo’s Ansible variables.
mkdir -p ./group_vars/dev- Create the Ansible variables file for the public variables. Sensitive information e.g. credentials should not be stored here. For this project, this file is group_vars/dev/vars and should contain the following; change your_prism_central_ip_address_here to match your environment:
---# public datapc_ip: your_prism_central_ip_address_here- Use Ansible Vault to create the encrypted file containing our sensitive data. For this demo, this encrypted file will contain the username and password for connection to Prism Central.
ansible-vault create group_vars/dev- The above command will launch your chosen editor which can then be used to set the contents of the vault file as follows (change the variable values as necessary):
---# sensitive datavault_pc_username: your_prism_central_username_herevault_pc_password: your_prism_central_password_hereViewing the contents of the vault file after saving will show encrypted contents only. If you need to edit the variable values later, use the following command:
ansible-vault edit group_vars/dev/vaultDemo Playbooks
With the Nutanix Ansible module installed and our demo environment configured, we can start writing Ansible playbooks that utilise the new module.
Test Playbook #1: Get Clusters Info
The playbook below is a modified version of clusters_info.yml provided with the source from GitHub, but with the following changes:
- The playbook makes use of the encrypted credentials in group_vars/dev/vault
- An additional task has been added that shows the output of our Ansible tasks
- To continue, create a new file named clusters_info.yml and add the following contents to the file:
---- name: Clusters_Info playbook hosts: localhost gather_facts: false collections: - nutanix.ncp module_defaults: group/nutanix.ncp.ntnx: nutanix_host: "{{ pc_ip }}" nutanix_username: "{{ vault_pc_username }}" nutanix_password: "{{ vault_pc_password }}" validate_certs: false tasks: - name: test getting all clusters ntnx_clusters_info: register: clusters - name: test getting particular cluster using uuid ntnx_clusters_info: cluster_uuid: '{{ clusters.response.entities[0].metadata.uuid }}' register: result - name: List clusters using length, offset, sort order and priority sort attribute ntnx_clusters_info: length: 2 offset: 0 sort_order: "ASCENDING" sort_attribute: "name" register: result - name: Print cluster list ansible.builtin.debug: var: result when: result is definedWith the first test playbook created, it can be tested using our entire Ansible configuration.
ansible-playbook clusters_info.ymlIf the connection to Prism Central was successful, the output of the clusters list module will be displayed. This output can be extensive but will end with something similar to the screenshot shown below.
Test Playbook #2: Create Prism Central Categories
The next demo playbook is again a modified version of one provided in the official GitHub repository. This time we are creating Prism Central Categories; please see the official categories documentation for detailed information.
- Create a new file named create_categories.yml and set the file contents as follows:
---- name: Create Prism Central categories playbook hosts: localhost gather_facts: false collections: - nutanix.ncp module_defaults: group/nutanix.ncp.ntnx: nutanix_host: "{{ pc_ip }}" nutanix_username: "{{ vault_pc_username }}" nutanix_password: "{{ vault_pc_password }}" validate_certs: false tasks: - name: task to create category keys ntnx_categories: state: "present" name: "nutanix_ansible" desc: "Category key created with Nutanix Ansible module" register: create_key - name: task to create category values ntnx_categories: state: "present" name: "nutanix_ansible" values: - "registered" - "unregistered" register: create_values - name: Print result ansible.builtin.debug: var: create_values when: create_values is defined- If the connection to Prism Central was successful, the output of creating Prism Central categories will be displayed. The indicator of success during this test, assuming a matching category doesn’t already exist, is the indication that 2 changes were made. See the screenshot for an example.
Likewise, if we were to run the same playbook again, the configuration management capabilities of Ansible would ensure no changes were made. This is due to the fact that the nominated category values and keys already exist:
Wrapping Up
Using the Nutanix Ansible module, it’s easy to see how quickly a required configuration can be deployed. The two examples shown here are just a few of the available entities that can be managed using this module; for full information, please see the official Nutanix Ansible GitHub repository.
A complete and downloadable copy of the Ansible configuration used throughout this article can be downloaded from the NutanixDev GitHub repository.
Thanks for reading and have a great day. 🙂
Related Resources
- Nutanix Ansible on GitHub
- Nutanix Developer Portal
- Getting started with the Nutanix Terraform provider
