Intergrating vCloud Application Director (Linux VM) with vCenter Orchastrator

So I have been using vCloud Application Director (or vCloud Automation Center Application Services) a fair bit recently which is VMware’s Platform as a Service (PaaS) life-cycle management add-on to vCloud Automation Center. Although it is a great product for orchestrating multi-tier application platform deployment, one feature that is currently lacking in my opinion is native vCenter Orchestrator (vCO) integration. vCO has become the corner stone of advanced automation and integration in the VMware product suite and it is nearly always required when trying to do end to end automation with vCAC for IaaS or PaaS.

 

The Script:

I have created a vCO Integration Bash Script which can be found here CallvCOWorkflow.sh. The Script is designed to be run from Application Director using either a Linux Guest based Service or External Service with the service VM provided through a Linux OS. It is an important fact that although this post is based upon using this script for AppD to vCO integration, this bash script can be used on any Linux OS assuming XMLStarlet (more on XMLStarlet below) can be used.

 

Calling vCO via the REST API:

So if you have not guessed already the CallvCOWorkflow.sh script is leveraging the vCO REST API to submit a vCO Workflow request. The vCO API is well documented and can be found here for 5.5 -> Using the vCenter Orchestrator REST API. However if you want to get started writing your own scripts against the vCO API I highly recommend the vCO Team post by Burke Azbill on How to use the REST API to Start a Workflow. This was basically the guide I followed to write the script and it worked a treat.

 

Why Bash and XMLStarlet?

So in my case I needed the script to run from an External Service VM in Application Director. For those who don’t know an External Service VM is a VM that is provisioned as part of a application blueprint deployment to integrate with an external system. The VM is quickly spun up, it then runs its required scripts and is then torn down again. The External Service VM needs to be quick to deploy, so a lightweight Linux VM is perfect. I also wanted to try and simply stick with OS level shell script and avoid having to install perl or python. One exception I did have to make however was to install XMLStarlet. “XMLStarlet is a set of command line utilities (tools) which can be used to transform, query, validate, and edit XML documents and files using simple set of shell commands in similar way it is done for plain text files using UNIX grep, sed, awk, diff, patch, join, etc commands.” XMLStarlet is required as we need to query the vCO REST API which responds in either either XML or JSON. Unfortunately there is no nice way to handle XML in bash so XMLStarlet is the solution to this problem.

 

Using the Script from a Linux OS:

To run the script from a Linux machine simply download the script, install XMLStarlet and update the input variables. The lines that need to be updated are shown below. Most are self explanatory with the exception of the PREFIX.
The PREFIX is used for Application Director to help distinguish which workflow and which workflow inputs are used for the different life-cycle stages such as Provision, Update, Teardown, etc…

You can change the PREFIX to anything you like, the key is that the script will use all variables that start with that prefix and an underscore as inputs to the vCO workflow.

####BEGIN INPUT VARIABLES####
vCOUserUPN=”user@domain.local”
vCOPass=”Secr3t!”
vCOFQDN=”vco.domain.local”
PROV_WorkflowName=”Workflow Name in vCO”
#PROV_WorkflowID=”Insert Workflow ID”
PREFIX=”PROV”
####END INPUT VARIABLES####

####BEGIN WORKFLOW INPUT VARIABLES####
#THIS IS AN EXAMPLE VCO WORKFLOW INPUT VALUE
#ALL INPUT VARIABLES MUST START WITH THE PREFIX
PROV_resName=”F5DHCPTestReservation”
PROV_clientMAC=”001122334455″
####END WORKFLOW INPUT VARIABLES####

 

For example I have used two script inputs being resName and clientMAC. These match vCO workflow parameter variables. The resName parameter is required however the clientMAC is optional for this particular workflow. Based on the options above the following XML is created. Note this is already provided in the log output.

INFO: Creating Template XML
INFO: The following XML will be submitted to run the vCO Workflow
<execution-context xmlns=”http://www.vmware.com/vco”>
        <parameters>
                <parameter type=”string” name=”clientMAC” scope=”local”>
                        <string>F50011223344</string>
                </parameter>
                <parameter type=”string” name=”resName” scope=”local”>
                        <string>DHCHTestReservation</string>
                </parameter>
        </parameters>
</execution-context>

 

Using the Script to Integrate AppD with vCO through an External Service:

So as this post is actually on integration with vCAC Application Services I should probably mention how to do that as a standalone external service.

Simply create a new External Service and ensure it is backed by a logical template that is a Linux OS (with XMLStarlet installed). Add properties to the service matching the Input variables above and as required for the Workflow Input variables.

Copy and paste the script into the various life-cycle stages you required ensuring you set the Prefix value at the start of each script in each stage. Also ensure that you do not include the input variables component of the script as this is now handled by AppD.

DHCPAppDExternalService

 

Save the External Service and register it with a Deployment Environment. Create a blueprint using the service and deploy.

Afterwards you should have your workflow complete successfully with vCO workflow completed and the output returned to AppD.

DHCPAppDExternalServiceExecution

Happy automating 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *