I have a requirement to deploy AWS CloudFormation template from vRA self-service portal. The requirement is to use custom parameters which we need to ask end-user in the form such as prod vs non-prod, region, load balancer (yes\no), etc...
I explored vRO plugin for AWS but didn't find any workflow or out-of-box way to deploy CloudFormation template to build the stack in AWS cloud.
Please suggest the best way to develop this automation in VRA\VRO.
The plugin only has the EC2 API associated with it, and unfortunately even that functionality is outdated. Saw on another thread that the plugin is getting an update but I wouldn't hold out hope that the CloudFormation API is part of that refresh. The thing with AWS is that they have tons of offerings and each of those offerings seems to have its own API. EC2 is pretty common, so I can see from a design perspective why VMware would only focus on that one; it pleases the most customers.
For this kind of task you're going to have to setup an XaaS since vRA can only deploy EC2 instances out of the box. The REST API for AWS is difficult to work with due to all of the handshakes you have to go through to authenticate to it, so unless you're adventurous I would steer clear from having vRO directly talk to that thing. As a workaround, I've deployed helper machines with either the AWS-CLI or AWS Tools for PowerShell installed on them, and used those as my work around for the things the plugin doesn't cover. It's a lot easier to write and manage scripts on those machines and have vRO call them with the appropriate arguments. As an example, here are the cloud formation CMDLETS ready to use with AWS Tools for PowerShell:
Another option is to still use vRO, but expose the Amazon AWS SDK directly to scripting. You can do this by modifying the Rhino Class Shutter File property.
The Rhino Class Shutter File property instructs vRO to take all Java classes listed in the file designated in the property and expose them to script within vRO. Each class entry should be on its own line in that file. Next, the libraries containing the classes need to be available to the server, hence copying all the JARs to the /var/lib/vco/app-server/lib directory. When you restart the server, it will process the shutter file and now those classes should be available from script.
Here is an example EMR script that works. This was adapted from the AWS SDK examples. I am sure you can find a Cloud Formation example to do the same thing.
This is a workflow with 3 inputs - awsAccessKey (string), awsSecretKey (SecureString), clusterID (string). All 3 inputs are passed to a scriptable task with the script contents below:
var credentials = new com.amazonaws.auth.BasicAWSCredentials(awsAccessKey, awsSecretKey);
var client = new com.amazonaws.services.elasticmapreduce.AmazonElasticMapReduceClient(credentials);
// predefined steps. See StepFactory for list of predefined steps
var hive = new com.amazonaws.services.elasticmapreduce.model.StepConfig("Hive", new com.amazonaws.services.elasticmapreduce.util.StepFactory().newInstallHiveStep());
var result = client.addJobFlowSteps(new com.amazonaws.services.elasticmapreduce.model.AddJobFlowStepsRequest()
This method works and is powerful, but has at least one drawback which is that you have to use the full namespace of every object everytime you instantiate one, so you might have to do a lot of crosschecking back to the AWS SDK to make sure you have the right names. The other problem is the management of the AWS Access and Secret keys. There may be a way to use the built in AWS Plugin to store them or you might have to cache them in a config element and reference it with your workflow.
The next logical problem is showing provisioned items back into vRA as manageable resources. This can only be done with Dynamic Types or with a custom plugin.
If you do any of this, it is of course strongly recommended to do it from a test instance and document all your steps before moving on.