Orchestrator already provides a feature called Dynamic Types in order to build your own custom Orchestrator data types since long, but most people don’t really use them, because it needs some time to fully understand and work with them.
In conjunction with vRealize Automation, Dynamic Types can be used as custom resources in the Advanced Service Designer. There are a lot of really helpful use cases because those custom resources can be very powerful.
That’s reason enough to figure out how to create your own custom resources based on Dynamic Types.
First of all, what are custom resources? In vRealize Automation (vRa), besides deploying virtual machines, we also can provide any services and create any kind of resource or element we want – so called XaaS or Anything-as-a-service. To do this, we simply tie a vRealize orchestrator (vRO) workflow that creates this resource for us to a catalog item in vRA and then users can request this resource exactly as he would request a virtual machine.
Recapping Xaas functionality
A typical example would be an Active Directory user. We simply could create a catalog item in vRA that calls the Active Directory user creation workflow in vRO and every user can request its own AD user from the service catalog.
Ok, that has still nothing to do with custom resources, but that is about to change shortly. If we later want to change or delete this new resource (the user), there is no item we can click on, respectively the vRA simply does not manage the object we created and so we only could create another XaaS item and workflow, that deletes any user we type into the form. Now, that could be ok, but in most cases it is much nicer to directly click on an item to change/delete it similar to the virtual machines in vRA. Also often we want to be sure, the end user only deletes items, he created itself and to ensure this it again is much easier, if he sees only his items. So we need a concept, that manages any kind of resource in the vRA and of course this are the custom resources. In our example we would define the Active Directory user type from vRO as our new custom resource and tie it to the first creation workflow and simply as that our new users would appear as items in the vRA items tab. Now we can define further actions for this resource and they would appear as buttons or menu entries exactly as we imagined.
What problems need to be solved?
This could be a really nice situation, but this concept has a nasty limitation; a custom resource can only be a real vRO Type and that only includes elements in vRO that can be shown in the inventory. So no Strings, no numbers, no properties and so on. Also that means, we only can manage objects in vRA, if there exists a fitting vRO plugin. Despite the fact, that there are several plugins out there, we could of course imagine many other resources, we would want to manage in our vRA.
Solution
In this blog series I want to manage my AWS CloudFormation stacks in vRA and although there is an AWS plugin for vRO (it doesn’t help, because it only can manage the EC2 and VPC service of AWS). That means no S3 buckets, no DynamoDB Tables and of course no CloudFormation stacks.
As I mentioned above, there are two alternatives to have a custom resource for CloudFormation in vRealize Automation– I could write a new vRO plugin myself or I have to find a flexible existing vRO type that I can customize to fit my needs. And well, there is a solution for that, the Dynamic Types. I can represent any kind of resource as a dynamic type and then create a custom resource in vRA with it. Additionally, I can extend the Dynamic Types with new custom fields to store any additional info I need. The only problem – I have to create them first and that can be a little bit challenging.
Ok, before we talk further about the Dynamic Types, we have to define exactly, how we want to integrate our resources (in this case the CloudFormation stacks). The first problem is the communication itself. Amazon defined a security concept that makes it difficult to directly use the Rest plugin of vRO. The problem is that every call to AWS has to be signed – that means for every call we first have to calculate a hash value out of every other info that we want to send to the server. So, if we would create our own new plugin, this would not be a big problem, because Amazon provides a SDK that takes care of that for us. That doesn’t help right now, because we don’t want to build a plugin, so we need another solution and fortunately there is the AWS command line interface which can be installed on any proxy host and simplifies the communication to AWS quite a bit.
So the complete plan is as following:
- We install and configure the AWS CLI to communicate with AWS and find out, how to create, manage and delete CloudFormation stacks with it. This would be the content of the next blog post.
- In the next step we create workflows and actions in the vRO to call the AWS CLI and based on them we create the new Dynamic Type. I guess this would take the third and fourth blog post.
- In the last blog post we tie our new Dynamic Type as a custom resource to the vRA and create the XaaS catalog item and additional actions to fully manage the CloudFormation stacks by vRA
Of course I will update this post with new links as soon as they are available. Stay tuned for the next post when we talk more about the AWS CLI
Recent Comments