With any growing deployments of any kind, the need to support a non-production environment is vital. To separate out develoment environments from production environments. It's becoming the rule to build multi-stage environments.
SaltStack supports building multistage environments directly out of the box. In this edition, we'll set up a multistage cluster, a development environment and a production environment. These environments will be isolated entirely from each other, but share the same salt-master.
Another possible way to build environments into SaltStack would be to build entirely isolated clusters from each other, with completely separate masters-minions, so know you do have options. SaltStack will keep sensitive data to each environment isolated from each other in this setup we're discussing. This particular setup has the added benefit that you can allow the different environments to share common code.
In order to fully participate in this chapter, it's important that you understand the master-minion relationship and how the
top.sls works inside of SaltStack. If you are ready to proceed, let's jump right on in.
We'll be setting up our infrastructure by keeping our particular directories for our environments separate. Start by building the following folder structure:
/ /common /states /pillars /development /states /pillars /production /states /pillars
rsync this to your server in the
/srv/salt directory (in this case, the default location), that'll give the salt-master the file structure:
/srv/salt /common /states /pillars /development /states /pillars /pillars /states /pillars
With that file structure in place, we can then configure out saltmaster to build state trees around the environment. To do this, we'll edit the
/etc/salt/master configuration to include the concept of
environments, like so:
# `/etc/salt/master` file_roots: base: - /srv/salt/common/states development: - /srv/salt/development/states production: - /srv/salt/production/states pillar_roots: base: - /srv/salt/common/pillars development: - /srv/salt/development/pillars production: - /srv/salt/production/pillars
This will tell the salt-master to only deliver data back to the minion in the appropriate environment. In the
lowstate, the compilation phase salt-master will give out the appropriate files based upon the requesting minion environment.
With the configuration out of the way, let's move to on actually using these environments:
In this setup, the top.sls file is a crucial component that will govern what minions have access to which data. In a single-stage environment, it is perfectly acceptable to have a top.sls file that looks something like:
base: '*': - core '*web*': - nginx '*db*': - mysql
This will tell SaltStack only to create a single state tree. In order to support multistage environments, we'll need to partition our top files against our
pillar_roots. To do that, we'll isolate the environments in our
base: - core development: '*web*': - nginx '*db*': - mysql production: '*web*': - nginx '*db*': - mysql
This will target minions based upon their
id. Sometimes this is useful and appropriate, but other times it's not. When it's not useful or we are setting our environments in another way, such as in grains, we'll need to match on something else.
To match on grains (see our section on role-based environments for more information on setting custom grains), we can support the following:
base: - core development: 'G@environment:development and role:web': - match: compound - nginx 'G@environment:development and role:db': - match: compound - mysql production: 'G@environment:production and role:web': - match: compound - nginx 'G@environment:production and role:db': - match: compound - mysql
By setting up our environment this way, we can fluidly move our resources around based upon the different environments.