Master SaltStack: From Basics to Advanced Automation in Minutes

SaltStack Automation Introduction

SaltStack is a C/S architecture automation platform where the server side is called Master and the client side is called Minion. Communication uses ZeroMQ pub/sub over ports 4505 (publish) and 4506 (request). Both Master and Minion run as daemons and listen on these ports. Authentication uses RSA keys and AES encryption.

SaltStack Operation Modes

Local

Master/Minion

Salt SSH

Three Main Functions of SaltStack

Remote execution (run commands on remote hosts)

Configuration management (state management)

Cloud management

1. SaltStack Overview

1. Simple Introduction

SaltStack follows a client‑server model with Master and Minion communicating via ZeroMQ. The Master listens on ports 4505 and 4506, while Minions connect to the Master and authenticate using RSA keys.

2. Communication Model

Salt uses a publish‑subscribe pattern. Minions initiate connections, so no inbound ports need to be opened on the managed systems. The Master uses port 4505 for publishing messages and port 4506 for receiving requests.

Publisher (port 4505) receives continuous connections from all Minions. Commands are sent asynchronously to all connected Minions.

Request Server (port 4506) handles one‑to‑one connections for file transfers and pillar data.

3. Salt Minion Authentication

When a Minion starts for the first time it searches for a Salt Master, performs a handshake, and sends its public key. The Master must accept the key with salt-key before the Minion can execute commands. After acceptance, the Master sends an AES key encrypted with the Minion’s public key.

2. SaltStack Installation

1. Add YUM Repository

wget -P /etc/yum.repos.d https://mirrors.aliyun.com/saltstack/yum/redhat/7.6/x86_64/saltstack-rhel7.repo

2. Install Master

yum -y install salt-master

3. Install Minion

yum -y install salt-minion

3. SaltStack Configuration

On the Master edit /etc/salt/master:

master: 10.0.100.132
user: root
interface: 0.0.0.0
file_roots:
  base:
    - /srv/salt
pillar_roots:
  base:
    - /srv/pillar

Start the Master: systemctl start salt-master On the Minion edit /etc/salt/minion to point to the Master:

master: 10.0.100.132
user: root
id: agent1

Start the Minion:

service salt-minion start

Key Management

# sudo salt-key --list-all
# salt-key --accept=<key>
# salt-key --accept-all
# salt-key -d <key>
# salt-key -D

Testing Remote Execution

# salt '*' test.ping
# salt 'agent1' cmd.run 'df -h'
# salt -L 'agent1,agent2' cmd.run 'uptime'
# salt -S '192.168.122.0/24' cmd.run 'uptime'

4. Configuration Management Practice

Create directories for states and files:

# mkdir /srv/{salt,pillar}
# cd /srv/salt
# vim host_file.sls

Example state to manage /etc/hosts:

/etc/hosts:
  file.managed:
    - source: salt://files/hosts
    - user: root
    - group: root
    - mode: 644

Apply the state:

# salt '*' state.sls host_file

Copy Files

# salt-cp '*' /etc/hosts /root

Install Nginx via State

nginx-install:
  pkg.installed:
    - names:
      - nginx

/etc/hosts:
  file.managed:
    - source: salt://files/hosts
    - user: root
    - group: root
    - mode: 644
    - require:
      - pkg: nginx-install

service.running:
  - names:
    - nginx

Install Apache via State

apache-service:
  pkg.installed:
    - names:
      - httpd
      - mod_ssl
  service.running:
    - name: httpd
    - enable: True

Schedule Tasks (Cron)

/usr/sbin/ntpdate time.aliyun.com >> /dev/null:
  cron.present:
    - user: root
    - minute: '*/5'

List cron on a Minion:

# salt '*' cron.list_tab root

State vs. Highstate

state.sls runs a specific SLS file in the default base environment without reading top.sls. state.highstate reads top.sls for all environments and applies all defined states.

5. Regex Matching Hosts

Use regular expressions with the -E option or in top.sls with match: pcre.

6. Grains (Client‑Side Data)

Grains collect system information on Minions. Common commands:

# salt '*' grains.ls
# salt '*' grains.items
# salt '*' grains.item os_family
# salt '*' grains.item ipv4

Custom grains can be defined in /etc/salt/minion:

grains:
  roles:
    - webserver
    - dbserver
  deployment: datacenter1
  cabinet: 13
  cab_u: 14-15

7. Pillar (Server‑Side Data)

Pillar stores configuration data such as passwords or version numbers. Define roots in /etc/salt/master and create YAML files under /srv/pillar:

pillar_roots:
  base:
    - /srv/pillar

Example pillar file env_salt01.sls:

roles:
  - webserver
  - dbserver
deployment: datacenter1
cabinet: 13
cab_u: 14-15

Reference pillar data in states or target Minions with -I or --pillar.

8. Remote Execution Targeting

Targeting options include globbing, regex, list, subnet/IP, grains, pillar, compound matchers, and node groups. Examples:

# salt 'salt01.tianyun.com' test.ping
# salt 'salt01*' test.ping
# salt -L 'salt01,salt02' cmd.run 'uptime'
# salt -S '10.0.100.0/24' test.ping
# salt -G 'os:CentOS' cmd.run 'uptime'
# salt -I 'Zabbix_Server' test.ping

9. States (Configuration Language)

States are written in YAML (or Python) to describe desired system state. Example LAMP stack state:

lamp-pkg-install:
  pkg.installed:
    - names:
      - httpd
      - php
      - php-mysql
      - php-gd
      - gd
      - mariadb-server

httpd-files:
  file.managed:
    - name: /etc/httpd/conf/httpd.conf
    - source: salt://files/httpd.conf
    - require:
      - pkg: lamp-pkg-install

httpd-service:
  service.running:
    - name: httpd
    - enable: True
    - require:
      - file: httpd-files
    - watch:
      - file: httpd-files

mysql-files:
  file.managed:
    - name: /etc/my.cnf
    - source: salt://files/my.cnf

mysql-service:
  service.running:
    - name: mariadb
    - enable: True

Use require, watch, require_in, and watch_in to define dependencies and reactions.

10. LAMP Deployment (dev Environment)

Define a dev environment in /etc/salt/master and create states under /srv/salt/dev. Apply with:

# salt '*' state.sls lamp saltenv=dev

11. State Relationships

Key relationship directives:

require : this state depends on another state.

require_in : another state depends on this one.

watch : monitor another state; if it changes, this state is refreshed (e.g., restart).

watch_in : this state is watched by another state.