Managing workload on-premise or on a public cloud? No Sweat!

Recently I was challenged with provisioning an application to both an on-premise cloud and a public cloud. In this example, the on-premise cloud is powered by vSphere and the the public cloud is AWS EC2. I’ll demonstrate how vRealize Automation abstracts both clouds and allows you to easily deploy a simple application (WordPress App) using extensibility with vRealize Orchestrator.

Machine Blueprints

First setup machine blueprints for both your on-premise vSphere workload and your AWS EC2 workload. The blueprints should leverage the same version of OS to make things simple.

Go to the infrastructure tab, navigate to blueprints and select “new blueprint”. You’ll be able to choose from several different clouds and on-premise options. In this example, I’ll leverage the multi-machine blueprints to create an application based on pre-existing single machine blueprints for Linux on vSphere and EC2.

Creating the multi-machine blueprint for both vSphere and EC2 is pretty much identical.

Ensure that you provide a descriptive name and description.

Now specify the single machine blueprints to be used in the “Build Information” tab and select “Add Blueprints”.

You’ll be provided with a list of single machine blueprints that can be added. Note that I pick the single machine blueprint CentOS Linux 5.6 running on EC2. If I was creating an on-premise blueprint I’d choose the linux blueprint just below.

Now that my single machine blueprint has been added, I’ll set the maximum lease for 2 days. Since this is running on EC2 I want to control how long the workload can run to avoid costs.

Finally, I’ll add properties that are required to deploy the WordPress application. Note that the properties are identically, regardless of running on vSphere or EC2.

Two things to note with the properties…

1. I am leveraging build profiles to contain certain wordpress properties like DB name, password, etc. A build profile essentially allows you to create a group of properties that can be easily reused across blueprints. I’ve named the build profile “WordPress Application” and checked it so that those properties are included in the blueprint.

2. I’m leveraging vRO extensibility to run a custom workflow that will execute on the linux machines and install the word press application. The property “ExternalWFStubs.MachineProvisioned” is used to tell the blueprint to run a vRO workflow once the machines are provisioned in vsphere or EC2. The unique ID of the workflow is 9d200500-6bef-4ab7-96d4-1f8f3b2209f9.

vRO Workflow

How do you guet the unique ID of a vRO workflow? Simply log into vRO, find your workflow and look at the “General” tab. The unique ID of the workflow will be displayed.

Since we are deploying to a consistent version of linux, A single workflow can be utilized to deploy wordpress on-premise or on EC2. There is one logic point that should be added to your workflow to decide if the workflow is running on an vSphere or EC2. In the screenshot below, you’ll notice that I highlighted a custom decision point.

The following code is in the decision point.

IsAWS = vCACVmProperties.get("__amazon.instanceType");

if (!IsAWS || 0 === IsAWS.length){
System.log(“VSphere Instance Type: “);
return false;
}else{
System.log(“AWS Instance Type: “+IsAWS);
return true;
}

If it’s running on EC2 it will direct the workflow down a path that uses the DNSname if it’s running in my on-premise cloud then it will use the IP address.

At this point we have a blueprint and a vRO workflow for deploying the wordpress application. After publishing the blueprints for on-premise and EC2 it’s now available for my users to consume.