Introduction to SaltStack Automation Operations

SaltStack

• • 1. Introduction to SaltStack
• •
• • 1. Brief Introduction
• • 2. Communication Modes
• • 3. Salt Minion Authentication
• • 2. Installing SaltStack
• • 3. Configuring SaltStack
• • 4. Practical Introduction to Configuration Management
• • 5. Differences between state.sls and state.highstate in SaltStack
• • 6. Regular Expression Matching for Hosts
• • 7. Data System Grains (Client)
• • 8. Data System Pillar (Server)
• • 9. Remote Execution Targeting
• • 10. Configuration Management States
• • 11. Relationships in Configuration Management

==Official Website: https://docs.saltproject.io/en/latest/==

1. Introduction to SaltStack

1. Brief Introduction

SaltStack is a service model based on the C/S architecture, where the server side is called Master and the client side is called Minion. It also features a publish-subscribe (pub/sub) service model in the message queue, with Minions communicating with the Master via ZeroMQ message queues. Both Master and Minion run as daemon processes, continuously listening on the ports defined in the configuration file: ret_port (4506 for receiving Minion requests) and publish_port (4505 for ZMQ publishing messages). When a Minion runs, it automatically connects to the Master address defined in the configuration file on the ret_port for authentication. RSA Key is used for identity confirmation, and AES encryption is employed to ensure the security of the transmission.

SaltStack Operating Modes:

• • Local
• • Master/Minion
• • Salt SSH

Three Major Functions of SaltStack:

• • Remote Execution (Execute remote commands)
• • Configuration Management (State Management)
• • Cloud Management

2. Communication Modes

Salt uses a publish-subscribe model to communicate with managed systems. Connections are initiated by Salt Minions, meaning you do not need to open any incoming ports on these systems (thus reducing attack vectors). The Salt Master uses ports 4505 and 4506, which must be open to receive access connections.

The Publisher (port 4505) requires all Salt Minions to establish a persistent connection to the publisher port where they listen for messages. Commands are sent asynchronously through this port to all connected Minions, allowing commands to be executed simultaneously across many systems.

The Request Server (port 4506) allows Salt Minions to connect to the request server as needed, sending results back to the Salt Master and securely retrieving requested files or data values related to specific Minions (known as Salt Pillar). Connections to this port are 1:1 between the Salt Master and Salt Minion (not asynchronous).

3. Salt Minion Authentication

When a Minion starts for the first time, it searches the network for a system named “salt” (though this can easily be changed to an IP or different hostname). Upon discovery, the Minion initiates a handshake and sends its public key to the Salt Master. After the initial connection, the public key of the Salt Minions is stored on the server and must be accepted on the Salt Master using the salt-key command (or through some automated mechanism). This can confuse new users because Salt does not provide the security key needed to decrypt messages until the public key of the Salt Minions is accepted (which means Salt Minions will not execute any commands until their keys are accepted). After the Minion’s key is accepted by the Salt Master, the Salt Master returns its public key along with a rotating AES key, which is used to encrypt and decrypt messages sent by the Salt Master. The returned AES key is encrypted using the public key initially sent by the Salt Minion, so it can only be decrypted by that Salt Minion.

2. Installing SaltStack

1. Download the yum repository<span>wget -P /etc/yum.repos.d https://mirrors.aliyun.com/saltstack/yum/redhat/7.6/x86_64/saltstack-rhel7.repo</span>

2. Install on the Master side<span>yum -y install salt-master</span>

3. Install on the Minion side<span>yum -y install salt-minion</span>

3. Configuring SaltStack

Note: There should be a space after the colon#hostnamectl set-hostname salt01.tianyun.com#vim /etc/hosts

Initialize Configuration Configure the corresponding file paths

Master Side

# Modify and add in /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
systemctl start salt-master

Minion Side

# Add in /etc/salt/minion
# This should point to the salt-master server, which can be an IP, domain name, or hostname. If using an internal DNS server, you can use hostname or domain name.
master: 10.0.100.132
user: root
id: agent1

# Start
service salt-minion start

View All Keys

[root@master]# sudo salt-key --list-all  # salt-key -L 
Accepted Keys:
agent1
Denied Keys:
Unaccepted Keys:
Rejected Keys:

Accept a Specific Key

salt-key --accept=<key>
salt-key -a=<key>

Accept All Keys

salt-key --accept-all
salt-key -A -y

Delete a Specific Key

salt-key -d xxx

Delete All Keys

salt-key -D

Common Testing Remote Execution Introduction

[root@master]# salt '*' test.ping
agent1:
    True

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

Note:
The master key pair is stored by default in /etc/salt/pki/master/master.pub  /etc/salt/pki/master/master.pem
The public key authenticated by the master is stored in: /etc/salt/pki/master/minions/
The minion key pair is stored by default in /etc/salt/pki/minion/minion.pub  /etc/salt/pki/minion/minion.pem
The minion stores the master's public key in /etc/salt/pki/minion/minion_master.pub
The minion_id is stored by default in /etc/salt/minion_id #?

Detailed Explanation of Salt Commands

salt "*" sys.list_modules   # View all modules

# salt -h
Usage: salt [options] '<target>' <function> [arguments]

Options:
      --version : View the version number of SaltStack software.
      --versions-report : View the version numbers of SaltStack software and dependencies.
      -h, --help : View help information.
      --saltfile=SALTFILE: Specify the path of the saltfile. If not provided, it will search for one in the current working directory.
      -c CONFIG_DIR, --config-dir=CONFIG_DIR: Specify the directory of configuration files (default is /etc/salt/).
      -t TIMEOUT, --timeout=TIMEOUT: Specify the timeout, default is 5 seconds.
      --hard-crash: Do not exit on original exceptions, default is off.
      -s, --static: Return all minion data in a group format.
      -p, --progress: Display a progress bar, requires the progressbar Python package.
      --failhard: Stop batch processing after the first execution error.
      --async : Execute asynchronously.
      --subset=SUBSET : Execute the program on a random subset of target minions. Minions will verify if the named function exists before executing.
      -v, --verbose : Enable detailed command output, showing JID and active job queries.
      --hide-timeout : Hide timeout.
      --show-jid : Show the task's JID.
      -b BATCH, --batch=BATCH, --batch-size=BATC : Execute tasks by percentage.
      -a EAUTH, --auth=EAUTH, --eauth=EAUTH : Specify external authentication method.
      -T, --make-token : Generate master token.
      --return=RETURNER : Set an alternative method. By default, Salt will send returned data from the command back to the master server, but returned data can be redirected to any number of systems, databases, or applications.
      --return_config=RETURNER_CONF : Specify the configuration file for command returns.
      -d, --doc, --documentation : View documentation for specified or all modules.
      --args-separator=ARGS_SEPARATOR : Specify the separator for sending commands and command arguments when a command is to be sent as an argument to another command.
      --summary : Display summary information.
      --username=USERNAME : Specify the username for external authentication.
      --password=PASSWORD : Specify the password for external authentication.
      --metadata=METADATA : Pass metadata to Salt for job searching.
      
Logging Options:
      -l LOG_LEVEL, --log-level=LOG_LEVEL : Specify the log level.
      --log-file=LOG_FILE : Specify the log file.
      --log-file-level=LOG_LEVEL_LOGFILE : Log file logging level. 'all', 'garbage', 'trace', 'debug', 'info', 'warning', 'error','critical', 'quiet'. Default: 'warning'.

Target Options:
*     -E, --pcre : Regular expression matching.
*     -L, --list: List matching, target expressions will be interpreted as a comma-separated list.
*     -G, --grain: Grains matching.
      --grain-pcre : Grains with regular expression matching.
      -N, --nodegroup: Group matching.
      -R, --range: Range matching.
      -C, --compound : Compound matching (specifying multiple matches, separated by spaces).
*     -I, --pillar : Pillar value matching.
      -J, --pillar-pcre : Pillar with regular expression matching.
      -S, --ipcidr : Minions subnet address matching.

Output Options:
      --out=OUTPUT, --output=OUTPUT : Print output from the 'salt' command using the specified outputter. Built-in options are 'key', 'yaml', 'overstatestage', 'newline_values_only', 'pprint', 'txt', 'raw', 'virt_query', 'compact', 'json', 'highstate', 'nested', 'quiet', 'no_return'.

      --out-indent=OUTPUT_INDENT, --output-indent=OUTPUT_INDENT : Print output indented by the provided value in spaces. Negative values disable indentation. Only applies to outputters that support indentation.

      --out-file=OUTPUT_FILE, --output-file=OUTPUT_FILE : Output to the specified file.

      --out-file-append, --output-file-append : Append output to the specified file.

      --no-color, --no-colour : Disable all color display.

      --force-color, --force-colour : Force color display in output.

      --state-output=STATE_OUTPUT, --state_output=STATE_OUTPUT : Override the configured state_output value output, specifying the state format (full, terse, mixed, changes or filter) output, default is full.

