Mastering SaltStack: A Practical Guide to Automated Operations

Automation Tool Comparison

Puppet is a comprehensive tool with a client‑server model, offering extensive modules and a simple CLI for installing and configuring packages across many operating systems.

Ansible focuses on simplicity and speed, requiring no agents on managed nodes and operating over SSH, with optional acceleration modes for large‑scale deployments.

SaltStack resembles Ansible in being CLI‑driven and using a push model; it can communicate via SSH or a dedicated minion agent, provides an asynchronous file server, and supports YAML state files and pillar data.

Summary : Puppet’s agent sync interval can be a drawback, Ansible’s SSH polling may not scale well, while Salt’s message‑queue architecture offers high performance for large production environments.

SaltStack Overview and Features

SaltStack is a C/S‑based centralized management platform. The master (server) controls minions (clients). It provides configuration management, remote execution, and monitoring, built on Python and ZeroMQ with modules such as pyzmq, pycrypto, pyyaml, etc.

Deploying SaltStack enables batch command execution, centralized configuration distribution, file distribution, system data collection, and package management across thousands of servers.

Key Features

Easy deployment and use

Supports most UNIX/Linux and Windows environments

Centralized master‑minion management

Powerful, extensible configuration

Certificate‑based authentication (secure)

API and custom module support via Python

SaltStack Architecture and Working Principle

Each minion generates a key pair on startup; the public key is sent to the master for verification, establishing encrypted communication via ZeroMQ.

Communication flow:

Master receives a command and publishes a job ID.

Minion receives the job, processes it in a local thread, and returns results through the message bus.

Master records the results and the client can retrieve them.

Installation and Configuration

SaltStack requires the EPEL repository. Install the master and minion packages:

# yum -y install salt-master
# yum -y install salt-minion

Master configuration (/etc/salt/master)

user: root
worker_threads: 10
publish_port: 4505
ret_port: 4506
syndic_master_port: 4506
pidfile: /var/run/salt-master.pid
root_dir: /
log_file: /var/log/salt_master.log
nodegroups:
  group_all: '*'
file_roots:
  base:
    - /etc/salt/
pillar_roots:
  base:
    - /etc/pillar

Minion configuration (/etc/salt/minion)

master: mail
id: node1

Start services:

service salt-master start
service salt-minion start

Authentication Commands

# salt-key -L   # list all keys
# salt-key -a   # accept a key
# salt-key -A   # accept all keys
# salt-key -d   # delete a key
# salt-key -D   # delete all keys

Salt Command Usage

General syntax: salt [options] [targets] [function] [args] Example:

salt '*' cmd.run 'uptime'

Targeting Methods

Glob : default, uses shell wildcards (e.g., salt '*').

PCRE : regular expressions (e.g., salt -E '^[m|M]in.[e|o|u]n$' test.ping).

Subnet : specify an IPv4 address or CIDR (e.g., salt -S 192.168.0.42 test.ping).

Grains : match based on system facts (e.g., salt -G 'os:Ubuntu' test.ping).

Pillar : match using pillar data (e.g., salt -I 'my_val:my_val' test.ping).

Compound : combine selectors (e.g., salt -C 'web* or G@os:Arch' test.ping).

Nodegroup : predefined groups in /etc/salt/master (e.g.,

nodegroups:
  node: 'L@node1,node2'
# salt -N node test.ping

).

Common Modules

Status module – view system information:

# salt '*' status.diskstats   # disk info
# salt '*' status.meminfo     # memory info
# salt '*' status.w           # w command output

Listing all modules and their functions can be done with salt '*' sys.list_modules and salt '*' sys.doc <module>, illustrated by the following screenshots:

Grains

Grains are static pieces of information collected by a minion at startup (e.g., OS, CPU architecture). They are used for targeting, configuration, and information queries. Grains can be defined in /etc/salt/grains, /etc/salt/minion, or via the master’s _grains directory, with the latter having the highest priority.

Pillar

Pillar data is defined on the master, scoped per‑minion, and encrypted for secure transmission. It is ideal for sensitive data (SSH keys, certificates) and dynamic variables. Pillar files are stored under pillar_roots and referenced in SLS files.

State System

Salt states (SLS files) describe the desired configuration of a system. The top.sls file serves as the entry point, mapping environments to target minions and associated state files. Applying states automates package installation, service management, and file deployment.