SLS files

SLS stands for SaLt State, which was the first type of file inside Salt to use this kind of file structure. While they can be rendered in a number of different formats, by far the widest use is the default, YAML. Various templating engines are also available to help form the YAML (or other data structure) and again, the most popular is the default, Jinja.

Keep in mind that Salt is all about data. YAML is a serialization format that in Python, represents a data structure in a dictionary format. When thinking about how SLS files are designed, remember that they are a key/value pair: each item has a unique key, which is used to refer to a value. The value can in turn contain a single item, a list of items, or another set of key/value pairs.

The key to a stanza in an SLS file is called an ID. If no name inside the stanza is explicitly declared, the ID is copied to the name. Remember that IDs must be globally unique; duplicate IDs will cause errors.

Tying things together with top files

Both the State and the Pillar system use a file called top.sls to pull the SLS files together and serve them to the appropriate Minions, in the appropriate environments.

Each key in a top.sls file defines an environment. Typically, a base environment is defined, which includes all the Minions in the infrastructure. Then other environments are defined that contain only a subset of the Minions. Each environment includes a list of the SLS files that are to be included. Take the following top.sls file:

base:
  '*':
    - common
    - vim
qa:
  '*_qa':
    - jenkins
web:
  'web_*':
    - apache2

With this top.sls, three environments have been declared: base, qa, and web. The base environment will execute the common and vim States across all Minions. The qa environment will execute the jenkins State across all the Minions whose ID ends with _qa. The Web environment will execute the apache2 State across all the Minions whose ID starts with web_.

Organizing the SLS directories

SLS files may be named either as an sls file themselves (that is, apache2.sls) or as an init.sls file inside a directory with the SLS name (that is, apache2/init.sls).

SLS files may be hierarchical, and there is no imposed limit on how deep directories may go. When defining deeper directory structures, each level is appended to the SLS name with a period (that is, apache2/ssl/init.sls becomes apache2.ssl). It is considered best practice by developers to keep a directory more shallow; don't make your users search through your SLS tree to find things.