salt-key Command Detailed Explanation:
# salt-key -h

Actions:
     -l ARG, --list=ARG: Display keys of the specified state (supports regular expressions)
     -L, --list-all : List all public keys. "--list all" has been deprecated.
     -a ACCEPT, --accept=ACCEPT: Accept the specified public key (in addition to pending keys, use --include-all to match rejected keys), supports regular expressions.
     -A, --accept-all : Accept all pending keys.
     -r REJECT, --reject=REJECT : Reject the specified pending key (supports regular expressions)
     -R, --reject-all: Reject all pending keys.
     --include-all: Display keys of all states.
     -p PRINT, --print=PRINT : Print the specified public key, supports regular expressions.
     -P, --print-all: Print all public keys.
     -d DELETE, --delete=DELET: Delete the specified key.
     -D, --delete-all: Delete all keys.
     -F, --finger-all: Display fingerprint information for all keys.

# Find modules
salt '*' -d|grep ":" |grep disk

# Find methods owned by a specific module
salt 'agent1' sys.list_functions test

4. Practical Introduction to Configuration Management

After configuring both the Master and Minion sides,

File Management

[root@master ~]# mkdir /srv/{salt,pillar}
[root@master ~]# cd /srv/salt
[root@master salt]# vim host_file.sls
/etc/hosts:
  file.managed:
    - source: salt://files/hosts
    - user: root
    - group: root
    - mode: 644
[root@master salt]# mkdir files
[root@master salt]# cd files/
[root@master files]# cp /etc/hosts .
[root@master files]# pwd
/srv/salt/files
[root@master files]# cd ..
[root@master salt]# pwd
/srv/salt
[root@master salt]# ls
files  host_file.sls
[root@master salt]# salt '*' state.sls host_file
agent1:
----------
          ID: /etc/hosts
    Function: file.managed
      Result: True
     Comment: File /etc/hosts is in the correct state
     Started: 18:15:50.497755
    Duration: 68.637 ms
     Changes:   

Summary for agent1
------------
Succeeded: 1
Failed:    0
------------
Total states run:     1
Total run time:  68.637 ms

Using the name method

[root@master salt]# vim host_file.sls
file_test:
  file.managed:
    - name: /etc/hosts
    - source: salt://test/123.txt
    - user: root
    - group: root
    - mode: 644

Copying Files

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

Installing Nginx

pkg is the module, installed is the method, -names is the parameter. Equivalent to yum install nginx. require is the dependency.

[root@master salt]# pwd
/srv/salt
[root@master salt]# vim nginx_install.sls
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
[root@master salt]# salt '*' state.sls nginx_install

Installing Apache

[root@master salt]# vim apache.sls
apache-service:
  pkg.installed:
    - names:
      - httpd
      - mod_ssl
  service.running:
    - name: httpd
    - enable: True
[root@master salt]# vim top.sls 
base:
'*':
    - apache
[root@master salt]# salt '*' state.highstate 
salt '*' state.highstate test=True indicates whether the state is synchronized, test=True indicates whether the test is successful or not.
If Apache is not installed, it will be installed; if it is already installed, it will not be reinstalled.

Scheduled Tasks

minute hour daymonth month dayweek
[root@master ~]# cd /srv/salt/
[root@master salt]# vim crontab.sls
/usr/sbin/ntpdate time.aliyun.com >> /dev/null:
  cron.present:
    - user: root
    - minute: '*/5'
[root@master salt]# salt '*' cron.list_tab root

Client View
[root@localhost ~]# crontab -l
# Lines below here are managed by Salt, do not edit
# SALT_CRON_IDENTIFIER:/usr/sbin/ntpdate time.aliyun.com >> /dev/null
*/5 * * * * /usr/sbin/ntpdate time.aliyun.com >> /dev/null

5 minutes changed to 3 minutes, then execute again
[root@master salt]# vim crontab.sls
/usr/sbin/ntpdate time.aliyun.com >> /dev/null:
  cron.present:
    - user: root
    - minute: '*/3'
[root@master salt]# salt '*' state.sls crontab

Deleting cron

[root@master salt]# vim del_cron.sls
/usr/sbin/ntpdate times.aliyun.com >> /dev/null:
  cron.absent:
    - name: /usr/sbin/ntpdate times.aliyun.com >> /dev/null
[root@master salt]# salt '*' state.sls del_cron

5. Differences between state.sls and state.highstate in SaltStack

The default execution environment for state.sls is the base environment, but it does not read top.sls (top.sls defines the execution environment and the SLS files to be executed). The official documentation for state.sls is as follows:

