A couple of weeks ago at the vMA Technology Conference (TechCon), I talked about Infrastructure as Code in one of the breakout sessions (live video recording is available here). In this presentation I explained the concept of Infrastructure as Code (IAC) and discussed what VMware is doing in the IAC space. In both vRealize Automation (vRA) and Cloud Assembly (CA) IAC is used. The actual blueprints that are available in the self-service catalogs of either one of these products are available in the system as JSON code. In vRA you can export this code using the CloudClient, in CA the code is directly available through the UI.

In this article we will dive deeper in what you can do with IAC in specifically vRA. I will show you how to build a basic versioning system for blueprints in vRA, using the CloudClient and GitHub leveraging the IAC concept. I talked about this versioning system in my vMA TechCon presentation. I received several reactions of people who found this interesting, so more details will follow in this article. Although the whole thing started a bit as a gimmick, it might be valuable for you.

The architecture of the versioning system

To get an idea of what components are required for the versioning system, let’s start with the architecture as presented in the following diagram:

The idea is to use Github as a versioning system, so the goal is the upload the code of the vRA blueprint to GitHub. To achieve this, we will need the CloudClient to get the JSON IAC code from vRA. We will use a little bash script to coordinate the whole process. The bash script is started through vRealize Orchestrator (using the Run SSH command workflow) in combination with the vRA event broker.

Please note that the whole versioning system is currently “one-way”, you can only upload your blueprint versions to GitHub. Downloading/restoring a blueprint is currently not part of the solution, but can of course be achieved through some manual steps.

Some bash scripting

The majority of the work will be done by a tiny bash script. This script is used to start the CloudClient, do an export of the JSON code, unzip this code and upload it to GitHub. In my case this is script is called update-template-github.sh:

#!/bin/bash
# Commandline parameter $1 contains the description for the commit
EXPORTDIR="/home/iac/CentOS7-composite-blueprint"
GITREMOTE="demo01"
cd ~
FILE=`VMware_vRealize_CloudClient-4.5.0-8227624/bin/cloudclient.sh vra content export --path /home/iac/ --id 870b37f4-91b4-42a5-be25-fcdbebada6c8 --content-id CentOS7 | grep .zip | awk '{print $9}'`
cd $EXPORTDIR
unzip -o $FILE -d $EXPORTDIR
git commit -m "Automatic update by vRA event broker" -a
git push $GITREMOTE master
cd ..
rm $FILE

After setting some variables, the scripts changes directory to the home directory of the logged-on user, runs a CloudClient command and returns the zip file that contains the vRA IAC content to the FILE variable. This file (saved in variable FILE) is extracted to the directory in EXPORTDIR. After the ZIP is file is extracted, a git commit and git push is initiated to the git repository that is defined in the GITREMOTE variable. After the git repository is updated, the zip file in FILE is removed.

The bash script is started by a vRO workflow, and requires some pre-configuration for both the CloudClient and the git client. Let’s first have a look at the CloudClient and git client, and then dive into the required vRO workflow and event broker configuration.

CloudClient configuration

The CloudClient command we’re going to use is:

vra content export --path /home/iac/ --id 870b37f4-91b4-42a5-be25-fcdbebada6c8 --content-id CentOS7

(this command is in the bash script as presented earlier)

This command runs an export of a blueprint identified by id 870b37f4-91b4-42a5-be25-fcdbebada6c8 and content-id CentOS7. You can run this command in an interactive shell, by starting the CloudClient (cloudclient.sh), you can also run directly from the command line. If you want to run this command directly from the command line, you have to pre-configure the vRA Server, vRA Infrastructure server and the required credentials. This can be achieved through a CloudClient.properties file. Start the cloud client with /cloudclient.sh, and walk through the following steps:

login autologinfile             #creates the CloudClient.properties file
login keyfile --file vra.txt.   #creates a encrypted password file for the vRA appliance user 
login keyfile --file vraic.txt. #creates a encrypted password file for the vRAIC service account

Now exit the CloudClient and edit the newly created CloudClient.properties file:

# CloudClient.Properties File used to automatically login to CloudClient and it should be located in the same directory as lib and bin folders.

