SaltStack Config has provided our customers with lots of value as they manage their infrastructure and deploy applications and services. However here at VMware we are always working to “free” up our customers from day-to-day management of software, so I am excited to announce that we now have a Web Hosted offering of SaltStack Config. Essentially vRealize Automation Cloud Customers can open a ticket via the VMware Cloud Services Portal and then request a SaltStack Hosted instance by following the instructions here.
One of the primary use cases of SaltStack Config is to provide a view of the Salt infrastructure (controllers and minions) from a single UI. This is helpful since admins can then run and/or schedule jobs from the UI across their infrastructure and much more.
The use case for the SaltStack Config hosted version is not much different, basically we host the appliance and you just connect your salt-controllers to it. Then you can use vRealize Automation Cloud Assembly to deploy minions to the salt-controllers and SaltStack Config can provide a UI and job management.
Let’s dive a bit deeper into how this works.
Architecture Overview
The simplest explanation of the architecture is that VMware will host the SaltStack Config appliance for your organization. Then you as the customer would then deploy salt-controllers on-prem or in the cloud, then connect those salt-controllers to the SaltStack Config instance in the traditional method of installing and configuring the SSEAPE plugin on the controller. The SSEAPE plugin will tell the salt-controller to register with the SaltStack Config instance.
The SSEAPE plugin configuration file will require the DNS name of the SaltStack Config appliance. You can find this DNS name in vRealize Automation Cloud Assembly under Infrastructure–> Integrations.
The next step will be to open a ticket with VMware to “approve” the Public IPs of the salt-controllers you want connected to the SaltStack Config instance. This ticket can be opened from the same link above where you requested the SaltStack Config instance.
Once the salt-controller has been configured via the SSEAPE plugin to talk to the SaltStack Config Hosted instance then you will see the salt-controller show up in SaltStack Config under Administration–> Controller Keys:
So the architecture will look something like this where there are n salt-controller .
Deploy Minions and Apply States
Now that there are salt-controllers connected to the SaltStack Config Hosted instance, minions and state file can be deployed and applied. Then the SaltStack Config Hosted instance can manage the environment and be a source for your state file if desired. I say “if desired” because the state files could also be source controlled or pushed down to the file roots of the salt-controllers depending on how you want to architect the environment.
Within vRealize Automation Cloud Assembly there are a couple of ways to configure a virtual machine with the minion agent at time of deployment. Some of those options include cloud-init scripts, ABX actions/subscriptions and vRealize Automation Cloud Template YAML properties. In this blog I will focus on the cloud template YAML method. I recently wrote a blog explaining the YAML method here, so I won’t dive to deep into the topic in this blog.
The vRealize Automation Cloud Assembly cloud template could look something like this:
The vRealize Automation Cloud Template above basically will deploy a minion and assign the minionId to it (in this case I will input the minion id at deployment time) and then we are instructing SaltStack to run the /apache/init.sls state file which will install apache on the linux machine. The remote access is used for initial connection to the minion for agent installation.
Once the minion is deployed to my onprem-controller then it shows up in SaltStack Config under Minions:
Under Activity –> Completed section you will also see some jobs having been run:
The job with function state.apply applied the state file, the deploy.minion deploys the minion agent and the grains.items will list out the grains of the minion.
Conclusion and Considerations
Considering this SaltStack Config instance is hosted there are some considerations:
- There is no SSH access to the SaltStack Config instance at this time, although that is being worked out.
- Each salt-controllers will need to be “approved” since the SG will need to be modified.
- You will not deploy minions directly to SaltStack Config appliance but to salt-controllers.
Hope you enjoyed reading this and look out for future blogs on this topic as continue to provide more cloud consumption capabilities to SaltStack Config!
