I. Overview
Salt is a basic setting management tool for heterogeneous platforms, using the lightweight communicator ZMQ, a batch management tool written in Python, completely open source, abiding by the Apache2 protocol, similar in function to Puppet, Chef, and has a powerful remote execution command engine , also has a powerful configuration management system, often called the Salt State System.
2. Basic principles
In the C/S mode, the server side is the master of the salt, and the client side is the minion. The minion and the master communicate through the ZeroMQ message queue. After minion goes online, first contact the master, send its own pub key, and after accepting the minion-key, that is, the master and the minion have mutual trust that the master can send any command for the minion to execute. At the same time, SaltStack also supports SSH without installing Agent, and realizes management through SSH.
Implementation steps:
1.ZeroMq is used for message transmission between the Master and Minion of the Salt stack, using the publish-subscribe mode of ZeroMq, and the connection methods include tcp, ipc
2. The salt command, publishes the cmd.run ls command from salt.client.LocalClient.cmd_cli to the master, obtains a Jodid, and obtains the command execution result according to the jobid.
3. After the master receives the command, it sends the command to be executed to the client minion.
4. minion receives the command to be processed from the message bus and hands it to minion._handle_aes for processing
5.minion._handle_aes initiates a local thread to call cmdmod to execute the ls command. After the thread executes ls, it calls the minion._return_pub method and returns the execution result to the master through the message bus
6. The master receives the result returned by the client, calls the master._handle_aes method, and writes the result to the file
7.salt.client.LocalClient.cmd_cli obtains the job execution result by polling, and outputs the result to the terminal.
Reference link:
Official site: http://www.saltstack.com/
Official documentation: http://docs.saltstack.com/
Chinese site: http://www.saltstack.cn/
Chinese manual: http://docs.saltstack.cn/
3. Installation and deployment
Environment preparation:
Operating system: centos 7.2
Configure EPEL source: # rpm -Uvh http://mirrors.zju.edu.cn/epel/7/x86_64/e/epel-release-7-9.noarch.rpm
Master side: 192.168.2.5
Minion end: 192.168.2.71
Master installation # yum install salt-master -y
Minion side installation # yum install salt-minion -y
Note: After installation, the Master configuration file is in /etc/salt/master, the minion configuration file is in /etc/salt/minion, and the default initial installation configuration file is annotated and can be customized.
SaltStack commonly used directory structure:
/var/cache/salt/master/minions/ #Store the cached data of minions
/srv/salt #Store the sls file of salt, there is no default by default, you need to create a new one
/srv/pillar #Store the pillar configuration file, there is no default by default, you need to create a new one
/etc/salt #Store salt's own configuration file
/var/log/salt #Log directory where salt is stored
Fourth, configure the Minion terminal to communicate with the Master, and perform a simple test.
1. Turn on the automatic certificate issuance on the Master side, which is turned off by default. If the minion is not turned on, the following error will be reported:
|
1
2
3
|
3月 08 14:47:46 node02 salt-minion[2736]: [WARNING ] ** Restarting minion **
3月 08 14:54:56 node02 salt-minion[2736]: [ERROR ] Attempt to authenticate with the salt master failed
3月 08 14:59:07 node02 salt-minion[2736]: [ERROR ] The Salt Master has cached the public key
for
thi...cate
|
Modify the Master configuration file as follows: /etc/salt/master
Modification: #auto_accept: False
for:auto_accept:True
# systemctl restart salt-master.service #Restart the Master side
2. Modify the Minion side configuration file as follows: /etc/salt/minion
Edit: #master: salt
master: 192.168.2.5 #Point to the main Master side
Edit: #id: salt
id: minion01 #Minion id number of the local end
# systemctl restart salt-minion.service #Restart the Minion side
At this time, the Master checks the salt-key, and the minion01 client is automatically added to the issuance list.
|
1
2
3
|
[root@node03 ~]
Accepted Keys:
minion01
|
Note: common commands for salt-key
-a #Add the specified id
-A #add all
-R #reject all
-d # delete the specified id
-D # delete all
test:
|
1
2
3
|
[root@node03 ~]
minion01:
3.10.0-327.el7.x86_64
|
###################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################
Description of commonly used configuration parameters on the Master side:
interface: specify the address of bind, the default is 0.0.0.0
publish_port: Specify the publish port, the default is 4505
ret_port: Specifies the result return port, which corresponds to the master_port in the minion configuration file, the default is 4506
uesr: Specifies the running user of the master process. If adjusted, you need to adjust the permissions of some directories. The default permission is root
timeout: Specify the timeout time. If the minion scale is large or the network condition is not good, it is recommended to increase the value, the default is 5s
keep_jobs: By default, the minion execution result will return to the master, and the master will be cached in the local cachedir directory. This parameter specifies how long to cache for viewing the previous execution results, which will occupy disk space, the default is 24h
job_cache: Whether the master caches the execution structure, if the scale is large (more than 5000), it is recommended to use other methods to store jobs, turn off this option, the default is True
file_recv: Whether to allow minion to transfer files to the master, the default is Flase
file_roots: Specify the file server directory, the default is:
file_roots:
base:
- /srv/salt
pillar_roots: Specify the pillar directory, the default is:
pillar_roots:
base:
- /srv/pillar
log_level: Execution log level, the supported log levels are 'garbage', 'trace', 'debug', info', 'warning', 'error', 'critical' , the default is 'warning'
Description of commonly used configuration parameters on the Minion side:
master: specifies the master host, the default is salt
mastar_port: Specifies which port the authentication and execution results are sent to the master, corresponding to the ret_port in the master configuration file, the default is 4506
id: Specifies the identity of the minion. Salt uses id as the identity, the unique identifier, and the default is the host name
user: specifies the user to run minion. Since a special user is required to install packages, start services, etc., it is recommended to use root, and the default is root
cache_jobs: Whether the minion caches the execution results, the default is False
backuo_mode: During file operation (file.managed or file.recurse), if the file is changed, specify the backup directory, the current valid value is minion, the backup is in the cachedir/file_backups directory, named after the original file name and timestamp, Default is Disabled
providers: specify the providers corresponding to the module, if in the RHRL series, the providers corresponding to pkg are yumpkg5
renderer: specifies the renderer in the configuration management system, the default value is: yaml_jinja
file_client: Specifies where the file client goes by default (remotr or local) to find files. The default value is remote
loglevel: specify the log level, the default is warning
tcp_keepalive: Whether the minion maintains a keepalive check with the master, there is a keepalive bug in the version below zeromq3, which will cause the minion to fail to reconnect to the master in some cases after the link is abnormal. It is recommended that the version above zeromq3 is True if possible