Salt, or SaltStack, is a remote execution tool and configuration management system, based on the community-sourced Salt platform. The remote execution capabilities allow administrators to run commands on various machines in parallel with a flexible targeting system. The configuration management functionality establishes a client-server model to quickly, easily, and securely bring infrastructure components in line with a given policy.
Architecture
The architecture of SaltStack is designed to work with any number of servers, from local network systems to other deployments across different data centers. Architecture is a simple server/client model with the needed functionality built into a single set of daemons.
Take a look at the following illustration. It shows the different components of SaltStack architecture. 
Roles
To understand how saltstack works, learn the machine roles and understand it, it helps to understand more about the how to query information about minion and how to using salt modules.
Master
Salt master is the machine/node that controls the complete infrastructure and trigger the policies for the servers it manages. It operates both as a repository for configuration data and as the control center that initiates remote commands and ensures the state of your other machines.
While it is possible to control infrastructure using a masterless configuration, most setups benefit from the advanced features available in the Salt master. Also it can operate in a tiered master configuration where commands can be relayed through lower master machines.
Minions
The servers that Salt(manager) manages are called minions. The minion is responsible for executing the instructions sent by the master, reporting on the success of jobs, and providing data about the underlying host.
How Salt communicates?
By default, Salt executes commands from the Master on Salt minions. Communications between a master and minions occurs over the ZeroMQ message bus. ZeroMQ messaging library provides extremely high performance network communication between parties, allowing Salt to send messages and data at rapid speeds. SaltStack modules communicate with the supported minion operating systems. The Salt Master runs on Linux by default, but any operating system can be a minion, and currently Windows, VMware vSphere and BSD Unix variants are well-supported.
And Salt master can send the command over SSH also, if you would like to setup agentless infrastructure. But it degrades performance quite considerably and can lead to complications with other Salt commands in some instances. So it is highly recommended that you use the salt-minion daemon where possible for performance, security, and simplicity.
Terminology
Before starting learning or getting hand dirty, we should always learn the terminologies, which will make us to work on flow and familiarize. Salt has many powerful features, but it can be difficult to match names with their functionality at first.
- execution modules – ad hoc commands
- grains – static information about minions
- pillar – secure user-defined variables stored on master and assigned to minions (equivalent to data bags in Chef or Hiera in Puppet)
- formulas (states) – representation of a system configuration, a grouping of one or more state files, possibly with pillar data and configuration files or anything else which defines a neat package for a particular application.
- mine – area on the master where results from minion executed commands can be stored, such as the IP address of a backend webserver, which can then be used to configure a load balancer
- top file – matches formulas and pillar data to minions
- runners – modules executed on the master
- returners – components that inject minion data to another system
- renderers – components that run the template to produce the valid state of configuration files. The default renderer uses Jinja2 syntax and outputs YAML files.
- reactor – component that triggers reactions on events
- thorium – a new kind of reactor, which is still experimental.
- beacons – a little piece of code on the minion that listens for events such as server failure or file changes. When it registers on of these events, it informs the master. Reactors are often used to do self healing.
- proxy minions – components that translate Salt Language to device specific instructions in order to bring the device to the desired state using its API, or over SSH.
- salt cloud – command to bootstrap cloud nodes
- salt ssh – command to run commands on systems without minions
Compare other CM’s term
If you are familiar with other CM’s tools like chef and puppet, here we have sort-out some comparison between the terms across the tools.
| Salt | Chef | Puppet |
| state | resource | resource |
| states | recipes | manifests |
| formula* | cookbook | module |
| pillars | databags | hiera |
| grains | ohai | facter |
*forumla – formulas are more like 3rd party cookbooks in Chef, there doesn’t seem to be an equivalent concept of packaging related states together unless they are meant to be shared externally. Unlike Chef cookbooks or Puppet modules, which it is standard to create for grouping resources even if packaging for distribution is not intended.
Salt Commands
Salt provides a number of commands to take advantage of the components outlined above. There is some significant crossover in terms of functionality between these tools, but we’ve attempted to highlight their primary functions below.
- salt-master: This is the master daemon process. You can start the master service with this command directly, or more typically, through an init script or service file.
- salt-minion: Likewise, this is minion daemon process, used to communicate with the master and execute commands. Most users will also start this from init scripts or service files.
- salt-key: This tool is used to manage minion public keys. This tool is used to view current keys and to make decisions about public keys sent by prospective minions. It can also generate keys to place on minions out-of-band.
- salt: This command is used to target minions in order to run ad-hoc execution modules. This is the main tool used for remote execution.
- salt-ssh: This command allows you to use SSH as an alternative to ZeroMQ for the transport mechanism.
- salt-run: This command is used to run runner modules on the master server.
- salt-call: This command is used to run execution modules directly on a minion you are logged into. This is often used to debug problematic commands by bypassing the master.
- salt-cloud: This command is used to control and provision cloud resources from many different providers. New minions can easily be spun up and bootstrapped.
There are some other commands as well, like salt-api, salt-cp, and salt-syndic, which aren’t used quite so often.