Automate the VMware SDDC using a Multi-Stage Environment Using Ansible

Posts in the Series: Ansible for VMware SDDC
  1. Automate the VMware SDDC using a Multi-Stage Environment Using Ansible
  2. Overview of the Ansible OVA Deployment Role

Welcome to the first post in my new series: Ansible for VMware SDDC where I will provide a series of posts to help you deploy the VMware SDDC stack in a multi-stage environment using Ansible. Automating VMware environments using DevOps tooling is no easy task, as most administrative tasks are achieved using PowerShell, and often lack a consumable API to perform certain tasks. I have decided to take on this daunting task and provide a complete end-end automated solution.

Managing your VMware infrastructure in this way will allow your SDDC configuration to be treated as Infrastructure as Code (IaC) and stored in a source control repository like Git. This further allows for immutable infrastructure where appliances can be re-deployed and configuration applied in several minutes, should the need arise. This can provide an alternative approach to restoring services due to a major issue, such as corruption or loss of an appliance by simply redeploying it from code.

I started this piece of work as a side project for deploying my own environments but have been fortunate enough to extend the work to help my clients automate their VMware infrastructure. I, therefore, decided to collate the work that I have done into a series to help others.

The Multi-Stage environment idea was based on a great article I read called How to Manage Multistage Environments with Ansible by Justin Ellingwood, which I recommend you read.

This post will demonstrate how to create the Ansible working environment from scratch and utilise a number of roles that I have created for various VMware deployments. I will provide follow-up posts in this series which will cover the deployment of a specific VMware technology, i.e. vCenter Server and to end the series I will demonstrate how you can deploy a full SDDC stack, including nested variants that can be quickly spun up for development and testing purposes.

Prepare the Environment

The roles that I have created have some dependencies that first need to be installed. I recommend that you use Python virtual environments when setting up your Ansible environment. I have created a guide here on how to install Python 3 and how to create and activate a virtual environment, where the dependencies can be installed. Note that this is not a requirement.

I have prepared an ‘ansible_vmware_sddc_requirements.txt‘ file that includes all dependencies that are required to run the VMware SDDC roles, including Ansible and the vSphere Python SDK (pyVmomi). These include specific versions of the core dependencies that I have tested against and other transient dependencies used by these modules.

You can find the ‘ansible_vmware_sddc_requirements.txt‘ requirements file on my Github Gist account here.

Or simply install the dependencies using pip:

Your environment will now be ready to run Ansible and my VMware SDDC roles.

Create Ansible Environment

This section will detail the creation of a multi-stage Ansible environment that includes an inventory for Development, Testing, Staging and Production. Each of these inventories will include its own hosts’ inventory file, group_vars and host_vars. The Development inventory will be set as the default if none has been specified when running a playbook on the command line. This helps to ensure that other environments are not accidentally targeted.

The Ansible environment is typically implemented specifically for the project/company/user so it is difficult to create an all-encompassing solution that suites all uses-cases. However, I have created a recommended setup for creating these deployments.

This is a base configuration that you will likely need or want to tailor to your own specific requirements. This typically boils down to variable placement within the groups, however, as long as the required variables have been defined, then it is up to you where to place them.

This post will only cover setting up the Development Environment.

Start by creating a new empty folder where Ansible should be set up:

I have created a script that I use to bootstrap my own environments when testing. You can download the script via my Github Gist account using wget.

Please note that this is script is far from elegant and I plan to improve/replace it completely in the future with something more robust. I’d also welcome anyone who would like to do that for me.

The script defines a number of group variables for each VMware solution (i.e. vCenter Server Appliance). If you feel that you do not require a specific set of groups, then simply comment out the respective variable.

Once you are happy, execute the script using bash.

If you want to execute the script as-is via the URL, then run the following command:

If you have any problems with the script, I have created a git repository where you can download multi-stage Ansible environment template via zip file here.

This will create the following Ansible directory structure including config files (note that I am only displaying groups for the Development inventory, but the same groups have been created for all other inventories):

Groups Overview

The table below details the groups that are created:

