Recently, I've needed to move config from the development to a production platform. The ideal approach to this would be to use vRealize Suite Life Cycle Manager (or vRSLCM if you insist on an acronym) which would enable a more CI/CD approach for vRealize Suite products for moving config through development, test, acceptance and production including the deployment and upgrade process, as well as customer specific config such as property groups...
It it covered nicely here by @virtualhobbit. However, it's a product which is often overlooked when discussions around vRA start, so I needed an easy way to move property groups & definitions without vRSLCM...
As I mentioned, I used the CloudClient where I can because it's easy to get started with, something customers can get familiar with without having to understand how to build up REST API calls using curl and has a quickly understandable command syntax...
You can still use the CloudClient's REST functionality to do this... There are plenty of blogposts covering how to connect to the CloudClient so I won't go into details on that - but using the REST client is new to some people... First off, I tried running the below command to ensure I had the required permissions to make REST calls... This was logged onto the source vRA instance.
vra rest get --service identity --uri tenants
Next, using 'vra rest get' commands, I can return the property groups and property definitions and export these to JSON:
vra rest get --service properties-service --uri propertygroups --export c:\somewhere\pg.json --format JSON
vra rest get --service properties-service --uri propertdefinitions --export c:\somewhere\pd.json --format JSON
This will export the existing property definitions and groups into JSON files:
JSON isn't the easiest thing to read & understand, so I tend to use http://jsoneditoronline.org/ which shows the JSON script graphically. This is also very useful when having to re-import the property groups / definitions.
Unfortunately the 'vra rest post' command will expect a single object rather than the array which we have just exported. As such, I used jsoneditoronline.org to split out the individual objects:
By collapsing the individual objects in the array, you can copy them out to another editor window to verify they are correctly formatted JSON, then save them to individual files... Not ideal from a speed point of view, but this approach does ensure consistency between platforms that is essential.
From the destination vRA instance, again after logging in, I ran some 'vra rest post' commands in order to post the property groups & definitions:
vra rest post --service properties-service -uri propertygroups --format JSON --data @c:\somewhere\pg.json --headers no
I can specify to include the headers which will show the full return rather than just the success code of 201:
vra rest post --service properties-service -uri propertygroups --format JSON --data @c:\somewhere\pg.json --headers yes
The same applies for the property definitions as well, although below I hit a case sensitivity issue where the command didn't like '\t' in a filename path, presumably because it's a tab character... so I had to use an uppercase in the string:
vra rest post --service properties-service --uri propertydefinitions --format JSON --data @c:\somewhere\file.json (n.b., I didn't specify headers here so it defaulted to no):
The REST client through CloudClient can be used for pretty much anything else, not just properties... This information is available in the API guide which is on the appliance:
https://vra.domain.local/component-registry/services/docs
Happy automating!
Thanks for sharing, Sam.
ReplyDelete