Amazon has a pretty cool service that allows you to create a template for an entire set of infrastructure. This isn’t a template for a virtual machine, or even a series of virtual machines, but a whole environment. You can create a template with servers, security groups, networks and even PaaS services like their relational database service (RDS). Hey, in today’s world, infrastructure as code is the direction things are going and AWS has a pretty good solution for that already.

What about if you’re working with a Hybrid Cloud? You probably want a single portal that can deploy your on-premises infrastructure as well as utilize these cool things in AWS. If you’re using vRealize Automation, you can deploy EC2 instance natively, but some of the other services can be tricky. This post shows how you can leverage some of these services by using an XaaS Blueprint.

Initial Setup

First, we need to setup a Linux Proxy. This is a linux VM that has the AWS CLI installed on it. We’ll need a way to communicate with AWS and these tools will do the trick. On the Linux proxy perform the following steps.


curl "https://s3.amazonaws.com/aws-cli/awscli-bundle.zip" -o "awscli-bundle.zip"


unzip awscli-bundle.zip


sudo ./awscli-bundle/install -i /usr/local/aws -b /usr/local/bin/aws


Once the tools have been installed, run the “aws configure” command and fill out some default configuration information. This includes access keys, secret access keys as well as a default region to use and a default output format.

Now just to demo that we can create an AWS Cloud Formation Template Stack, we’ll run a test. The picture below, shows that a stack is created from the command that we’ve executed on the Amazon CLI tools.

vRealize Orchestrator Workflow

Here’s where the magic happens. We will build a vRO workflow that formats a string and then passes that command over to an “Run SSH Command” workflow. All we’re doing here is taking the command we ran from the cli and putting it into a vRO workflow. Then vRO will call try to execute this commando on the Linux Proxy.

Below, my format Command script will gather some parameters that I want to be able to customize when sending to AWS to create my stack. You can see that I’ve added variables for stackName and KeyName in my string.
cmd = "aws cloudformation create-stack --stack-name " + stackName + " --template-url https://s3.amazonaws.com/cf-templates-lmixyjh9tl6m-us-east-1/2016044zXm-template1kgn967yo2mqs38fr --parameters ParameterKey=KeyName,ParameterValue=" + KeyName
System.log(cmd);


If you try to manually build the stack from the AWS Console, you’ll see that there are a few more variables that I could have used, but I kept this simple with just a stack name and a key name. The rest of the parameters must have a default setting if you don’t plan to pass them along with the script.

Pass the cmd variable over to the SSH Workflow to have your Linux Proxy server execute the command for you.

XaaS Blueprint

Now that you’ve got a vRO workflow that can build a stack for a Cloud Formation Template, log into your vRealize Automation instance and publish an XaaS Blueprint. (This was previously done from the Advanced Services Designer in version 6 or before). Create the XaaS blueprint, publish it and then entitle it for your users. If you need more instructions on this, please see the vRealize Automation 7 Guide for instructions.

Create a Request

Now that all the setup is done, lets make a request. Click the AWS Cloud Formation Template catalog item that was published in vRA. Enter a description and a reason for the request.

Enter any of the parameters that you’ve seen fit to require. Notice in the example below, that even though my vRO workflow requires two parameters, I hard-coded the Amazon Key Name so that it cannot be changed. This means that I only need to enter a stack name to deploy it.

If we want to see whats going on, check the “Requests” tab of vRA to ensure the request finished. Check vRO to ensure that the workflow ran successfully, and you can check in AWS to make sure that a stack is being created.

After a few minutes (depending on how complex your template is) you should see a stack completed message with your stack name specified.

A quick test reveals that I am serving up the AMI Test page through Apache.

Summary

Maybe this isn’t quite as slick as having a way to manage the entire lifecycle of your virtual machines through vRA, but it is a really cool way to have a single portal to deploy on-premises, EC2 and Cloud Formation Templates. The tricky piece is managing the lifecycle of the stack. Perhaps an additional element in your vRO workflow that spins down the stack hours, or days later, or a second XaaS Blueprint that lets users destroy a stack based on the name. This would all depend on the specific use case, but this post should get your brain moving. I hope you’ve found it useful in your cloud endeavors.