NSX Ansible Module Update – nsx_manager_syslog

 

 

 

I alluded to this post yesterday on Twitter, and after committing the code early this morning to the upstream repo on GitHub, here it is!

Similar to how the configuration of the user roles in NSX Manager were initially being done using the Ansible URI module, the configuration of the remote syslog server as utilizing the same method. The code originally looked like this:

 43 - name: Set syslog configuration on NSX Manager
 44   uri:
 45     url: "https://{{nsxmanager_spec.host}}/api/1.0/appliance-management/system/syslogservers"
 46     method: PUT
 47     url_username: "{{ nsxmanager_spec.user }}"
 48     url_password: "{{ nsxmanager_spec.password }}"
 49     headers:
 50       Content-Type: "application/json"
 51       Accept: "application/json"
 52     body:
 53       syslogServersList: '[{"syslogServer": "{{ syslog_server }}", "port": "514", "protocol": "UDP"}]'
 54     body_format: json
 55     force_basic_auth: yes
 56     validate_certs: no
 57     use_proxy: no
 58     return_content: yes
 59   tags: nsx_syslog_enable
 60   delegate_to: localhost

This worked and the configuration was updated accordingly. However, I wanted to expand the NSX Ansible module to include this functionality natively. Fortunately, the definition exists within the NSX RAML file and writing a small amount of Python code was a very easy lift.

 5961   /system/syslogserver:
 5962     displayName: systemSyslogServer
 5963     description: |
 5964       Working With Syslog Server
 5965       -----
 5966     get:
 5967       displayName: systemSyslogServerRead
 5968       description: Retrieves only the first syslog server among the servers configured.
 5969       responses:
 5970         200:
 5971           body:
 5972             application/xml:
 5973               example: |
 5974                 <syslogserver>
 5975                   <syslogServer>192.168.110.20</syslogServer>
 5976                   <port>514</port>
 5977                   <protocol>UDP</protocol>
 5978                 </syslogserver>
 5979     put:
 5980       displayName: systemSyslogServerUpdate
 5981       description: Configures one syslog server. If there are syslog server(s) already configured, this API replaces the first one in the list.
 5982       body:
 5983         application/xml:
 5984           example: |
 5985             <syslogserver>
 5986              <syslogServer>name-2</syslogServer>
 5987                 <port>port-2</port>
 5988                 <protocol>protocol-2</protocol>
 5989             </syslogserver>
 5990           schema: systemSyslogServerUpdate
 5991     delete:
 5992       displayName: systemSyslogServerDelete
 5993       description: Deletes all the syslog servers.

The module is now available in the master branch on GitHub.

The module will work with NSX-v versions 6.4 and lower. To leverage the module within an Ansible playbook or role, the following code example can be used:

  1 ---
  2 - hosts: all
  3   connection: local
  4   gather_facts: False
  5 
  6   tasks:
  7     - name: Configure NSX Manager syslog
  8       nsx_manager_syslog:
  9         nsxmanager_spec: "{{ nsxmanager_spec }}"
 10         state: present
 11         syslog_server: "{{ syslog_server }}"
 12         syslog_port: "{{ syslog_port }}"
 13         syslog_protocol: "{{ syslog_protocol }}"
 14       register: nsxv_syslog

It important to note that in NSX-v 6.4, an additional syslog API call was added that supports setting multiple syslog servers within the NSX Manager. The module above, supports the API call that only modifies a single syslog server. I will likely be adding support for the additional API call in the near future, in the meantime this module can be leveraged to configure syslog on your NSX Managers.

Enjoy!

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!

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!

Deploying an SDDC with Ansible

The small effort I started at the end of last year using Ansible to deploy NSX components has snowballed a bit and found its way into a project at work. As we are working to deploy a new HCI architecture internally, one of the efforts we are embarking on is a fully automated, infrastructure-as-code architecture design. There are several components that are working in conjunction with one another to be able to accomplish that task, but the part I am going to talk about today is automation through Ansible.

As many of you have seen, I’ve recently been automating NSX component delivery and configuration using the open source VMware NSX Ansible modules. I’ve been fortunate enough to put my meager coding skills to work and enhance those models this year — adding new capabilities exposed through the API for NSX Edge configuration. In addition to the NSX Ansible modules, there are a multitude of upstream Ansible modules for VMware components. The first step was evaluating what the current upstream modules were capable of performing and putting together a small demo for my colleagues to observe both the power of Ansible and the ease of use.

My initial impressions of Ansible is that it is probably the most user-friendly of the configuration management/automation tools currently available. And for the VMware SDDC components, it appears to be rather robust. I have identified a few holes, but nothing insurmountable — the great thing is if something is exposed via an API, creating an Ansible module to leverage said API is rather simplistic.

The Ansible playbooks are a first step, I really want to convert most of them into Ansible roles. I’ve started committing the code in my Github space. You can download the playbooks and start using them if you’d like.

https://github.com/virtualelephant/vsphere-sddc

I currently have playbooks for creating a datacenter, cluster, adding hosts, configuring several advanced settings on each ESXi host, creating a DVS with port groups and performing a few other configuration tasks. The bit that I want to work out next is deployment of the vCenter server through Ansible. It’s currently a work in progress, but it has been a fun effort thus far.

Enjoy!