SaltStack Tutorial

Recommended by 0 users

 SaltStack Tutorial

Reviewing a Few Essentials

Salt is a very powerful automation framework. Before we delve into the more advanced topics that this book covers, it may be wise to go back and review a few essentials. In this chapter, we will cover the following topics:

  • Using remote execution
  • Basic SLS file tree structure
  • Using States for configuration management
  • Basics of Grains, Pillars, and templates

Executing commands remotely

The underlying architecture of Salt is based on the idea of executing commands remotely. This is not a new concept; all networking is designed around some aspect of remote execution. This could be as simple as asking a remote Web server to display a static Web page, or as complex as using a shell session to interactively issue commands against a remote server.

Under the hood, Salt is an example of one of the more complex types of remote execution. But whereas most Internet users are used to interacting with only one server at a time (so far as they are aware), Salt is designed to allow users to explicitly target and issue commands to multiple machines directly.

Master and Minions

Salt is based around the idea of a Master, which controls one or more Minions. Commands are normally issued from the Master to a target group of Minions, which then execute the tasks specified in the commands and then return any resulting data back to the Master.

Targeting Minions

The first facet of the salt command is targeting. A target must be specified with each execution, which matches one or more Minions. By default, the type of target is a glob, which is the style of pattern matching used by many command shells. Other types of targeting are also available, by adding a flag. For instance, to target a group of machines inside a particular subnet, the -S option is used:

# salt -S test.ping

The following are most of the available target types, along with some basic usage examples. Not all target types are covered here; Range, for example, extends beyond the scope of this book. However, the most common types are covered.


This is the default target type for Salt, so it does not have a command line option. The Minion ID of one or more Minions can be specified, using shell wildcards if desired.

When the salt command is issued from most command shells, wildcard characters must be protected from shell expansion:

# salt ‘*’ test.ping
# salt \* test.ping

When using Salt from an API or from other user interfaces, quoting and escaping wildcard characters is generally not required.

Perl Compatible Regular Expression (PCRE)

Short Option: -E

Long Option: –pcre

When more complex pattern matching is required, a Perl Compatible Regular Expression (PCRE) can be used. This type of targeting was added to the earliest versions of Salt, and was meant largely to be used inside shell scripts. However, its power can still be realized from the command line:

# salt -E ‘^[m|M]in.[e|o|u]n$’ test.ping


Short Option: -L

Long Option: –list

This option allows multiple Minions to be specified as a comma-separated list. The items in this list do not use pattern matching such as globbing or regular expressions; they must be declared explicitly:

# salt -L web1,web2,db1,proxy1 test.ping


Short Option: -S

Long Option: –ipcidr

Minions may be targeted based on a specific IPv4 or an IPv4 subnet in CIDR notation:

# salt -S test.ping
# salt -S test.ping

As of Salt version 2015.5, IPv6 addresses cannot be targeted by a specific command line option. However, there are other ways to target IPv6 addresses. One way is to use Grain matching.


Short Version: -G

Long Version: –grain

Salt can target Minions based on individual pieces of information that describe the machine. This can range from the OS to CPU architecture to custom information (covered in more detail later in this chapter). Because some network information is also available as Grains, IP addresses can also be targeted this way.

Since Grains are specified as key/value pairs, both the name of the key and the value must be specified. These are separated by a colon:

# salt -G ‘os:Ubuntu’ test.ping
# salt -G ‘os_family:Debian’ test.ping

Some Grains are returned in a multi-level dictionary. These can be accessed by separating each key of the dictionary with a colon:

# salt -G ‘ip_interfaces:eth0:’

Grains which contain colons may also be specified, though it may look strange. The following will match the local IPv6 address (::1). Note the number of colons used:

# salt -G ‘ipv6:::1’ test.ping

Grain PCRE

Short Version: (not available)

Long Version: –grain-pcre

Matching by Grains can be powerful, but the ability to match by a more complex pattern is even more so.

# salt –grain-pcre ‘os:red(hat|flag)’ test.ping


Short Option: -I

