The Beginner’s Guide to vRealize Automation 7 Software Components

Remember when paper maps were the only way to get around, then GPS came out and changed the game? That's sort of what VMware did with vRealize Automation 7's Software Components feature. Let's move on from that questionable metaphor to take a deeper look at how Software Components work in vRealize Automation and what you can use them for.

Software Components in vRealize Automation 7 are a blessing. They make execution of nearly any command in a VMs Guest OS at deployment time extremely easy. The basic premise is that you put your scripts (Bash, Powershell or Batch scripts) inside a Software Component and assign them to VMs. That easily, you can execute pretty much anything on a VM with just a few clicks.

What you'll need

First things first, this is what you'll need to take advantage of vRA7 Software Components :
– A vRealize Automation 7 Enterprise license, the Advanced license doesn't allow for Application Authoring.
– The vRealize Automation Guest Agent installed on all VMs you want to deploy Software Components to.
– Network connectivity from the VMs running the Guest Agent to the vRA IaaS server on port TCP 443.

Guest Agent (AKA the Gugent) installation and troubleshooting

You'll need to install the vRealize Automation Guest Agent on the VMs you want to deploy Software Components to. Normally, you would include the Guest Agent inside the VM Templates you are using for deployment. If you use Linux VM Templates, the Guest Agent installation also includes the Software Bootstrap Agent in its installation, the Bootstrap Agent is critical for using the Software Components functionality. If you have a Windows VM template, you'll need to install the Guest Agent and the Software Bootstrap Agent separately, you absolutely need both of those for vRA7 Software Components to work properly. If you don't install both, you'll only be able to use the Guest Agent to run scripts that already reside inside your VM's file system, not the ones you configure in the vRA GUI and are copied over to the VM on deployment, which is not ideal.

Here's a link to the Guest Agent installation procedure for Linux and for Windows.

If you have any issues with the Guest Agent and deploying Software Components to machines that have it installed, you'll want to keep an eye on this log file:

On Linux machines, /usr/share/gugent/GuestAgent.log

On Windows machines, C:\VRMGuestAgent\GuestAgent.log

It's a good idea to take a look at these logs to better understand what's going on.

I have encountered an issue with the Guest Agent when installing v7.0 of the Agent on a Red Hat 7 or CentOS 7 VM, where the Software Component I configured in vRA 7 simply wouldn't deploy itself. Thankfully, the community is full of helpful people that document this kind of thing and how to workaround it. The better fix though is to move to vRA v7.0.1 and use the agent from that same version, as it seems to fix the bug.

 

How to create Software Components

To create a new Software Component, go to the Design tab in vRA7, then go to Software Components and click New.

The first thing you'll ask yourself when seeing this screen is: "What's a Container?". We're not taking about Linux Containers here, vRA just wants to know WHERE the Software Component you're creating will be allowed to reside. The term Container refers to an object in the vRA Converged Blueprint Designer. If this is your first Software Component, you'll most likely want and have to put this value to Virtual Machine. That means that when designing blueprints, the only place you'll be able to use this Software Component is on that type of Container. The point of this is to allow you to configure some sort of basic encapsulation, where certain Software Components can only be executed if another predetermined Software Component has already been executed. In other words, this is a way to define dependencies between Software Components.

An example use case of this would be to install plugins for a monitoring agent. You would create a Software Component that installs the base agent, (which you would install on ALL your VMs) , then create a 2nd Software Component that would install a plugin for monitoring a database instance, for example. Not all your servers are database servers, so you wouldn't want to install that database monitoring plugin on every server that has a monitoring agent. So in this case, you would want to configure your 2nd Software Component that installs the database monitoring plugin to have the value of that "Container" field to be the name of the first Software Component that installs only the base monitoring agent. This way, the only time you can install that DB monitoring plugin is if the base monitoring agent has already been previously installed. Make sense?

 

Properties
This next step gives you the option to set custom values to variables that exist in your Software Components. The value of any variable in the script you put in a Software Component can be defined at Request time using Custom Properties like the ones you define here.

Let's continue with our previous example, let's say we want to install a Monitoring Agent onto a basic CentOS VM. You could create a Software Component that installs the agent without any interaction from the user deploying it. But using the Properties feature here, you could allow the user to specify the installation path, if he so chooses to.

This is just one example, but the possibilities of user input are limited only by your imagination. If you want to have the user decide which ASCI Unicorn will be appended at the top of your monitoring agent's log file, you can do that too. All you need is to populate an array of values and it will presented to the user as a dropdown list :

Here's my pick :

                   n
        |\   |  or
       _| \-/ic
      /    un
    //    ~ + \
   //         |
  //    \      \
 |||     | .  .|
///     / \___/

 

Moving on…

 

Actions

The next step is to actually input the scripts you want to execute into vRA. For our example, we'll use a Linux Bash script, but if you use Windows, you can also use Powershell or Batch scripts.

You'll notice there are 4 different Lifecycle Stages :

The first three stages are called sequentially when the deployment is started : Install, Start and Configure. If you don't enter a script for one of these, it is simply skipped.
The last one, "Uninstall" gives you the possibility to run a script when you "teardown" an existing software deployment. In our example, this will be useful to de-register our Monitoring Agent from the main Monitoring console, before destroying the VM :

Let continue with our example and input a script that will install our monitoring agent at the "Install" stage :

Finally, let's include our "Uninstall" script :

And we're good to go!

 

Using the Software Components you create

Before we can include this in a blueprint, we need to publish it :

 

Now when we create a new Blueprint in vRA, we can drag and drop our new Software Component on the Converged Blueprint Designer's canvas and all is well in the world :

 

A few more notes on Software Components :

– You can even include exit codes in your scripts to voluntarily fail the Software Component deployment if things go wrong. For example, for bash script, all you need to do is return a non-zero value and that will force the deployment to fail. The vRA documentation has a short and sweet table explaining this at the bottom of this page.

– You can use Software Components as dependencies, either by playing around with the "Container" field mentioned earlier to have Software Components depending on other Software Components, or you can have VMs depend on the successful deployment of a Software Component before beginning their provisioning.

 

The Bottom Line

If you were even a little familiar with the way Application Authoring worked in vRealize Automation 6, you know that VMware has made major improvements to Software Components and in doing so, gave us yet another reason to take a serious look at adopting vRA. There is always room for improvement though, hopefully VMware brings back some sort of integration with Puppet, (which did exist in vRA6) to again, take Software Deployment with vRA to the next level.