NSX-T and Ansible – An Overview

I spent the last few blog posts covering the basics of the Policy API introduced in NSX-T 2.4. I will be back to that topic soon with more examples, but for now, I would instead move to a different tool that I have been heavily leveraging when automating NSX-T, Ansible. VMware R&D has provided us with some great Ansible modules for NSX-T that makes automating the initial deployment of NSX-T a breeze. One of the things I discovered is that sticking to a single tool when automating NSX-T is not a wise choice. Some tools may excel at a specific task but may be cumbersome to use or altogether ineffective at others. We have gone through the benefits and capabilities of the Policy API, but the Policy API does not cover the initial fabric stand up: transport node creation, uplink profiles, edge deployment, etc.. For the initial fabric initialization, we need to revert back to the Management Plane API or a tool that abstract it and make it easier to consume. For this use case, I believe the best tool is Ansible.

The diagram below presents my current workflow when automating NSX-T. Ansible is used for the initial environment creation, then intent-based tools such as the Policy API or Terraform are leveraged to create network topologies and security policies. I tend to have Ansible trigger the Policy API or Terraform so that I can have a single playbook perform the configuration end to end, but it is a matter of personal preference. The key idea here is: use the best tool for the task at hand, in this case, Ansible for the fabric preparation, and the Policy API (or Terraform) for the logical topologies.

What is Ansible?

I by no mean want to replace the excellent Ansible Documentation or other resources that cover Ansible at length. I just want to emphasize the fundamental Ansible properties and befits in the context of automating NSX-T. They are:

• Ansible is a configuration management Tool, deployment Tool, and Ad-hoc task execution tool all in one.
• It follows a push approach
• Ansible is Agentless
• Ansible accepts YAML style configurations
• Idempotency
• Ansible runs tasks in a sequential manner

Especially notable characteristics are idempotency and the fact that tasks are executed in a sequential manner based on an order specified by the administrator. Ansible shares its idempotency property with intent base tools such as the Policy API and Terraform. It means that before trying to perform a change to the system, it will check the system status and complete the change only if the change is required to achieve the desired state. For example, if the administrator defines the creation of a logical switch as part f the YAML specification, Ansible will check if that logical switch is already present before attempting to create it. Checking the status of the system and evaluate if a change is required can be challenging for a stateless tool such as Ansible that does do not rely on the Policy Engine Database, or a Terraform state file. Ansible idempotency is going to be as strong as the way the specific ansible modules have been written. For example,  the logical switch module will check if an existing logical switch with the same name already exists in the NSX-T configuration. If it exists, any setting in the YAML specification that differs from the system status will not be updated (i.e., teaming policy, or replication mode), because the module does not look into those details when assessing the current configuration.

The fact that Ansible runs tasks in a sequential manner means that the administrators need to be aware of the dependencies between the different objects and plan on creating them in the correct order. It means I cannot specify a logical switch before the corresponding transport zone or a load balancer configuration before a T1 router. When using the intent-based tools, those dependencies are resolved by the tools themselves.

So, after all of this, why do I still use Ansible for infrastructure preparation, and I do not use the Policy API or Terraform. The short answer is: it is not possible to use the Policy API or Terraform for infrastructure preparation at the moment. And Ansible does a pretty good job at it once you understand its limitations and arrange your workflow around them. I mean, notepad++ has been my only automation tool for 10 years when configuring routers, I think I can live with Ansible.

How does Ansible work with NSX-T?

When you look at Ansible tutorials and examples, they will most likely be in the context of managing a plethora of servers.

In this scenario, this is what happens:

• Ansible connect to the servers and pushed small programs called modules
• Ansible remotely execute those modules, by default over SSH, and then remove them from the server
• The library of modules only resides on the Ansible Management Node
• The inventory file provides the list of servers where the modules have to run
• A playbook file includes the list of modules to be run on each server

When we use Ansible to automate NSX-T things are more straightforward.

• NSX-T Ansible modules are executed locally on the Management Node
• The only host required in the inventory is localhost
• No SSH required. Connection variable is set to local
• The NSX-T modules generate REST API calls from the Ansible Management Node to the NSX-T Manager

The simpler solution of the NSX-T scenario means that we do not need to become Ansible experts to effectively leverage Ansible with NSX-T. Only the most basic functionalities plus some tricks in managing JSON data structures are actually required. I will review them in future posts.

 

Advertisement