salt.modules.state.sls(mods, saltenv='base', test=None, exclude=None, queue=False, env=None,**kwargs)

Here, saltenv refers to the execution environment, which defaults to the base environment.

state.highstate: This is global for all environments, and all states are effective. It reads each environment’s top.sls and applies to all SLS files.

6. Regular Expression Matching for Hosts

https://www.cnblogs.com/wangyajian/p/11572572.html

Grains：https://www.cnblogs.com/wangyajian/p/11586990.html
pliiar：https://www.cnblogs.com/wangyajian/p/11586998.html
state module：https://www.cnblogs.com/wangyajian/p/11633678.html
state install nginx：https://www.cnblogs.com/wangyajian/p/11633828.html
highstate：https://www.cnblogs.com/wangyajian/p/11663089.html
salt-key：https://www.cnblogs.com/hanson666/articles/7105197.html

7. Data System Grains (Client)

Minion collects information, Master matches and provides it to the Minion side

========== Client’s self-collected identity information ==========Grains collects all system information at the time of Minion startup, stored on the Minion side.

[root@master ~]# salt '*' grains.ls  # List all items
[root@master ~]# salt '*' grains.items # Get all item values
[root@master ~]# salt '*' grains.item os_family
[root@master ~]# salt '*' grains.item osrelease
[root@master ~]# salt -G 'osrelease:7.8.2003' test.ping
[root@master ~]# salt '*' grains.item ipv4
[root@master ~]# salt '*' grains.item ip4_interfaces

Custom Grains Method 1: vim /etc/salt/minion

# Server cabinet location
[root@agent ~]# vim /etc/salt/minion
grains:
  roles:
    - webserver
    - dbserver
  deployment: datacenter1
  cabinet: 13
  cab_u: 14-15
# roles is the key, with values webserver and dbserver, data center one
[root@agent ~]# systemctl restart salt-minion

8. Data System Pillar (Server)

Master side settings, provided to the Minion side

Pillar in SaltStack mainly serves to store and define some data needed in configuration management, such as software version numbers, usernames, passwords, etc. Its storage format is similar to Grains, both in YAML format.

[root@master ~]# vim /etc/salt/master
pillar_roots:
  base:
    - /srv/pillar
[root@master ~]# mkdir /srv/pillar
[root@master pillar]# vim env_salt01.sls
roles:
  - webserver
  - dbserver
  deployment: datacenter1
  cabinet: 13
  cab_u: 14-15
[root@master pillar]# vim top.sls
base:
'*':
    - env_salt01
[root@master pillar]# salt '*' saltutil.refresh_pillar
[root@master pillar]# salt -I 'roles:webserver' cmd.run 'uptime'
[root@master pillar]# salt --pillar 'roles:webserver' cmd.run 'uptime'

9. Remote Execution Targeting

Related to Minion_ID:

• • Globbing (wildcards)
• • Regex (regular expressions)
• • List

Not related to Minion_ID:

• • Subnet/IP
• • Grains
• • Pillar
• • Compound matchers
• • Node groups

# salt 'salt01.tianyun.com' test.ping
# salt 'salt01*' test.ping
Regular expressions:
* means 0 to many times
? means 0 to 1 time
[] means any one character
[!]

# salt -L 'salt01,salt02' cmd.run 'uptime'  # -L for multiple hosts
Unsupported syntax: # salt -L 'salt01.tianyun.com,salt03*' test.ping
# salt -E 'salt0[^14].tianyun.com' test.ping  # Regular expression means not 01 04
# salt -S '10.0.100.0/24' test.ping  # Subnet
# salt -G 'os:Centos' cmd.run 'uptime'  # System built-in Grains
# salt -I 'Zabbix_Server' test.ping  # Pillar

Minion side modify ID: vim /etc/salt/minion_id

Using regex in SLS files, note match pcre:
# cat /srv/salt/top.sls
base:
'saltstack0[^23].tianyun.com':
    - match: pcre
    - apache

Using Grains in SLS files
base:
'os:CentOS':
    - match: grain
    - apache

Compound Matching

Compound matching
# salt -C ‘I@or/and'
# salt -C 'I@roles:dbserver and I@delpoyment:datacenter1 and G@os:Centos and [email protected]/24 or E@salt0[13].tianyun.com' cmd.run 'uptime'

[root@master ~]# vim /etc/salt/master
nodegroups:
  webs: 'I@roles:dbserver and I@delpoyment:datacenter1 and G@os:Centos and [email protected]/24 or E@salt0[13].tianyun.com'
