SaltStack Architecture and Getting Started with Salt

This article will focus on SaltStack Architecture and how you can use it in your environment.  I will cover the SaltStack overall design, steps to install it, and just some of the way you can use it in your environment.

The SaltStack Architecture is easy to learn and install, especially if you already know one of the other configuration management packages.  SaltStack (or just Salt) is a Python-based, open-source configuration management platform and remote execution engine.  It competes primarily with Puppet, Chef, and Ansible but this article will not compare these products.  I will create a separate article that will just focus on comparing each one in detail.

It can be designed in several ways but I will cover the simple master-minion setup since that will fit easily in my lab.

Let’s get started.

Key Terms

• Salt-Master: The node used control your salt-minions across your infrastructure. Salt-masters will push a desired state down either manually or automatically.
• Salt-Minion: The node that is controlled by a Salt-Master.
• Salt-State: Salt state is a set of instructions passed down to a node. It could be anything from placing an SSH key, downloading yum packages or removing users access.  The core of the Salt State system is the SLS, or Salt State file. The SLS is a representation of the state in which a system should be in, and is set up to contain this data in a simple format. This is often called configuration management.
• Formula:  Salt Formulas are pre-written Salt States. They are as open-ended as Salt States themselves and can be used for tasks such as installing a package, configuring, and starting a service, setting up users or permissions, and many other common tasks.
• Grains:  Salt grains are bits of data collected and stored about the minions.  This is information about the IP address, server name, OS version and such data.  Grains can be used in scripts when targeting minions.
• Pillars: Pillars are tree-like structures of data defined on the Salt Master and passed through to minions. They allow confidential, targeted data to be securely sent only to the relevant minion similar to a Salt grain.
• Reactor:  An interface for listening to events and defining actions that Salt should taken upon receipt of given events.
• Runner Module:  A module containing a set of runner functions.
• Runner Function:  A function which is called by the salt-run command and executes on the master against one or more minions.
• API Daemon:  This daemon will listen for commands from sources other than the shell.

SaltStack Architecture

The SaltStack architecture is very simple, secure, and scalable.  You can have a single master (most common), multi-Master (for redundancy), or master/Syndic configuration.

A single master is most common and simple to setup.  I will go into how to setup the master below.

In larger deployments, you can configure Syndic servers to relay messages between minion and master.  This will reduce the load on the single master.

For very large deployments, a multi-master design would be better and can accommodate the loss of one of the masters and still allow for remote management.

As with all the other configuration management platforms, the Salt master servers are deployed on Linux based servers.  Windows or Unix clients are natively supported but there are also ways to manage other types of devices.

Salt is an agent based tool.  It has a client agents (called minion) that must be installed and will establish communications with the master.  It will use encrypted TCP channels so it is very secure.

Salt is using the ZeroMQ message based protocol so it is very lightweight compared to other communication methods and uses TCP port 4505 and 4506.

Installing Salt

Installing Salt will vary slightly depending on your platform.  The install below will be for Unix but details for other operating systems can be found on the Salt Documentation website.

If you want to use FQDN, please make sure all the server names are in DNS and can be resolved from all servers before using it with Salt.

I will be testing on Ubuntu and here are the commands I will be using in my lab.

Installing Salt on the Master

This will download the Salt package from the internet so your machine will need to be Internet facing for the below commands to work.  You will also need to have root level access to the servers to complete the installation.

Download Salt

curl -L https://bootstrap.saltstack.com -o install-salt.sh

Install Salt Master:

sudo sh install-salt.sh -M -A 127.0.0.1

The [-M] tells the system to configure as a master, the [-A] tells the software where the master is (in this case, we are the master to it is looking at local loop), and [-I] for the minion ID which could be the minion FQDN.

Start Salt

I find it best to start the master after you accept all keys but it will work both ways.

sudo service salt-master start

sudo service salt-master status

Install Salt Client (Minion):

The client (Minion) setup will be very similar to the master one we just did but with a few command differences below.

Download Salt

curl -L https://bootstrap.saltstack.com -o install-salt.sh

Install Salt Client

sudo sh install-salt.sh -A master-fqdn

 

Accept Minion Keys on Master

Before you can communicate between the master and minion, the SSL keys need to be accepted on the master server.  Make sure you confirm the keys match between the master and minion before you accept them.

List Keys

sudo salt-key

Accept keys

sudo salt-key -a <Server Name>

(Server Name or IP, whatever is listed in results of salt-key command)

 

Testing Communications between Master and Minion

To test communication between Master and Minion, run the salt ping command.

From Master

sudo salt '*' test.ping

If the server is communicating with the master, it will return “True.  If False, there is a problem.

Salt can also use the following when issuing commands:

• Unix Filename Wildcards
• (-E) Regular Expressions
• (-S) Network IP Address / Subnet (/16 or /24)
• More available too
• (-C) Compound will mix expressions ‘S@IP and E@(servername)’

Salt Remote Execution Commands

Once the master and minions are connected, you can run commands on the master that are executed on any or all of the minions. This is the Remote Execution piece.

You can also define states which can cause configuration to be applied and validated on minions. Configuration meaning users, directories, files, firewall, services, and so forth. This is the “Configuration Management” piece.

The states file is located in /srv/salt/top.sls and will control which servers will have which packages and configurations.  The top.sls file is written in YAML.

Not to dig too deep into the YAML method but to give you an idea.  The files are written in a hierarchical way.  Here is an example:

uptodate:
  pkg.uptodate:
    - refresh: True

Then just issue the patch command like below and replace the * with the servers you want to patch.  very easy to do and quick.

sudo salt '*' pkg.upgrade

if you want to run a random command on a remote server, here is an example of something you can use:

salt '*' cmd.run 'command arg1, arg2, arg3'

Since this is just an introduction, I will stop here with possible commands but you get the picture and understand the power of salt.

Salt can be used for state configuration where each server will validate itself to a standard you define (in top.sls).  It will also can be used for batch changes that you create and execute from the master.  Lastly, it can also be used for smaller isolated command line commands to run commands remotely.

For the complete list of commands and modules you can run, check out the salt documentation site noted below.

The Salt Commands page will list all available salt commands you can run (Salt-*)

The Execution Modules page will have all the predefined modules we can run.

Salt Grains

Salt grains are bits of information collected about a minion.

sudo salt servername grains.items

This command will return details about the software, hardware, and configuration of a minion server.  You can also add or delete this information to fit your needs.

As you will probably guess, you can use grains to better target your scripts.  You can also use this information inside your scripts to better deploy changes.

Grains (and Pillars) really gives salt a lot of power and since it is very customizable, you can basically do just about anything with it.

For private information, you can store the data in a salt pillar.  Pillars are stored in a different directory and configured separately from the salt directory scripts.

Conclusion

I hope this introduction to the SaltStack Architecture was helpful.  This article was designed to be a small introduction to salt and not a ‘How to use Salt’ post.  I plan to write other articles about similar packages as well as more detailed articles about salt so you can get a good understand of the products and compare the major players in the field.

Please feel free to leave any comments and questions below and I will do my best to answer them.  In the future, I plan to create additional articles about how to script in YAML and how to use Salt on Windows and VMware.

Don’t forget to signup for our email list to be the first to know when I create these new articles on Salt or other automation technologies.