# Passwords can be provided or simply encrypted to a file, use command:
# login keyfile --file mypass.txt --password mypaasword

#vra_server : vRealize Automation Virtual Appliance
vra_server=<FQDN of the vRA Appliance>

#vra_tenant : Tenant Name, defaults to vsphere.local
vra_tenant=<vRA tenant you want to connect to>

#vra_username : Username
vra_username=<Username with sufficient permissions that will be used to logon to vRA>

#vra_password : Password
#vra_password=

#vra_keyfile : Encrypted file location of password - created in previous step with login keyfile command
vra_keyfile=/home/iac/VMware_vRealize_CloudClient-4.5.0-8227624/vra.txt 

# Some Administrator level API calls require Windows Authentication to communicate to the vCAC Infrastructure Service Components

#vra_iaas_server : Infrastructure Server (Windows Authentication) where IaaS Web Server node (Model Manager Web) is running, defaults to finding the name dynamically from vCAC
vra_iaas_server=<FQDN of the vRA infrastructure code Windows server>

#vra_iaas_username : Windows username in the form user@domain
vra_iaas_username=<Windows service account that is used for the vRA windows services: username@domain.local>
#vra_iaas_password : Windows password
#vra_iaas_password=

#vra_iaas_keyfile : Encrypted file location of Windows password - created in previous step with login keyfile command
vra_iaas_keyfile=/home/iac/VMware_vRealize_CloudClient-4.5.0-8227624/vraic.txt

#vco_server : VirtualCenter Orchestrator Server
#vco_server=<not required in this scenario>

#vco_username : Username
#vco_username=<not required in this scenario>

#vco_password : Password
#vco_password=

#vco_keyfile : Encrypted file location of VCO password
#vco_keyfile=<not required in this scenario>

Now test your configuration by starting the CloudClient with ./cloudclient.sh. If the CloudClient successfully starts (without entering your credentials), you’re all set!

Git configuration

Part of the process is automatically connecting to github.com to do a git push. Because we don’t want any login prompts, I’m connecting to github through SSH. By uploading the public SSH key of your host, you can automatically connect to GitHub. The process to configure SSH with keys is described here.

After generating a keypair (private and public key), you have to upload your public key to GitHub. Upload it as a deploy key in the repository you’re planning to use. Select the repository -> settings -> deploy keys.

You can test the connection to git with:

ssh -T git@github.com

If everything works as expected you would a confirmation message:

Hi viktoriousss/vRA-CentOS7! You've successfully authenticated, but GitHub does not provide shell access.

Now cd to your directory (in this example that is /home/iac/CentOS7-composite-blueprint) you want to connect to git and run:

git init
git remote add demo01 git@github.com:viktoriousss/vRA-CentOS7.git

This tells git to initialize a new repository at the client site, and link it to the vRA-CentOS7 repository identified locally by identifier demo01.

Event broker and vRO workflow

The last is to configure the vRO workflow and the vRA event broker. The vRA event broker runs the bash script that uses the CloudClient en Git to create a versioning system for your blueprints. The Blueprint Configuration event topic is used for this, which is triggered after a user clicks save or finish:

In this example the blueprint’s name and ID is CentOS7, so this is configured as a condition for the Blueprint configuration topic:

The workflow subscription is linked to a basic workflow called “updateBlueprintOnGithub”.

The updateBlueprintOnGithub workflow is actually just “a Run SSH command” workflow that is linked to the linux server that will run the update-template-github.sh. The logHeader action is nothing special and added for logging purposes.

Parameters of this workflow are the hostNameOrIP of the SSH host (iac.viktorious.local in my case), login name and password (or an SSH key) and the name of the script: /home/iac/update-template-github.sh.

And it all comes together

Now we have configured the different components, we can start using the versioning system. Open de CentOS7 blueprint, add/change/remove a component and click save or finish. The eventbroker will trigger the vRO workflow that will start the bash script. You can see the live commits on GitHub here, open a commit to see the differences with a previous version:

That’s it! I hope this was helpful again, please leave your feedback below!