In this chapter you will learn how to better organize those files using topfiles in the state system and learn about environment in Salt.

You will learn how to organize your states so that we can enforce the state of your infrastructure with just a single remote execution command.

• How to use topfiles in the state system to target state files to different minions
• How to use environments to further organize our state files
• How to use GitFS to store our state files in version control

The highstate

Until now, we have only been running a single state file at a time using state.sls. We want to be able to split different pieces of our state into different files to make them more modular. How can we accomplish this?

Topfiles can also be used in the state system to target different state files to different minions.

Let's create our topfile now to state files.

Under /srv/salt/ create a top.sls file:

base:
  '*minion':
   - apache
  'os_family: debian':
   - match: grain
   - users_and_ssh

<aside> 💡 Note that if a minion is not targeted in the top.sls file at all, it will return an error when state.highstate is run.

</aside>

This file is structured almost exactly like the topfile that we used for our pillar data:

• First line defines the environment. There will be more later on, but for now the default env is enough: base
• Within the env we define a series of targeting strings: '*minion', in this case, will target all minions that end in * minion.
• The second targeting ('os_fam(...)) means that it is using grain matching using the -match: grain keyword

The complete set of state files included in the topfile is referred to as the highstate. Thus, it shouldn't surprise you that we use the remote execution function, state.highstate, to run the highstate.

Environments

Salt provides a concept of environments to further organize our states. We can configure as many environments as we need to organize our infrastructure and give each environment its own location in the filesystem.

<aside> 💡 Here, we're using the example of different environments fulfilling different roles: maybe we would have an environment for our web servers, an environment for our database servers, and so on. However, we could have an environment for production, an environment for development, and an environment for staging. Many users of Salt don't use the concept of environments at all and instead just organize everything within their base environment. This is also a perfectly valid use of environments, though it is recommended that you use directories to structure and separate the various pieces of your infrastructure to keep things organized.

</aside>

Under etc/salt/master → File Server Settings we can define the path for different environments according to our needs. For example, we can define the base env under /srv/salt and the webserver env under /srv/web.

file_roots
  base:
   - /srv/salt
  webserver:
   - /srv/web

After every env is creating according to our needs, we must move the correspondent state and top files inside each env folder.