Group Name Description Group Members
vcsa_65_appliances vCenter Server 6.5 Appliances
vcsa_67_appliances vCenter Server 6.7 Appliances
vcsa_appliances All vCenter Server Appliances vcsa_65_appliances
vro_75_appliances vRealize Orchestrator 7.5 Appliances
vro_76_appliances vRealize Orchestrator 7.6 Appliances
vro_appliances All vRealize Orchestrator Appliances vro_75_appliances
nsxt_24_appliances NSX-T 2.4 Appliances
nsxt_25_appliances NSX-T 2.5 Appliances
nsxt_appliances All NSX-T Appliances nsxt_24_appliances
vrlcm_21_appliances vRealize Life Cycle Manager 2.1 Appliances
vrlcm_appliances All vRealize Life Cycle Manager Appliances vrlcm_21_appliances
vidm_33_appliances vRealize Identity Manager 3.3 Appliances
vidm_appliances All vRealize Identity Manager Appliances vidm_33_appliances
vrli_48_appliances vRealize LogInsight 4.8 Appliances
vrli_appliances All vRealize LogInsight Appliances vrli_48_appliances
vrops_75_appliances vRealize Operations 7.5 Appliances
vrops_appliances All vRealize Operations Appliances vrops_75_appliances
vesxi_65_hosts Virtualized/Appliance based ESXi 6.5 Hosts
vesxi_67_hosts Virtualized/Appliance based ESXi 6.7 Hosts
vesxi_hosts All Virtualized/Appliance based ESXi Hosts vesxi_65_hosts
pesxi_65_hosts Physical ESXi 6.5 Hosts
pesxi_67_hosts Physical ESXi 6.7 Hosts
pesxi_hosts All Physical ESXi Hosts pesxi_65_hosts

This group structure allows variables to be tailored to specific VMware product versions or global to all products in a given category.

Hosts Inventory Overview

The hosts’ file in each inventory will look like the following YAML formatted file:

If you are not familiar with using YAML formatted host files (I know a lot of people still use the ini format) then I recommend to learn it. It becomes a lot easier to manage, keeps it consistent with playbooks and it’s a lot easier to visualise the group structure.

When adding hosts to this inventory, place them under the ‘hosts:‘ section for the respective group, with 2 spaces indentation and terminated with a colon ‘:‘, for example:

If you are using a Python virtual environment then also add the ansible_python_interpreter for the localhost to match that of your environment, for example:

Create a VMware SDDC Stack Application Group

In this section, we are going to look at creating an Ansible group that will be shared between all components in the SDDC stack. One advantage of using this approach is that it reduces the amount of duplicated information and allows all components in the stack to access the same variable information, credentials, etc.

I didn’t want to include this in the main Ansible environment setup as you are free to create as many of these SDDC application groups as you like and you don’t have to use the same naming conventions that I will be using (but to avoid confusion in future posts, it’s probably best that you do).

For the purposes of this series, I am going to create a new SDDC application group called sddc_stack_01 and add a definition to the end of the hosts’ file in my development inventory.

Which should now look as follows (groups omitted for readability):

In the posts to follow, all appliances that are deployed will be added to this group, in addition to their respective role-based group.

We also need to create a folder in group_vars where the YAML based variable files for the sddc_stack_01 application group will be stored.

I am also going to create two empty files in this directory, sddc_stack_config_vars.yml for storing variables and sddc_stack_credentials.yml for credentials (I may create more as we progress through this series):

The sddc_stack_01 application group structure should look like the following:

Example Playbooks

There will be a playbook for each main group of appliances (i.e. vcsa_appliances) that will target the defined hosts and deploy them using the specified role. There is no need to create additional playbooks for sub-groups as these can be targeted using the ‘–limit- Ansible parameter when executing the playbook.

The following is an example of the vmware_deploy_vcsa.yml role

A playbook exists for all other groups managed by Ansible.

That’s it for this post, and I look forward to sharing with you some of the work that I have been doing for automating VMware deployments. Stay tuned!

Please rate this post!

Average rating / 5. Vote count:

Leave a Reply

Notify of