Many companies nowadays are getting serious about adopting the “Devops” mentality and treating anything IT Teams produce “as code”. For most people, that phrase in itself doesn’t mean much until they see a concrete use case that can really benefit from such a concept. If you use vRealize Automation as a Cloud Platform, you’ll come across some concepts that can fit the “code” mold.
Let’s dive deeper into this use case.
vRealize Automation creates a problem
The problem comes along when you add a 2nd vRA instance into your environment, when let’s say, you want a new vRA instance for development and testing purposes.
How would you copy over all your existing workflows, blueprints, Resource Actions, Event Broker Subscriptions, Property Groups and Property Definitions from one vRA instance to the next? One option is to use the Cloudclient and copy everything semi-manually using some scripts. That basically exports all your content to “.zip” files that you can copy to the new vRA instance location and import them using another Cloudclient connection. Sure that works if you need to do it once, twice, but if you do it everyday, it won’t be long that you’ll want to tear your hair out!
So what can we do better when managing these objects? If you’ve been paying attention, you should know that the answer is “treat them as code”!
What does treating something as code mean?
Software Development practices have been around for a long time and although they are constantly evolving and there is always something new in that field, these practices and processes can be considered mature and efficient if applied properly. It only makes sense to apply some of these principles to managing constructs like those that exist in vRA. At the very least, these principles can give you some sort of framework to work within to avoid wasting time and to make you a little more efficient.
Applying these principles to something other than pure Software Development is what we can call “treating as code”. But more concretely, what does that mean? Here are a few examples :
– Artifact Versioning (What’s an artifact? Here’s what Wikipedia says, but basically it’s either compiled source code, or an object used by a program. In the case of vRA, any zip file that contains a blueprint can be considered an artifact)
– Committing and Pulling artifacts from a central repository
– Source Code Management (This portion is still lacking for our use case with vRO/vRA)
These tasks are usually accomplished using Software Development tools like GIT for Source Code Management or JFrog Artifactory for Artifact Management.
But what are we treating as code?
The term VMware uses, “SDDC Content”, refers to vRealize Automation Blueprints, Property Groups, Custom Property Definitions, Event Broker Subscriptions, Resource Actions and vRealize Orchestrator Workflows, Actions and Configuration Elements. Basically the point of having all this content is that if you have a new vRA and vRO instance, porting all of this content over to it will make it nearly identical to the old one. Some exceptions remain however, for example you won’t be able to port over catalog configurations or tenant branding settings, but the meat and potatoes of your vRA configuration is exportable and doing so will save you a bunch of time because you won’t have to recreate it manually.
This SDDC Content is the reason and key to Infrastructure as Code with vRealize Automation.
vRA Blueprints are actually YAML code, Custom Property Definitions are basically zip files with a line of code that defines it as a variable. Because of this, these constructs can be treated as code, each of them is either code itself, or code artifacts.
Why is it important to manage content?
Just try to manage more than one vRealize Automation instance and this question will answer itself. If you are serious about using vRA as a cloud management platform, finding an efficient way to manage this content will quickly become a necessity. But just in case you were looking for a point form list, here it is :
– Easy Portability between datacenters/vRA instances
– Forces you to make “portable” vRealize Orchestrator workflows with no hard coded values
– Helps ensure that the same version workflows are deployed across all the vRA environments
– Other benefits, like allowing you to keep a backup of all your import content, in case you need to rebuild a vRA instance after a disaster
If you don’t manage your vRA content properly, your life will be so difficult, that I can almost guarantee you will have vivid nightmares of a past SDDC object’s ghosts…
How do I manage SDDC content? vRealize Code Stream and “Houdini” have a solution.
Ever heard of vRealize Code Stream? I wouldn’t be surprised if you didn’t… This is one of VMware lesser known products, but that doesn’t mean it isn’t as useful as other ones! vRealize Code Stream is an interesting product on its own, it can be used for automated testing of software deployments, which is great, but that is a subject for another time.
For this particular use case, what we’re really interested in is actually what is called the “Management Pack for IT Devops” or what is commonly known as “Houdini”. Houdini is a Management Pack for vRealize Code Stream that will allow you to store “SDDC” objects in an Artifact Repository, like JFrog Artifactory. The list of content that can be managed with it is pretty long, but essentially it encompasses nearly every significant object that exists within vRealize Automation, vRealize Orchestrator and even vRealize Operations. VMware likes to call this “Release Management”.
Let’s dive into the specifics of how to solve this problem using the tools that VMware provides to us for this purpose.
vRealize Code Stream is actually deployed using the vRealize Automation OVA file. That’s right, vRCS is hidden like the dark side of the moon, right beneath your nose, within the vRA appliance. The only way to use it though, is to input a vRealize Code Stream License key during the (vRA) installation. Doing so will deactivate all unnecessary services on the appliance and allow you to use the vRCS-specific components. Also, the vRA v7.1 / vRCS v2.1 appliance also contains a (well hidden) Professional version of JFrog Artifactory that you can use as a repository for artifact management of your SDDC objects. It is suggested to have a separate dedicated vRCS appliance (AKA a Remote Content Server) specifically to store Artifacts if your environment is a large one. You can find more info if you click on the MyVMware link below, that will bring you to the documentation specifically for the Houdini Management Pack, or you can also take a look at page 15 of the vRealize Code Stream Reference Architecture document.
Once you’re all set up, all the functionality of the Management Pack is exposed via XaaS blueprints in the vRA catalog :
Source : http://www.clearascloud.com/2015/12/management-pack-for-code-stream-devops.html
Using the services in this catalog, you’ll be able to Capture content (store it in your artifact repository) then Release it (copy from your repo to a vRA/vRO instance). The usage of it is pretty straightforward and works fairly well once you get the hang of it. The idea is that you commit code (SDDC objects) into a central repository and then pull those objects into different vRA instances. That’s how you keep the same code in all your vRAs!
You’ll also notice that Houdini uses the concept of Branches, which is commonly known across the Software Development community in Source Code Repositories. Basically, the number one rule for Branches is that the “master” branch should always be stable and you can create point-in-time copies of that branch to add features to it and once the code is deemed to be stable enough it is recommitted or merged back to the master branch. If you’re not an expert on this though, don’t worry, there is no shortage of information around branches on the interwebs. Here’s a page from Github that explains the concept briefly.
If you want more information on the vRealize Code Stream Management Pack for IT Devops (AKA Houdini), here are a few resources :
– Search the VMware Hands-on-Labs for HOL-1721-USE-4 – DevOps with vRealize Code Stream
– MyVMware link for the Management Pack
– Solution Brief for the Management Pack
– Here’s a blog post on Houdini (an oldie, but goodie)
Also, I’ll be exploring this in more detail in a future blog post. I’ll show you how you can use vRealize Code Stream and Houdini to claim the crown of Continuous Delivery!
The Bottom Line
If you use vRealize Automation and vRealize Orchestrator seriously, you should include vRealize Code Stream and the Management Pack for IT Devops (AKA Houdini) into your everyday life. You don’t need to have the title “Devops Engineer” to think and act like one. 😉
