vRealize Automation SaltStack Config - Part 1

As you may be aware VMware acquired SaltStack to bolster it’s Software Configuration Management and Infrastructure Automation.

Now with vRealize Automation 8.5 just being released, the integration of SaltStack Config into vRA is getting better and better. So I thought it might be a good time to go through how easily and powerful, consuming SaltStack Config state files within the context of a vRealize Automation Cloud template can be.

If you want a quick tutorial on SaltStack Config, I recommend going over to the VMware Blog site where Vincent Riccio has a tonne of posts about how to get started.

Also a shout out to Rob Robertson for helping me out on this little project.

In this post, I’m going to explain a few concepts within the world of SaltStack Config, and how to use them to deploy a multi tier application. So let’s begin..

First thing, This is a visual representation of what we are going to go through.

The first thing we want to do is configure our vRA cloud template to define the SaltStack Config properties.

  masterId: saltstack_enterprise_installer
  saltEnvironment: base
    - /configureMinion/kickStart.sls
    webMinion: '${resource.Web_Machine.resourceName}'
    app: '${input.linux_fields.applications}'

The main properties to make sure you have on all your machine resource objects are:

masterId & saltEnvironment.

The other properties we have defined in the cloud template are specifically for our Database Machine. This is what will be the single entry point into SaltStack Config, where we will execute a state file called kickStart.sls and also pass two variables into that state file. Variables are referred to as Pillars in SaltStack Config.

More info on Pillars found here

Next, we need to write our kickStart state file. This single state file has a few simple tasks to complete.

  1. Get the Id (or Hostname) of the minion that we are running this state on. This might sound odd, however at the time that this state file runs, we don’t have all the properties about our workload from Cloud Assembly, so we have to work this one out on the fly. This shows us how easily it is to get Grains (think ootb properties about our Salt Minion directly from SaltStack Config)
    More info on Grains found here
  2. Get the variables passed in from our vRA cloud template
  3. Copy the base mine.conf configuration file onto our minion
  4. Restart the Minion, to pick up the latest mine.conf configuration file and
  5. Finally, fire off an event with the context of the application we want installed. This is where the Salt Master Reactor and Orchestration takes over.

The Salt Mine is away for Salt Minions to get information about other Minions from the Salt Master. It’s configurable to only be the information you want to be exposed. More info on the Salt Mine found here


So let’s see how the Salt Master picked up the event that we just triggered.

On the Salt Master, there is a file in the master.d dir that tells the Salt Master what type of events to look out for and what to do when we see one.
To understand more about SaltStack Config Reactor click here

From the code below, you can see that our master is looking for any events with the tag ‘salt/softwareBuild/*‘. This means that when our kickStart.sls file executes an event with the name salt/softwareBuild/{{applicationToInstall}} , the Salt Master will see that event and react to it, by executing our application-install.sls file.



In our example above, the wild card was replaced with moad.

Note: you don’t need to specify the full path to a state file (if the file name is “init.sls”). SaltStack Config will automatically look in the directory specified (i.e. moad in the Env: Base directory) and pick up the init.sls file.

Okay, so now we are getting into how SaltStack Config orchestration takes over.

The orchestrate runner generalizes the Salt state system to a Salt Master context. Whereas the state.sls functions are concurrently and independently executed on each Salt minion, the state.orchestrate runner is executed on the master, giving it a master-level view and control over requisites, such as state ordering and conditionals. This allows for inter minion requisites, like ordering the application of states on different minions that must not happen simultaneously, or for halting the state run on all minions if a minion fails one of its states.

The orchestration file example below is a pretty simple use case but shows how powerful SaltStack Config can be. You can execute multiple states, have dependencies between those states and/or pass data inbetween states.

So lets see how that works. In our example we want 3 main processes to run:

  1. Wait for the database minion to be back online. Due to SaltStack Config being extremely fast, we need to confirm that the reboot we triggered back in the kickStart state has completed.
  2. Run the moad.db sls file. This does 3 main tasks:
    1. Creates a user
    2. Installs dependent packages
    3. Configures the mysql instance
  3. Run the moad.web sls file. Again, another 3 tasks
    1. Creates a user
    2. Installs dependent packages
    3. Configures the Web/App instance and connects to the mysql instance by it’s ip address.

What’s really powerful about SaltStack Config is within this example of a orchestration file, I can use requisites to make sure certain states don’t execute until other states have completed, as well as pass Pillar data to the underlying state files.

To learn more about requisites click here

init.sls (orchestration state file)



This is just a few examples of how to work with SaltStack Config work. How to use States, Events, Pillar, Requisites and Orchestration.

SaltStack Config is more than just a config management tool, it’s a complete management framework.

I will be posting more about SaltStack Config over the coming weeks.

All files from this post can be found here: