I have written a few blog articles about vRealize Automation SaltStack Config (although it has been a while) and I referenced a method of using the reactor system within SaltStack Config to auto accept keys and deploy software when deploying from vRealize Automation. Essentially admins could either use cloud-init or ABX to do the initial minion agent installation, then the SaltStack Config reactor would auto-accept the key based on some criteria and then the reactor could kick off some orchestration to apply state files.
The method I described is still relevant, however in vRealize Automation 8.4.1 we have now introduced additional vRealize Automation Cloud Template YAML properties for SaltStack minion configurations. This allows Cloud Admins to easily configure a Cloud Template to deploy a minion agent, run a state file and add additional parameters all from built in YAML properties.
Before I deep dive into this feature lets review some prerequisites:
- vRealize Automation 8.4.1
- SaltStack Config 8.4.1
- SaltStack Config must be vRA Integrated via vRealize Suite Lifecycle Manager
- FQDN name resolution must be working from minion to controller
- SSH access to the minion (SSH is used to remote access into the minion to deploy the agent).
Now that we have that out of the way, let’s look at this exciting new feature in more detail.
vRealize Automation Cloud Template YAML Properties for SaltStack Config
Within a vRealize Automation 8.4.1 Cloud Template there are some properties that can be defined for deploying minions and running state files. Lets define these properties and then see how they work.
| masterid | Salt Controller id to which the salt minion is to be connected, could be the SaltStack Config Server or a controller connected to it. |
| minionid | Assign a minion id to the system, this is what will show up in SaltStack Config as the identifier of the minion |
| saltEnvironment | Specify which salt environment to pull state file from |
| pillarEnvironment | Tell it which environment to pull pillar from |
| stateFiles | List of state files to run on deployed minion |
| additionalMinion params | Additional configuration parameters for salt minion |
| additionalAuth params | Additional authentication parameters passed in for provisioning salt minion (e.g., master_port: 8000) |
| variables | Parameters that may be required by the state file to run on the deployed minion (e.g., role: admin) |
Here is an example vRealize Automation Cloud Template that is configured to deploy the minion and run a couple of state files.
Notice the remoteAccess property that is part of the Cloud.vSphere.Machine properties. The system will use those credentials to SSH into the machine and deploy the minion. You can use vRealize Automation Cloud Templates “secrets” repo to store sensitive passwords if you wish.
In the YAML example above the masterId is set to saltstack_enterprise_installer because that is the default master id for the SaltStack Config system. The masterId could also point to an id for a master that is connected to the SaltStack Config system. SaltStack Config can manage multiple salt masters via the GUI. For more about the reference architecture of SaltStack Config go here.
The stateFiles property can be a list of state files that you want to run on the minion. State Files declare the state of the system and ensure state as well, they are typically written in YAML (and python). The path will be dependent on both the saltEnvironment (base & sse are default environments) and the general path to the state file from within the base or sse environment as an example. For instance your path could be:
Managing Minion Deployments
Once the minion is deployed you can view some logs and see information in both vRealize Automation and SaltStack Config.
From within vRealize Automation deployment history tab you can see informational logs that come from SaltStack Config about the minion agent being deployed and any state files that were run.
From within SaltStack Config interface you can look at the Activity section and see the minion deployment was run as well.
If you ran a state file during the minion deployment then you will see a job that applied the module/function state.apply. Once you click on that job you can see the return data that came from the minion and if the job was successful or not.
As of vRealize 8.4.1 the key will not automatically be accepted when the minion registers. So you will need create a acceptkey.conf file in the /etc/salt/master.d directory with the values auto_accept: True, then restart the master service service salt-master restart. This method is best for non-prod or test environments.
For production environments you can use the reactor based wheel.key accept method I discuss in this blog.
The key acceptance is scheduled to be available in the upcoming release and will negate the need for the .conf file or the reactor based wheel.key accept in most situations.
Also note that using the YAML method with Windows is still a work in progress. I will write up another blog about that once that feature is available.
Thanks for reading and hopefully this method of deploying minions with built-in YAML properties from the vRealize Automation Cloud Template will accelerate your software and machine deployments!