[root@master ~]# salt -N 'webs' test.ping

10. Configuration Management States

States are the configuration language in the SaltStack system. In daily operations, a large number of States files need to be written, such as creating a user, installing a software package, managing the corresponding configuration files, and finally ensuring that the service runs normally. Therefore, it is necessary to write some States SLS files, i.e., state configuration files to describe and implement the corresponding functions. States SLS primarily use YAML language, but can also support Python language.

[root@master ~]# vim /etc/salt/master
file_roots:
   base:
     - /srv/salt/
   dev:
     - /srv/salt/dev/services
     - /srv/salt/dev/states
   test:
     - /srv/salt/test
   prod:
     - /srv/salt/prod/services
     - /srv/salt/prod/states
[root@master ~]# systemctl restart salt-master
[root@master ~]# cd /srv/salt/
[root@master salt]# pwd
/etc/salt
[root@master salt]# mkdir dev test prod
base environment, configurations needed by all machines
yum, dns, kernel parameters, zabbix agent


[root@master salt]# mkdir -p init/files
[root@master salt]# vim init/files/resolv.conf
nameserver 8.8.8.8
nameserver 114.114.114.114
[root@master salt]# cd init/
[root@master init]# pwd
/srv/salt/init
[root@master init]# ls
files


[root@master init]# vim dns.sls
/etc/resolv.conf:
  file.managed:
    - source: salt://init/files/resolv.conf
/etc/resolv.conf is the target file for the minion. If a name is configured below, it will be different.
source: salt:// indicates the base environment of salt.

[root@master init]# salt '*' state.sls init.dns env=base  
Note that this is init.dns; if placed directly in /srv/salt/xx.sls, it does not need to be added. Now it is placed in /srv/salt/init/xx.sls.
The default is also env=base

For all hosts:

[root@master salt]# pwd
/srv/salt
[root@master salt]# vim top.sls
top:
base:
  '*':
    - init.dns
[root@master salt]# salt '*' state.highstate  # Based on top.sls

11. Relationships in Configuration Management

unless

• • Mainly used for cmd state module, only when the command pointed to by unless returns false will the command pointed to by name be executed, e.g., test -d /usr/local/nginx

re

• • require I depend on a certain state, who do I depend on
• • require_in I am depended on by a certain state, who depends on me

wa

• • watch I monitor a certain state [monitoring] when the state changes, for example, if the state I monitor changes, restart
• • watch_in I am monitored by a certain state

require

require: 
  module_name:ID

[root@master dev]# cat /srv/salt/dev/lamp.sls
dep-install:
  pkg.installed:
    - names:
      - php

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

httpd-service:
  service.running:
    - name: httpd
    - enable: True
    - require:
      - file: httpd-files
        
mysql-files:
  file.managed:
    - name: /etc/my.cnf
    - source: salt://files/my.cnf

watch

[root@master dev]# cat /srv/salt/dev/lamp.sls
dep-install:
  pkg.installed:
    - names:
      - php

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

httpd-service:
  service.running:
    - name: httpd
    - enable: True
    - require:
      - file: httpd-files
    - reload: True # Optional, if PID does not change, choose reload. Default is without this, only watch will restart.
    - watch:
      - file: httpd-files  # As long as httpd-files changes, it will change, changing ports or starting will also change
        
mysql-files:
  file.managed:
    - name: /etc/my.cnf
    - source: salt://files/my.cnf
            

Relationships, watch_in and require_in watch and reload are written in the service watch_in, if written in the file, then in the service write reload

Link: https://blog.csdn.net/qq_39578545/article/details/114994167?ops_request_misc=%257B%2522request%255Fid%2522%253A%252204b592e965f59785c4e97c61ceed050a%2522%252C%2522scm%2522%253A%252220140713.130102334..%2522%257D&request_id=04b592e965f59785c4e97c61ceed050a&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~sobaiduend~default-2-114994167-null-null.142^v102^pc_search_result_base1&utm_term=saltstack%E8%87%AA%E5%8A%A8%E5%8C%96&spm=1018.2226.3001.4187

END

Official Site: www.linuxprobe.com

Linux Command Collection: www.linuxcool.com

Teacher Liu Chuan QQ: 5604215

Linux Technology Group: 2636170

（New group, hotly joining…）

Readers who want to learn the Linux system can click the“Read Original” button to learn about the book “Linux Should Be Learned This Way”, which is also very suitable for professional operation and maintenance personnel to read, becoming a high-value tool book to assist your work!