What is Salt?

  • Salt is a distributed remote execution system used to execute commands and query data on remote nodes, either individually or by arbitrary selection criteria
  • Salt is a configuration management system, capable of maintaining remote nodes in defined states (for example, ensuring that specific packages are installed and specific services are running, or specific hardware box is running specific OS with specific configuration)

It was developed in order to bring the best solutions found in the world of remote execution together and make them better, faster, and more malleable. Salt accomplishes this through its ability to handle large loads of information, and not just dozens but hundreds and even thousands of individual servers quickly through a simple and manageable interface.

Configuration management principles

There are a few principles that all configuration management tools have in common.

Convergence principle

Enforcing configuration on server at any state X leads always to state Y.

Convergence principle

Idempotence principle

Enforcing configuration on server at certain state Y leads back to state Y.

Idempotence principle

Configuration management models

There are the two main separation of configuration management tools where resources are described as a result state or as way to that state.

Declarative model

Declarative model describes what needs to happen, the minutiae for making it so are left to the system. For example:

The Sandwich I Desire.

There should be a sandwich on a plate in front of me in five minutes’ time. It should have only peanut butter and jelly between the two slices of bread.

Imperative model

In contrast, imperative model involves writing code that follows explicit steps to solving a problem, completing a task, or achieving a desired result. It’s telling the system specifically how to do something with the expectation that the desired outcome will result. For example:

Make me a Sandwich!

Spread peanut butter on slice of bread. Set this slice of bread on a plate, face-up. Spread jelly on another slice of bread. Place this second slice of bread on top of the first, face-down.

SaltStack components

The training covers these components in more detail, but it is helpful to a general idea of the role each component plays in SaltStack architecture.

SaltStack components overview
Component Schema Description
Salt Master Central management system, this system is used to send commands and configurations to the Salt Minion that is running on managed systems.
Salt Minions Managed systems receive commands and configuration from the Salt Master.
Execution Modules Ad hoc commands executed from the command line against one or more managed systems. Can be used for real-time monitoring and status, one- off commands and scripts or deploy critical updates
Formulas (States) A declarative or imperative representation of a system configuration.
Grains A declarative or imperative representation of a system configuration.
Pillar User-defined variables. These secure variables are defined and stored on the Salt Master and then ‘assigned’ to one or more minions using targets. Pillar data stores values such as ports, file paths, configuration parameters, and passwords.
Runners Modules that execute on the Salt Master to perform supporting tasks. Runners report job status, connection status, read data from external APIs, query connected Salt Minions, and more. For example, the Orchestrate runner coordinates configuration deployments across many systems.
Returners Send data returned by Salt Minions to another system, such as a database. Returners can run on the Salt Minion or on the Salt Master.
Reactor Trigger reactions when events occur in your SaltStack environment.
Salt SSH Run Salt commands over SSH on systems that do not have a Salt Minion.
Salt Minion Proxy Control remote devices through Salt proxy minions on systems that do not have a support for Python.