VMware Aria Automation Config Cloud Automation SaltStack Config VMware vRealize Automation Cloud vRealize Automation

Getting Started with SaltStack Config – Creating State Files

So you got SaltStack Config installed and now you want to get started with running scripts, installing apps, manage state and much more. But how and where to begin? I am going to be writing a multi-part blog series on how to get started. We will journey from writing your first state files for Windows and Linux machines to building out Orchestration across the environment using SaltStack Config.

First I want to preface that this blog is not the only resource out there to help you get started with SaltStack Config. I have listed a few at the bottom of this blog and I would recommend you check out those resources as well.

So let’s jump into some things you can do to get started once you have SaltStack Config up and running!

Deploy a Couple of Minions

In this blog I am going to be working with minions, and regular Linux and Windows minions to be more specific. I am not going to jump into how to use proxy minions for network devices as I will save that for a later blog.

So first things first, we need a couple of minions, preferably a Linux and/or Windows minion. However if you just want to focus on Linux for example that is fine too.

You can use vRealize Automation Cloud Assembly to deploy a couple of test minions or you can install the minion agent onto some test machines using the instructions from the SaltStack Repo.

Once deployed you should see them in your SaltStack Config UI under minions.

Windows Packages and States

SaltStack has something called a winrepo, it is basically a system that utilizes a software repository to install packages on Windows systems.

To first get the winrepo configured, first install pygit2 or gitpython on the salt controller.

Then run the command to install the repo on the salt controller :

salt-run winrepo.update_git_repos

Navigate to /srv/salt/win/repo-ng/salt-winrep-ng and do a directory listing. You will see a number of state files (sls) that are used to install packages on Windows systems. These are pulled from a repo and you can add package state files as well as modify the files that are there.

Take a look at one of the state files via cat or vi and take a look at the contents. Basically the winrepo-ng uses Jinja to add some logic to the file.

From here you can do a couple of things to apply these state files to your Windows minion. You can write a state file in the Config–> File Server section of SaltStack Config and list the packages that you want to apply to the Windows systems. Basically just enter the name of the sls file without the sls extension.

Create a job to call the state file you created in the File Server. To do that go to Config–>Jobs and click Create. Then create a job with Function state.apply and look for the state file you just created.

After you run the job you can check the status of the job in the Activity –> Completed section.

You cannot directly call winrepo state files from a job via state apply. They are called via pkg.install so a state file would be a better method.

The other method I mentioned in the parenthesis is that you can apply these winrepo state files via the CLI and remote execution. As an example:

salt -G 'os:Windows' pkg.install 'vscode'

There are some other things you can do with Windows as well besides just installing packages. You can also write state files to modify local group policy or handle patches and much more. Let’s look at a quick example of a local group policy state file.

In the SaltStack Config File Server in Config–> File Server create a state file that can set local group policy.

Then create a job to call that state file you just created:

Click on your Windows minion and then choose “Run Job” choose the Windows Policy job you just created. Click Run Now.

Then go to Activity –> Completed and ensure the job ran successfully.

I was not trying to confuse you by offering multiple ways to run jobs and create state files, but I was more hoping it would help you learn to navigate the interface and start to understand how you can do things in a logical way.

Well so far we have installed some software and did some group policy stuff on Windows. Let’s see how we can work a bit with that Linux minion.

Linux Package Management

Let’s just jump right into creating state files to do things on our Linux minion. First lets install redis and ensure the service is running.

Go to Config–> File Server and create a state file to install redis and start the service.

    - name: redis
    - name: redis

Go to Config–>Jobs and create a job to run the state file you just created.

After you run the job check out the Activity –> Completed section and look at the job results.

Highstate and Top Files

Within SaltStack there is a concept called highstate, I will not go into the exact definition of highstate here but I will talk about one of the applications of applying a highstate. That application is a method of calling a Top File.

A Top File (top.sls) basically allows admins to declare a number of state files that need to be run against certain minions when a highstate is executed. These state files are generally designed to apply a “state” or maintain a “state” across an entire environment. So for instance if you want to ensure that all ‘webservers’ have a certain firewall config, then you could create a top.sls file that ensures any minions that would fall into the ‘webservers’ category would get the appropriate state files applied to ensure the firewall config state is applied. “Whew…”

I felt it was important to include a mention and present an example of the top.sls here in the State file blog because it can bring some high level application of the state file to your environment. Let’s look at a quick an easy example.

From within SaltStack Config create a file in Config–>File Server and call it “top.sls” and put it right into the root of the base environment. Something like this:

We put into the root of base because in sseapi (SSC file roots) the root base is our “file roots”. If you were to put your top file directly on a controller it would (by default) go into /srv/salt.

If you run a state.apply (with no state file provided) or state.highstate it will run this top file.

The top file will then run the redis state file against all minions with grain = os:Ubuntu.

So there you have it. A first look at state files and hopefully a springboard to helping you start configuring minions. In the next blog in the series I am going to touch on running scripts and more advanced states. Thanks for reading!

Additional Resources:

Great Tutorial:


State KB: https://docs.saltproject.io/en/latest/topics/tutorials/starting_states.html

Using the SaltStack Config File Server: