Salt Components

In the previous step, we discovered the features of Salt and the benefits of using Salt in continuous integration and continuous deployment.

In this step, we’ll explore Masters and Minions, the two main components of the SaltStack platform, as well as other components that empower the SaltStack platform.

Masters

Salt Master is a master component in Salt and is mainly responsible for sending commands and configurations to the Salt Minions to manage them. It can manage thousands of Minions and runs as a daemon.

Minions

A Salt Minion represents a managed system and is responsible for receiving and executing commands and configurations that a user sends via Salt Master.

Salt can be run in a masterless mode where only the Minion is used. The masterless mode is used to manage a single machine without the need for a Master. This mode is also called Standalone Minion.

Salt Minion runs as a daemon:

The Execution Module

Ad hoc commands are executed on the Minion to target one or multiple managed Minion systems to perform tasks such as updates, commands, script execution, and real-time monitoring.

Formulas

Formulas are pre-written Salt states. A formula could be either declarative or imperative, representing a system configuration. Formulas can be used to execute tasks such as managing configurations and services states or installing and managing system packages.

SaltStack maintains a central collection of Formula repositories where you can find formulas for software such as Vim, OpenSSH, Apache, Collectd, Zabbix, Docker, Kafka, Consul, Kibana, and many others.

Grains

Salt Grains are the interface to access static information about the Minion system, such as:

• Operating System
• Kernel
• Memory
• Network
• Packages.

Although this information can be found by default on the managed system, you can add your own Grains.

Pillars

Pillars are user-defined variables. They act as an interface to store and generate sensitive data specific to a Salt Minion. Sensitive data can be identified as passwords, cryptographic keys, ports, and tokens.

Pillars can also be used to store any other type of Minion data, such as variables and configurations. Pillars’ data is managed like the Salt State Tree.

The difference between a Grain and a Pillar is that a Pillar is stored in the Master and passed through to the Minion.

Top File

The role of Top File is mapping the Salt States to Minions. Without it, a Master will not know the states that should be applied to a given Minion. Some rules should be respected when using this file, such as setting the base environment to have at least one environment.

A Top File should define three components:

• The environment: The state tree directory where the Salt States can be found.
• The target: The group of targeted Minions to which States will be applied.
• The State files: These files describe the different states to apply to managed systems.

A Top File is named top.sls by default.

Writing state files requires knowledge about the Salt targeting system, which will be explained in detail later.

Example:

# Development environment
dev:
 #targeted minions
 'dev-webserver*':
 # A State file
 - webserver
 # Nginx Formula
 - nginx

# Live environment
prod:
 #targeted minions
 'webserver*':
 # A State file
 - webserver
 # Nginx Formula
 - nginx

Runners

Salt Runners are modules located inside the Master and are responsible for executing different tasks such as:

• Reporting job and connection status
• Interacting with external APIs
• Interacting with Minions.

The difference between Runners and the Salt Execution Modules is that a Runner executes on the Salt Master, not the Minion, but both are Python modules written in a similar way.

Returners

When a command is executed on a Minion, the latter returns the execution result to the Master. However, if you want to store this data to an external data store, you should use Salt Returners.

Salt Returners return data from Salt Minions to another external system such as MySQL or Redis. Salt Returners can be used on Salt Minion or Salt Master.

Reactors

Reactors are event triggers. When an event occurs in Salt, the Reactor system is responsible for triggering a reaction in response to this event.

Salt Reactors use the event bus to watch event tags and, if a tag matches a given pattern, the system runs a command in response.

Salt Cloud

Salt Cloud is a SaltStack interface for interacting with cloud providers such as Microsoft Azure. With Salt Cloud, the system administrator can provision systems and virtual machines on different cloud providers without leaving Salt.

Salt Cloud can be configured using YAML (a data-serialisation standard) files, and is designed to be an automated system.

Salt Cloud allows the creation of Cloud Minions by using maps and profile configurations. These Minions are assigned to a Master that will manage them.

Salt Cloud can interface with multiple private and public cloud providers and technologies such as OpenStack or Azure. System administrators can also add new providers that don’t exist, by default.

Salt SSH

Salt can run without any agent on the target system. The agentless mode uses SSH to execute commands. This component ensures that commands are running over SSH on targeted systems.

Salt SSH is very easy to use. Simply set up a basic roster file of the systems to connect to and run Salt SSH commands in a way similar to how you would run standard Salt commands.

Salt SSH uses a simple roster file. Here is an example:

server1:
 host: 192.168.10.1
 user: dev
 passwd: p@ssw0rd
 sudo: True # Whether to sudo to root, not enabled by default
server2:
 host: 192.168.42.2
server3:
 host: mydns.westus.cloudapp.azure.com