While I have been using VMware’s Cloud Automation services for a while now, I have only been deploying and automating cloud services. I have not had a look at automating CAS itself, specifically Cloud Assembly.
I was lucky enough to get my hands on a blank org that was not been used by anyone else, good chance to play with the api. I thought why not create something that would configure a completely blank cloud assembly to something that can be used, consisting of :
– Cloud Accounts
– Cloud Zones
– Image Mappings
– Flavor Mappings
– Network Profiles
– Storage Profiles
This is something that is not new, I have seen other examples of this. I thought I had seen this done with python but was thinking why not give it some flavor and have vRA7/vRO7 automate its younger sibling. So lets slap it together in vRO. again this was a lot of re-use of existing code I had to save time getting it out the door, but hopefully give you the building blocks to refine and go forward..
Below is the video demo I did on this.
I have added my vRO package for anyone to download at the bottom of this page, for the API’s that I am using you can see all of them in the swagger ui https://www.mgmt.cloud.vmware.com/iaas/api/swagger/ui/
1) Before I start I wanted to use config elements to hold most my configurations, such as refresh token, Azure, AWS subscription details etc. I have broken it up by global, aws and azure elements. Some of these I populate during the provisioning so I can recall later, like casRegionId, but regions, ami’s and keys need to be filled in prior to running
2) First I created a rest call action to handle all my calls to CAS.
3) First thing is first, I need a workflow to do the authorisation, CAS like many VMware products uses a bearer token. Created a workflow that queries the CAS api with my refresh token, parse the return and output the bearer token.
4) While I didn’t follow my usual rule when creating this project which is using actions and passing around a properties payload. I did start but then got lazy in the middle due to time constraints, Since I didn’t know how many accounts I needed to create I created a generic account creation payload and a set configuration element actions show below.
5) I then i created a workflow to get the region id, this is needed when creating network profiles etc.
6) Next we need to create network profiles to associate with the cloud accounts. This is where the laziness kicks in, I have used a scriptable task here when i should have created an action.
7) Then we need to create some flavors, Since this was just testing i did hard code the sizes in, but these could be inputs.
8) Images mappings is the next part we need.
9) I could have spent a little more time and made this next piece agnostic but broke the storage profiles into platfoms.
10) Creating a project is next, Again this would be cleaner if I had of done the similar thing as I did with the cloud accounts.
Now we take all that snap it all together and create the master workflow which takes in the boolean inputs to build out the Cloud Assembly for use. The sleeps are a massive sin and in there is because when the cloud accounts are created it takes a couple moments to collect the data for network etc. Again this could be better handled with get zones api call checking for when the data is available in the payload and continue when successful.
Finally we publish XaaS BP in vRA7 and we end up with out catalog item.
I did have all the Rest operations to the different endpoints and have listed them out in the description within the workflow attributes.