What is SaltStack & Tutorial? | All You Need to Know-FREE

Last updated on 09th Jul 2020, Blog, Tutorials

SaltStack is an open-source configuration management and remote execution engine. It remotely executes commands across all machines. It is a python based software. Thomas S Hatch is the creator and the principal architect of SaltStack. SaltStack uses the ZeroMQ messaging library to process high-speed requirements for all networking layers. Salt is simple, scalable and fast. This tutorial will explore the basic principals of SaltStack, SaltStack setup, Minion file system and tan walk through with remote execution steps, configuration management, cloud management, Python API operations and finally conclude with a complete working example

What is SaltStack?

Salt is a very powerful automation framework. Salt architecture is based on the idea of executing commands remotely. All networking is designed around some aspect of remote execution. dis could be as simple as asking a Remote Web Server to display a static Web page, or as complex as using a shell session to interactively issue commands against a remote server. Salt is an example of one of the more complex types of remote execution

Salt is designed to allow users to explicitly target and issue commands to multiple machines directly. Salt is based around teh idea of a Master, which controls one or more Minions. Commands are normally issued from teh Master to a target group of Minions, which then execute teh tasks specified in teh commands and then return teh resulting data back to teh Master. Communications between a master and minions occur over teh ZeroMQ message bu

SaltStack modules communicate wif 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. The Salt Master and the minions use keys to communicate. When a minion connects to a master for the first time, it automatically stores keys on the master. SaltStack also offers Salt SSH, which provides an “agent less” systems management.

Need for SaltStack

SaltStack is built for speed and scale. This is why it is used to manage large infrastructures with tens of thousands of servers at LinkedIn, WikiMedia and Google.

Imagine dat you have multiple servers and want to do things to those servers. You would need to login to each one and do those things one at a time on each one and then you might want to do complicated things like installing software and then configuring dat software based on some specific criteria.

Let us assume you have ten or maybe even 100 servers. Imagine logging in one at a time to each server individually, issuing the same commands on those 100 machines and then editing the configuration files on all 100 machines becomes very tedious task. To overcome those issues, you would love to update all you’re servers at once, just by typing one single command. SaltStack provides you exactly the solution for all such problems.

Features of SaltStack

SaltStack is an open-source configuration management software and remote execution engine. Salt is a command-line tool. While written in Python, SaltStack configuration management is language agnostic and simple. Salt platform uses teh push model for executing commands via teh SSH protocol. Teh default configuration system is YAML and Jinja templates. Salt is primarily competing wif Puppet, Chef and Ansible.

Salt provides many features when compared to other competing tools. Some of these important features are listed below.

Fault tolerance 

Salt minions can connect to multiple masters at one time by configuring the master configuration parameter as a YAML list of all the available masters. Any master can direct commands to the Salt infrastructure.

Flexible 

The entire management approach of Salt is very flexible. It can be implemented to follow the most popular systems management models such as Agent and Server, Agent-only, Server-only or all of the above in the same environment.

Scalable Configuration Management 

SaltStack is designed to handle ten thousand minions per master.

Parallel Execution model 

Salt can enable commands to execute remote systems in a parallel manner.

Python API 

Salt provides a simple programming interface and it was designed to be modular and easily extensible, to make it easy to mold to diverse applications.

Easy to Setup 

Salt is easy to setup and provides a single remote execution architecture that can manage the diverse requirements of any number of servers.

Language Agnostic 

Salt state configuration files, templating engine or file type supports any type of language.

Benefits of SaltStack

Being simple as well as a feature-rich system, Salt provides many benefits and they can be summarized as below −

Robust 

Salt is powerful and robust configuration management framework and works around tens of thousands of systems.

Authentication 

Salt manages simple SSH key pairs for authentication.

Secure 

Salt manages secure data using an encrypted protocol.

Fast 

Salt is very fast, lightweight communication bus to provide teh foundation for a remote execution engine.

Virtual Machine Automation 

The Salt Virt Cloud Controller capability is used for automation.

Infrastructure as data, not code 

Salt provides a simple deployment, model driven configuration management and command execution framework.

architecture of SaltStack

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.

• SaltMaster 

SaltMaster is the master daemon. A SaltMaster is used to send commands and configurations to the Salt slaves. A single master can manage multiple masters.

• SaltMinions 

SaltMinion is the slave daemon. A Salt minion receives commands and configuration from the SaltMaster.

• Execution 

Modules and Adhoc commands executed from the command line against one or more minions. It performs Real-time Monitor

• Formulas

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 

Grains is an interface dat provides information specific to a minion. Teh information available through teh grains interface is static. Grains get loaded when teh Salt minion starts. This means dat teh information in grains is unchanging. theirfore, grains information could be about teh running kernel or teh operating system. It is case insensitive.

• Pillar 

A pillar is an interface dat generates and stores highly sensitive data specific to a particular minion, such as cryptographic keys and passwords. It stores data in a key/value pair and the data is managed in a similar way as the Salt State Tree.

• Top File 

Matches Salt states and pillar data to Salt minions.

• Runners 

It is a module located inside the SaltMaster and performs tasks such as job status, connection status, read data from external APIs, query connected salt minions and more.

• Returners 

Returns data from Salt minions to another system.

• Reactor 

It is responsible for triggering reactions when events occur in you’re SaltStack environment.

• SaltCloud 

Salt Cloud provides a powerful interface to interact with cloud hosts.

• SaltSSH 

Run Salt commands over SSH on systems without using Salt minion.

Salt Machine Roles

Salt’s control structure is fairly simple as configuration management systems go. In a typical setup, there are only two distinct classes of machines.

Master

The Salt master is the machine that controls the infrastructure and dictates 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. A daemon called salt-master is installed on the master to provide this functionality.

While it is possible to control infrastructure using a masterless configuration, most setups benefit from the advanced features available in the Salt master. In fact, for larger infrastructure management, Salt has the ability to delegate certain components and tasks typically associated with the master to dedicated servers. It can also operate in a tiered master configuration where commands can be relayed through lower master machines.

Minions

The servers that Salt manages are called minions. A daemon called salt-minion is installed on each of the managed machines and configured to communicate with the master. 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 Components Communicate

Salt masters and minions, by default, communicate using the ZeroMQ messaging library. This provides extremely high performance network communication between parties, allowing Salt to send messages and data at rapid speeds. Because ZeroMQ is a library and not an independent service, this functionality is available in the salt-master and salt-minion daemons natively.

When using ZeroMQ, Salt maintains a public key system for authenticating masters and minions. Upon first boot, a minion generates a key pair and sends its credentials to the master server it is configured to contact. The master can then accept this key after verifying the identity of the minion. The two parties can then communicate quickly and securely using ZeroMQ encrypted with the keys.

If for some reason it is impossible to install the salt-minion daemon on a node, Salt can also issue commands over SSH. This transport option is provided for convenience, but it degrades performance quite considerably and can lead to complications with other Salt commands in some instances. It is highly recommended that you use the salt-minion daemon where possible for performance, security, and simplicity.

Salt Terminology

Before diving into Salt, it is a good idea to familiarize yourself with some of the terminology that will be used. Salt has many powerful features, but it can be difficult to match names with their functionality at first. Let’s take a look at some of the more general terms you are likely to see.

Remote Execution: Execution Modules and Functions

Salt attempts to provide a distinction between its remote execution and configuration management functions. The remote execution capabilities are provided by execution modules. Execution modules are sets of related functions that perform work on minions.

While Salt includes functions that allow you to run arbitrary shell commands on minions, the idea behind execution modules is to provide a concise mechanism for executing commands without having to “shell out” and provide detailed instructions about how to complete the process. The use of modules allows Salt to abstract the underlying differences between systems. You can get similar information from minions running Linux or BSD, even though the actual mechanisms to gather that data would be different.

Salt comes with a decent selection of builtin execution modules to provide out-of-the-box functionality. Administrators can also write their own modules or include community-written modules to extend the library of commands that can be executed on minion machines.

