I am very excited to introduce our latest feature enhancement between vRealize Automation and SaltStack Config with the introduction of a SaltStack Config Resource Types for vRealize Automation Cloud Templates. Last year we introduced the saltConfiguration property into the Cloud Template YAML as part of a virtual machine set of properties. The saltConfiguration property was our first step providing SaltStack specific YAML code to deploy the minion agent and optionally running a state file on the minion at time of deployment from vRealize Automation.

The new SaltStack Config Resource Type takes this up a ‘notch’ by providing a drag-and-drop canvas object that can be associated with a virtual machine. This new feature will make it simpler and quicker to get started using SaltStack Config in conjunction with vRealize Automation for software and operating system configurations.

SaltStack Resource Type Overview

In case you are not familiar with a “resource type” in vRealize Automation let me explain it. A resource type is an object that can be dragged onto the Cloud Template canvas. This can be a virtual machine, network, load balancer, s3 bucket and much more. In the screenshot below the list of resource types are on the left and the objects can then be dragged onto the canvas.

Once the resource type object is dragged onto the canvas, the YAML code related to the object can then be modified. For instance a sample YAML snippet for the SaltStack Config resource type might look something like this:

Cloud_SaltStack_1:
type: Cloud.SaltStack
properties:
hosts:
- ${resource.Cloud_vSphere_Machine_1.id}
masterId: saltstack_enterprise_installer
stateFiles:
- /user/doe.sls
saltEnvironment: sse
variables:
user: joe

Let’s look at the properties of this resource type a bit more closely.

Also a remoteAccess property needs to be added to the virtual machine itself, this provides SSH/WinRM credentials so vRealize Automation can login to the machine and install the agent.

Now let’s look into how to use this new resource type.

Deploying Machines and States

So essentially the SaltStack Config Resource Type does the following:

• Deploys Minion Agent on the Virtual Machine at request time
• Installs a state file during deployment (optional)

The state file is a YAML or python file in SaltStack that is used to declare what you want to do with that minion. Such as turn off a firewall rule, patch a system, install a package and much much more.

When the machine is deployed this is what you will see in vRealize Automation.

When the Cloud_SaltStack_1 object is clicked, you can see some properties that came over with the deployment. Properties such as:

• The state file that ran on the minion
• The minions that were associated with the saltstack config resource type
• Any variables that were passed etc.

vRealize Automation also records logs from SaltStack Config in the History section of the deployment as well.

Note: When the deployment is deleted in vRealize Automation the minion will be deleted from SaltStack Config as well.

Now that the machine is deployed and things look competed in vRealize Automation, let’s look at what is happening in SaltStack Config.

SaltStack Config Activities

Since SaltStack Config is responsible to install the minion and run the states you will want to see the activity within the SaltStack Config interface to make sure everything looks good there too. When you go into the SaltStack Config interface you will see a section called Activities, when you click on that you should see a few activities if a single minion with a single state file was deployed.

There will be a deploy.minion job to get the minion agent onto the machine, a key.accept job which accepts the minion key, and the state.apply job to apply the state file specified in the Cloud Template. Looking at the state.apply job results we can see the state file ran and a user was added to the minion.

For reference here is the state file that was used to deploy the user in the example above.

{% set username = pillar.get('user', 'random') %}
friend:
user.present:
- names:
- {{username}}

Notice that the example is using the command pillar.get to reference the user variable that was in the Cloud Template YAML. When you pass variables along with the SaltStack Config Resource Type they are temporarily stored and accessible via pillar. The pillar.get command will retrieve the value that is associated with user variable in the Cloud Template. We use jinja to set a state file variable and associate that with the Cloud Template variable. This allows for the value to be propagated wherever the state file variable is being called. In the example above a state variable is set called username and then referenced in the names property.

Conclusion

The SaltStack Config Resource Type is only available in vRealize Automation 8.7 and above and in vRealize Automation Cloud. I hope you will find this exciting new feature super helpful in your journey to modernize and automate your infrastructure!