In case you missed the announcement from last year that VMware acquired SaltStack you can read more about that here. In this blog I am super excited to be able to present and discuss our how vRealize Automation 8.3 will have deeper integration with SaltStack (now named SaltStack Config) from a product perspective. Our vRealize Automation 8.x customers have been entitled to download SaltStack Config as a separate appliance and use that product, however now with vRealize Automation 8.3 customers will see SaltStack Config as another service, similar to Cloud Assembly or Code Stream for example.

When you click on the SaltStack Config tile it will open up the SaltStack Config interface. It is simple and easy to get started with this powerful configuration management tool now and start building out your infrastructure. In this blog I am going to go over some highlights of this new integration and show how it can be used. If you want to read about some use cases for SaltStack Config then I wrote a blog here you can check out.

Configuring vRealize Suite Lifecycle Configuration Manager with SaltStack Config

With the vRealize Suite Lifecycle Configuration Manager(vRSLCM) 8.3 you can now add SaltStack Config to the vRealize Automation set of services. In order to do that go into vRSLCM and go to Manage Environments. Then choose the vRealize Automation 8.3 tile and click on the three dots. Then choose Add Product and you will see a SaltStack Config Tile.

Once you click the Add Product you will see a list of tiles. Choose SaltStack config and go through the wizard to install it.

Once you have completed the installation of SaltStack Config you will then see the SaltStack Config service tile in vRealize Automation 8.3.

Navigating the SaltStack Config Interface

Like I mentioned before when you click on the SaltStack Config tile the interface for SaltStack Config will open up. If you are familiar with the SaltStack Enterprise (now SaltStack Config) interface then the functionality is the same, just some of the menu items will be located in different areas. But you will still see things like file server, jobs, activity, pillars, minions etc.

The left hand navigation bar provides access to the minions that are under management. If you click Minions then you can see a list of minions that are currently registered with the SaltStack Config system. Note that the SaltStack Config appliance that was deployed acts as a Salt “Master” so minions can register with it.

If you click on a minion then you will see Grains and Activity that are related to that minion. Grains are essentially metadata about the minion in a key/value pair format. There are many out-of-the-box grains like OS, fqdn, cpuarch and much more, and you can also create custom grains as well. The Activity section will show any jobs and/or commands run against that minion.

Another important area of the interface to note is Config –> File Server. This section is where you will create your state files for jobs, orchestration and reactors. SaltStack Config still uses the “base” structure (default) to provide an intuitive and powerful tree structure within the interface to provide an elegant method to call files from various state files and have state files interact with other state files. For example you can create subdirectories where you can put configuration files for example and then point to that location from a state file. This may be helpful when installing a database or apache webservers for example. The example below shows how sample directory structure for the apache deployments.

That was just a quick tour of a couple of important areas within the interface. Let’s jump into how vRealize Automation Cloud Assembly works with SaltStack Config now as well.

Cloud Assembly and Deploying Minions

Next we will discuss some steps to deploy minions via vRealize Automation and then have them auto-register with the SaltStack Config master system. Within Cloud Assembly there are some additional enhancements that have been in made to help with the minion deployment process. One of those enhancement is Property Groups.

Within Cloud Assembly there are Property Groups, if you go to Design –> Property Groups you will see a built-in property group called “SaltStackConfiguration”. Within this property group are two Constant Value properties: masterAddress and masterFingerPrint. These will be automatically configured to point to the SaltStack Config appliance that was deployed via vRSLCM.

These properties then can be used within Cloud Assembly Cloud Templates in order to install the minion onto a machine being deployed via Cloud Assembly. Then once the minion is registered with SaltStack Config then you can take advantage of configuration management features like orchestration, state management and software delivery. Below is an example of a Cloud Template using cloud-config to configure the minion on the machine (notice I did not need the master fingerprint property just yet, we will discuss that in a part 2 blog).

inputs: 
  environment:
    type: string
    enum:
      - Production
      - Development
resources:
  LinuxVM-Minion:
    type: Cloud.vSphere.Machine
    properties:
      name: salt-minion-vra
      cpuCount: 1
      totalMemoryMB: 2048
      imageRef: 'https://build-artifactory.eng.vmware.com/symphony-infra-local/ubuntu/releases/xenial/release-20190605/ubuntu-16.04-server-cloudimg-amd64.ova'
      cloudConfig: |
        #cloud-config
        runcmd:
          - curl -L https://bootstrap.saltstack.com -o install_salt.sh
          - sudo sh install_salt.sh -A ${propgroup.SaltStackConfiguration.masterAddress}
          - sudo salt-call grains.set env ${input.environment} # example to pass grains
      remoteAccess:
        authentication: publicPrivateKey
        sshKey: ssh-rsa your-public-key
      networks:
        - network: '${resource.vSphere_Network.id}'
  vSphere_Network:
    type: Cloud.Network
    properties:
      networkType: existing

Whenever a minion tries to register with the Saltstack Config master the default operation is for an administrator to manually accept the key that was generated on the minion. This operation will then allow SaltStack Config to manage the minion and run jobs against it. However it is possible to set some orchestration rules that will be kicked off via a Reactor file that provide auto-acceptance of a minion based on certain criteria. SaltStack Config is an Event driven configuration management platform, so the Reactor looks at the event bus for certain Events to respond to with orchestration. For example the Reactor file below is looking for ‘salt/auth’ events, those types event indicate that a minion is trying to authenticate with the SaltStack Config master. The Reactor file has instructions to then look a the ‘accept-key.sls’ Reactor state file for further instructions.

The Reactor state file ‘accept-key.sls’ can use jinja to further refine the filtering of which minions should be accepted. In the example below, only minions with ‘id’s that starts with dev or oc-cool will be auto-accepted and registered with the SaltStack Config master.

If you do not want to use cloud-init to install the minion there is an alternative approach documented here. The referenced blog will explain how to use ABX to install the minion on both Windows and Linux.

I am really excited about this deeper UI integration between SaltStack Config and vRealize Automation 8.3. I am also excited that our vRealize Automation customers have SaltStack Config to provide powerful configuration management capabilities along with all the other goodness vRealize Automation brings to our customers. Look out for much more SaltStack Config blogs and videos in the future!