NSX Ansible Module Update – nsx_manager_roles

As the previous post discussed, using the API directly through Ansible was an adequate initial step to configuring a users role within the NSX Manager. The next logical step was to include this functionality directly inside the upstream NSX Ansible module.

After an initial commit yesterday afternoon, I received some feedback from the community and posted a new update to the module today that is better inline with Ansible best practices and idempotency.

The module is now available in the masterbranch on GitHub.

The module can be used inside an Ansible role or playbook with the following code:

  1 ---
  2 - hosts: all
  3   connection: local
  4   gather_facts: False
  5 
  6   tasks:
  7     - name: Configure NSX Manager roles
  8       nsx_manager_roles:
  9         nsxmanager_spec: "{{ nsxmanager_spec }}"
 10         state: present
 11         name: "{{ nsx_uid }}"
 12         is_group: true
 13         role_type: "{{ nsx_role }}"
 14       register: add_nsx_role

The Ansible task can specify a state of present to add a new user and assign a role, modify to change the role of an existing user or group, and absent to remove a user or group.

If you run into an issues using the module, please reach out to me over Twitter or comment directly in the Issues section on GitHub for NSX Ansible.

Enjoy!

NSX Roles Automation through Ansible

This is a bit of a quick hit.

Yesterday, while working with Ansible to fully deploy and configure an NSX-v Manager, we worked out a method to add a user or group of users and assign the appropriate role. The current NSX Ansible module does not support this functionality, so the role we are executing relies on the URI module.

 64 - name: Set NSX Permissions
 65   uri:
 66     url: "https://{{ nsxmanager_spec.host }}/api/2.0/services/usermgmt/role/global_admins@virtualelephant.com?isGroup=true"
 67     method: POST
 68     url_username: "{{ nsxmanager_spec.user }}"
 69     url_password: "{{ nsxmanager_spec.password }}"
 70     headers:
 71       Content-Type: "application/xml"
 72       Accept: "application/xml"
 73     body: "<accessControlEntry><role>enterprise_admin</role></accessControlEntry>"
 74     body_format: raw
 75     force_basic_auth: yes
 76     validate_certs: no
 77     use_proxy: no
 78     return_content: yes
 79     status_code: 204
 80   tags: nsx_permissions
 81   delegate_to: localhost

The API call does not return a typical 200 status if the call was successful, so the task above specifies that Ansible should be looking for a 204 status.

I am currently working on adding this functionality to the NSX Ansible module published on GitHub. Time (and testing) allowing, the code will be available in the coming days.

Enjoy!

VMworld US 2018 – Session and Schedule

With the VMworld US 2018 conference set to start in just over a month, my schedule is beginning to take shape. 2018 will be my 5th trip to the US show and I am extremely excited to be presenting again on several different stages in Las Vegas!

Sunday – TAM Day table from 4:15PM -5PM

Come find me to talk about the full vSphere SDDC, including NSX-v, NSX-T, vSphere, vCloud Director and/or the VCDX certification.

Monday – VMTN Lounge from 1PM – 1:30PM

Session ID: CODE5542U – Enhancing the SDDC with Ansible

New engineers are often unsure how to contribute to an Open Source project and timid when it is time to make their first merge request. Drawing insight from the recent Ansible automation efforts within the VMware Private Cloud team, learn how to identify areas within an Open Source project where you can contribute using a real-world use-case. In this session, we will walk through the open source Ansible VMware modules leveraged to fully automate the deployment of the software-defined datacenter, including vSphere, vSAN and NSX components. We’ll dive into how gaps in the current Ansible modules were identified and how our engineers were able to begin writing additional functionality and contributing it upstream. The presentation will also highlight how improvements to our own VMware Open Source projects on GitHub can benefit and be leveraged by our customers.

Tuesday – experts bar from 11:3oAM – 1:30PM

Come find me to talk about the full vSphere SDDC, including NSX-v, NSX-T, vSphere, PKS and/or the VCDX certification.

Tuesday – solutions exchange theatre 3:30pm – 4PM

Come learn about how VMware utilizes multiple public cloud providers, in addition to our on-premise clouds, to deliver a memorable VMworld Hands-on-Lab experience each year! I will go over the VCDX methodologies and how they were leveraged to design the Hands-on-Lab architecture.

Tuesday – meet the experts @ solutions exchange theatre from 3:30pm – 4PM

Come find me to talk about the full vSphere stack, including NSX-v, NSX-T, vSphere, PKS and/or the VCDX certification.

thursday – Transformers: How vmware IT transitioned to a services-based organization from 10:30AM – 11:30AM

Session ID: LDT1515PU

Hot on the heels of the digital transformation process sweeping across IT organizations worldwide, the VMware private cloud architects will discuss how they are leveraging their operational experience to propel VMware IT into a services-based organization. As VMware IT has learned, the digital transformation process is less about the technologies adopted and more about the people involved. In order to drive true adoption, the digital transformation starts with strong leadership, but also requires engagement from those closest to the consumers. Come discover how to drive your organization’s digital transformation initiatives and gain true adoption from a technical practitioner’s perspective. Challenges and lessons learned will also be covered.

Ansible RabbitMQ Playbooks

I am working on an AMQP Message Broker service architecture, using RabbitMQ, at work right now. As part of the design work, I have spent a bit of time in my vSphere lab standing up the cluster to work out all the configuration, RBAC, policies and other various settings that will be required by the solution. If you haven’t been able to tell lately, my automation tool of choice is Ansible for all the things — I just cannot get enough of it!

Once again, Ansible did not let me down and provides a set of built-in modules for managing RabbitMQ. I found several examples of using the modules to configure a RabbitMQ node and based the work I’ve done off of those. The reason I wrote my own, rather than just git cloning someone else’s work was so that I can write the playbooks (and eventually roles) based on the service architecture specifications I am documenting for the work project.

I have created a new project space on GitHub to host the RabbitMQ playbooks and you are welcome to clone or fork the code based on your needs.

There are currently two playbooks — one for deploying an Ubuntu template into a vSphere environment, one for installing and configuring RabbitMQ on the deployed nodes. I kept the two playbooks separate so that if you want to use install RabbitMQ on a bare-metal or AWS environment, the second playbook can be used as a standalone. If you are choosing to install RabbitMQ in a vSphere environment, the create_vms.yml playbook can be used.

The rabbitmq.yml Ansible playbook will read in a set of environment variables from rabbitmq-vars.yml and then go through the installation steps. I use official repositories for all of the RabbitMQ and Erlang packages.

Note: If you are not using the 16.04 Xenial release, you can change the playbook to use the distribution of Ubuntu you are using inside your environment. I have been sticking with Ubuntu 16.04 LTS mostly because the open-vm-tools package fully support dynamic configuration of the network interfaces through Ansible. If/when 17.10 or 18.04 fully support this configuration through Ansible, I will upgrade my template.

The first part of the playbook adds the official repositories for RabbitMQ and Erlang, then performs the installation of the RabbitMQ package on the hosts.

The next part is a good example of how to use the built-in RabbitMQ modules Ansible includes as part of the core distribution. The playbook starts the plugins needed for RabbitMQ, adds a new administrator user and removes the default RabbitMQ user.

As I finalize the AMQP Message Broker service architecture, the Ansible playbooks will more fully represent the specifications within the documentation. I hope to publicize the service architecture when it is complete in the coming week.

Enjoy!

Backup vCenter and NSX to AWS S3

As I go deeper into the Ansible rabbit-hole, I am beginning to look for ways to manage upgrade operations through Ansible playbooks. As part of that journey, I wanted to begin backing up my VCSA and NSX-v VM appliances using their built-in methods prior to executing playbooks to perform the upgrades. Both appliances allow FTP, SFTP or SCP connections through their management interfaces for backing up the configuration data — all that is needed is an endpoint.

I wondered if it would be possible to backup these items to S3 using my AWS account. A quick search through my AWS portal showed me that I could use the AWS Storage Gateway, setup a S3 bucket for backups and mount the partition on a Linux VM for the vSphere appliances to use as an endpoint. With minimal effort, I was able to configure both appliances to backup to the local Linux VM and see that data replicated into S3 in a matter of minutes.

Fortunately, AWS has outstanding documentation for deploying the Storage Gateway within a vSphere environment (here). Once the Storage Gateway is deployed, the S3 bucket is created and the file share is created you can mount it on a Linux VM.

linux-vm$ mount -t nfs -o nolock 10.180.138.20:/usa1-2-lab-backups /opt
linux-vm$ mkdir -p /opt/vcsa
linux-vm$ mkdir -p /opt/nsxv

I created a separate backup location on the NFS mount point to the Storage Gateway — one for the VCSA and one for the NSX-v. At this point, it just a matter of configuring the two appliances to use the endpoint.

For the VCSA, log into port 5480 over HTTPS and select the Backup option on the left-hand menu.

The above screenshot shows how to configure the backup schedule and then you can perform a backup job using those details manually.

Similiary, the NSX-v Manager has a Backup and Restore are inside its management interface where you can configure the endpoint. NSX-v only supports FTP or SFTP today, but using SFTP I was able to use the endpoint.

Once the backup location is configured, you can execute a backup job through the admin interface.

From there it was just a matter of verifying the data was being sent and replicated to the S3 bucket I created in AWS.

That is all there is to it! Backups of the appliance data to an AWS S3 bucket using the Storage Gateway is nice and easy. Now I can begin working on the Ansible playbooks to upgrade the VCSA through the API, knowing the data is backed up to the cloud!

Enjoy!