Configuration Management: States, Formulas, and Templates

The configuration management functionality of Salt can be accessed by creating repositories of configuration files. The files contained within these repositories can be of a few different types.

States and Formulas

The configuration management portion of Salt is primarily implemented using the state system.

The state system uses state modules, which are distinct from the execution modules described above. Fortunately, state and execution modules tend to mirror each other quite closely. The state system is aptly named, as it allows an administrator to describe the state that a system should be placed in. As with execution modules, most state modules represent functionality shortcuts and provide easy syntax for many common actions. This helps maintain readability and removes the necessity of including complex logic in the configuration management files themselves.

Salt formulas are sets of state module calls, arranged with the aim of producing a certain result. These are the configuration management files that describe how a system should look once the formula TEMPhas been applied. By default, these are written in the YAML data serialization format, which provides a very good middle ground between high-readability and machine-friendliness.

The Salt administrator can apply formulas by mapping minions to specific sets of formulas. Formulas can also be applied in an ad hoc manner as needed. Minions will execute teh state modules found within to bring its system in line with teh provided policy.

A good collection of Salt formulas created by the SaltStack organization and community can by found in this GitHub account.

Templates

Templating allows Salt formulas and other files to be written in a more flexible manner. Templates can use the information available about the minions to construct customized versions of formula or configuration files. By default, Salt uses the Jinja template format, which provides substitution functionality and simple logical constructs for decision making.

Renderers are the components that runs the template to produce valid state or configuration files. Renderers are defined by the templating format that constitutes the input and the data serialization format that will be produced as an output. Considering the defaults described above, the default renderer processes Jinja templates in order to produce YAML files.

Access Control System

An Access Control System provides options for a user for a group to execute a task with permissions. A Salt access control system is used to configure access to non-administrative control interfaces. You can apply this process to all the systems. This control helps the non-administrative users to execute the Salt commands.

Salt interfaces are of the following three types −

• Publisher ACL system
• External Auth system
• Peer system

Publisher ACL System

A Publisher ACL system allows access to the users other than root to execute Salt commands on minions from the master. The publisher ACL system is configured in the master configuration file via the publisher_acl configuration option.

External Auth System

The external auth system is used to provide access to execute salt commands on specific minions through external authorization system like PAM, LDAP, etc. This configuration file is defined in the master file as described below.

Peer System

Salt minions can pass commands using the peer interface. The peer interface is configured through the master configuration file either to allow minions to send commands from the master using the peer configuration section or to allow minions to execute runners from the master using the peer_run configuration.

Configuration management

Configuration management is one of the most significant concept in SaltStack. It is used to create a reusable configuration template, called a state. The state describes everything required to put a system component or an application into a non configuration.

Salt State

Salt state is a reusable configuration for a specific part of a system. States are easier to understand and described using a simple YAML.

Create a Salt State

Salt states are easy to create. Let us create a simple state in this chapter. Move to the directory “salt-vagrant-demo/saltstack/salt/” and create a file named samples.sls and add the following lines in it.

Apply Salt State

Now that we have created a state using the ‘.sls’ file and applied it by specifically calling it. Salt has a default state file called as the top.sls file. The top file is used to apply multiple state files to Salt minions. The top file describes where states should be applied. Well, States and the Top file work together to create the core of SaltStack’s configuration management capability.

Apply Batch Size

If you have a large number of connected minions, then you can limit how many systems are updated at once. It is performed by using the –batch-size option,

Salt State Functions

Salt state functions are used to install and configure applications on your remote system. Let us install a “Vim” package using the Salt state function.

Create and Apply State Function

Create a file named “sample.sls” under the directory “salt-vagrant-demo/saltstack/salt/sample.sls” and add the following

Salt State Testing

The test run is mandated by adding the “test = True” option to the states. The return information will show states that will be applied in yellow and the result is reported as ‘None’.

SaltStack ─ Pillar Component

Pillar is an essential component to make Salt states reusable. It is used to define secure data for minions assigned using targets. Salt pillar data stores values such as ports, file paths, configuration parameters and passwords.

Querying about and Assigning Information to Minions

In order to manage vast numbers of systems, Salt requires some information about each of the host systems. The templates described above can use data associated with each system to tailor the behavior of each minion. There are a few different systems in place to query about or assign this information to hosts.

Grains

Salt grains are pieces of information, gathered by and maintained by a minion, primarily concerning its underlying host system. These are typically collected by the salt-minion daemon and passed back to the master upon request. This functionality can be leveraged for many different purposes.

For instance, grain data can be used for targeting a specific subset of nodes from the pool of minions for remote execution or configuration management. If you want to see the uptime of your Ubuntu servers, grains allow you to target only these machines.

Grains can also be used as arguments for configuration changes or commands. For example, you can use grains to get the IPv4 address associated with the eth0 interface for a change to a configuration file or as an argument to a command.

Administrators can also assign grains to minions. For instance, it is fairly common to use grains to assign a “role” to a server. This can then be used to target a subset of nodes similar to the operating system example above.

Pillars

While it is possible to assign grains to minions, the vast majority of configuration variables will be assigned through the pillars system. In Salt, a pillar represents a key-value store that a minion can use to retrieve arbitrary assigned data. This functions as a dictionary data structure which can be nested or tiered for organizational purposes.

Pillars offer a few important advantages over the grain system for assigning values. Most importantly, pillar data is only available to the minions assigned to it. Other minions will not have access to the values stored within. This makes it ideal for storing sensitive data specific to a node or a subset of nodes. For instance, secret keys or database connection strings are often provided in a pillar configuration.

Pillar data is often leveraged in the configuration management context as a way to inject variable data into a configuration template. Salt offers a selection of template formats for replacing the variable portions of a configuration file with the items specific to the node that will be applying it. Grains are also often used in this way for referencing host data.

Mine

Salt mine is an area on the master server where the results from regularly executed commands on minions can be stored. The purpose of this system is to collect the results of arbitrary commands run on minion machines. This global store can then be queried by other components and minions throughout your infrastructure.

The Salt mine only stores the most recent result for each command run, meaning that it will not help you if you need access to historic data. The main purpose of the mine is to provide up-to-date information from minion machines as a flexible supplement to the grain data that is already available. Minions can query data about their counterparts using the mine system. The interval in which the minion refreshes the data in the mine can be configured on a per-minion basis.

Additional Functionality

Salt provides a few other systems that do not fit nicely into the above categories.

Reactors

The Salt reactor system provides a mechanism for triggering actions in response to generated events. In Salt, changes occurring throughout your infrastructure will cause the salt-minion or salt-master daemons to generate events on a ZeroMQ message bus. The reactor system watches this bus and compares events against its configured reactors in order to respond appropriately.

The main goal of the reactor system is to provide a flexible system for creating automated situational responses. For instance, if you have developed an auto-scaling strategy, your system will automatically create nodes to dynamically meet your resource demands. Each new node would trigger an event. A reactor could be set up to listen to these events and configure the new node, incorporating it into the existing infrastructure.

Runners

Salt runners are modules that execute on the master server instead of minions. Some runners are general purpose utilities used to check the status of various parts of the system or to do maintenance. Some are powerful applications that provide the ability to orchestrate your infrastructure on a broader scale.

Returners

Salt returners are used to specify alternative locations where the results of an action run on a minion will be sent. By default, minions return their data to the master. A returner allows the administrator to re-route the return data to a different destination. Typically, this means that the results are returned to the destination specified by the returner and to the process that initiated the minion command.

Most often, returners will pass the results off to a database system or a metrics or logging service. This provides a flexible method for getting arbitrary data into these systems. Returners can also be used to collect Salt-specific data like job caches and event data.

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 a 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.

Conclusion

Now that you are familiar with the basic SaltStack terminology and have a high level understanding of what the tools you’ll encounter are responsible for, you can begin setting up Salt to control your infrastructure. In the next guide, we will cover how to install and configure a Salt master server on an Ubuntu 14.04 server. We will also demonstrate how to configure new minion servers to bring them under your master’s management.