Long Option: –pillar

It is also possible to match based on Pillar data. Pillars are described in more detail later in the chapter, but for now we can just think of them as variables that look like Grains.

# salt -I ‘my_var:my_val’ test.ping


Short Option: -C

Long Option: –compound

Compound targets allow the user to specify multiple target types in a single command. By default, globs are used, but other target types may be specified by preceding the target with the corresponding letter followed by the @ sign:

Letter Target
G Grains
E PCRE Minion ID
P PCRE Grains
L List
I Pillar
S Subnet/IP address
R SECO Range

The following command will target the Minions that are running Ubuntu, have the role Pillar set to web, and are in the subnet.

# salt -C ‘G@os:Ubuntu and I@role:web and S@’ test.ping

Boolean grammar may also be used to join target types, including and, or, and not operators.

# salt -C ‘min* or *ion’ test.ping
# salt -C ‘web* or *qa,G@os:Arch’ test.ping


Short Option: -N

Long Option: –nodegroup

While node groups are used internally in Salt (all targeting ultimately results in the creation of an on-the-fly nodegroup), it is much less common to explicitly use them from the command line. Node groups must be defined as a list of targets (using compound syntax) in the Salt Master’s configuration before they can be used from the command line. Such a configuration might look like the following:

webdev: ‘I@role:web,G@cluster:dev’
webqa: ‘I@role:web,G@cluster:qa’
webprod: ‘I@role:web,G@cluster:prod’

Once a nodegroup is defined and the master configuration reloaded, it can be targeted from Salt:

# salt -N webdev test.ping

Using module functions

After a target is specified, a function must be declared. The preceding examples all use the test.ping function but, obviously, other functions are available. Functions are actually defined in two parts, separated by a period:

<module> . <function>

Inside a Salt command, these follow the target, but precede any arguments that might be added for the function:

salt <target> <module>.<function> [arguments…]

For instance, the following Salt command will ask all Minions to return the text, “Hello world”:

salt ‘*’ test.echo ‘Hello world’

A number of execution modules ship with the core Salt distribution, and it is possible to add more. Version 2015.5 of Salt ships with over 200 execution modules. Not all modules are available for every platform; in fact, by design, some modules will only be available to the user if they are able to detect the required underlying functionality.

For instance, all functions in the test module are necessarily available on all platforms. These functions are designed to test the basic functionality of Salt and the availability of Minions. Functions in the Apache module, however, are only available if the necessary commands are located on the Minion in question.

Execution modules are the basic building blocks of Salt; other modules in Salt use them for their heavy lifting. Because execution modules are generally designed to be used from the command line, an argument for a function can usually be passed as a string. However, some arguments are designed to be used from other parts of Salt. To use these arguments from the command line, a Python-like data structure is emulated using a JSON string.

This makes sense, since Salt is traditionally configured using YAML, and all JSON is syntactically-correct YAML. Be sure to surround the JSON with single quotes on the command line to avoid shell expansion, and use double quotes inside the string. The following examples will help.

A list is declared using brackets:


A dictionary is declared using braces (that is, curly brackets):


A list can include a dictionary, and a dictionary can include a list:


There are a few modules which can be considered core to Salt, and a handful of functions in each that are widely used.


This is the most basic Salt command. Ultimately, it only asks the Minion to return True. This function is widely used in documentation because of its simplicity, and to check whether a Minion is responding. Don’t worry if a Minion doesn’t respond right away; that doesn’t necessarily mean it’s down. A number of variables could cause a slower-than-usual return. However, successive failed attempts may be cause for concern.


This function does little more than the test.ping command; it merely asks the Minion to echo back a string that is passed to it. A number of other functions exist that perform similar tasks, including test.arg, test.kwarg, test.arg_type, and test.arg_repr.


0 Responses on SaltStack Tutorial"

Leave a Message

Your email address will not be published. Required fields are marked *

Copy Rights Reserved © Mindmajix.com All rights reserved. Disclaimer.
Course Adviser

Fill your details, course adviser will reach you.