Ansible SDDC Demo Video

Following on the heels of the release of the VMware SDDC Ansible roles inside the Virtual Elephant GitHub space, here is a recording of several of the roles being leveraged to deploy and configure a set of ESXi nodes (advanced settings, DVS and VMkernel configuration) within a vCenter cluster, deploy an NSX-v Manager through ovftool and the deployment of the NSX-v Controllers.

To avoid any copyright issues, there is no sound or music playing in the background. The video was recorded and then time-lapsed to make it a quick-view of the deployment. Deploying the NSX-v Manager and Controllers were the longest-running tasks, but in it’s raw form the demo video was just under 30 minutes to perform all of the tasks you see in the video.

Leveraging Ansible can greatly enhance and reduce the time it takes a vSphere Administrator to deploy a VMware SDDC environment!

Enjoy.

Ansible Roles for VMware SDDC Deployments

I’ve been excited for weeks now as I prepped for VMworld 2018 in Las Vegas and anticipating being able to talk more about leveraging Ansible to deploy and operate a VMware SDDC environment. As you can tell from my recent posts, I am heavily involved in automation using Ansible, both within my side projects and as a practicing architect at VMware. As an internal team, we are working hard to improve and enhance several of the upstream Ansible modules, and I hope to be able to share those externally in the future as they are contributed back.

In my spare time, I’ve been working the lab to provide a set of Ansible roles that anyone can leverage to configure ESXi hosts, deploy and configure a vCenter Server Appliance (VCSA), and deploy and configure NSX-v within their environments. I am happy to announce the initial release of these roles in the Virtual Elephant GitHub space.

The following roles have been published within the space and are operational:

  • esxi-adv-settings – Configure advanced ESXi settings on an ESXi node
  • esxi-host-config – Configure DNS, hostname and NTP settings on an ESXi node
  • esxi-services – Configure ESXi services on an ESXi node
  • esxi-vmk-interfaces – Create/delete VMkernel interfaces on an ESXi node
  • nsxv-cluster-prep – Prepare vCenter cluster for NSX-v
  • nsxv-controllers – Create/delete NSX-v controllers
  • nsxv-license – Assign NSX-v license
  • nsxv-logical-switch – Create/delete NSX-v logical switch
  • nsxv-manager-config – Configure NSX-v Manager
  • nsxv-manager-deploy – Deploy NSX-v Manager OVA to vCenter Server
  • nsxv-manager-roles – Configure NSX-v Manager user roles
  • nsxv-transport-zone – Create/delete NSX-v transport zone
  • vcenter-add-hosts – Add or remove ESXi nodes to vCenter Server
  • vcenter-cluster – Create/delete/modify vCenter cluster
  • vcenter-datacenter – Create/delete vCenter datacenter object
  • vcenter-maintenance-mode – Manage the maintenance mode state of an ESXi node
  • vcenter-networking – Create/delete DVS
  • vcenter-portgroups – Create/delete port groups

Wherever possible, each role has been written to allow the creation, deletion or modification of said objects within the SDDC environment.

In addition to the roles themselves, there are published playbooks that execute the roles in a specific order, based on dependencies, to perform the actual deployment of the SDDC environment.

  • esxi_sddc_configure.yml – Configure ESXi nodes
  • nsxv_sddc_deploy – Deploy and configure NSX-v Manager and controllers

If you are looking to start leveraging Ansible to deploy and manage your VMware SDDC environments, these roles are a great starting point. Reach out to me over Twitter, or come find me this afternoon in the VMware {code} Theatre at 1:00PM.

Enjoy!

 

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!