When we have only one server, two servers and several servers, we deploy software tools to log on to the server one by one, but as the number of enterprise servers not only increases, it is obvious that the deployment of logon by one has become unrealistic. At this time, the automated operation and maintenance management tools came on the scene. At present, the more popular tools are puppet, ansible, saltstack. I have used ansible and saltstack. When there are more machines, the execution of ansible is much slower than that of saltstack. Today I will mainly introduce saltstack.

1. Introduction to saltstack

saltstack is an automated operation and maintenance tool written by python and based on c/s architecture. It is composed of master and minion. It uses ZeroMQ message queue pub/sub mode to communicate, and uses SSL certificate to issue authentication management. It supports multi-master. saltstack not only can be managed by installing the client in the node, but also can be managed directly by ssh. The operation mode is to send instructions to the master and the client receives instructions to execute. yaml format is used to write configuration files, support api and custom python module, which can easily achieve functional expansion.
Saltstack has a saltstack master, and many saltstack minon s are connected to that master when initialized. When initialized, minion exchanges a secret key to establish a handshake and then establishes a persistent encrypted TCP connection. Usually, commands start from the master's command line, and the master distributes the commands on minion. Saltstack master can connect many minions at the same time without worrying about overload, thanks to ZeroMQ. Because a persistent connection is established between minion and master, commands on master can quickly reach minion. Minion can also cache multiple types of data to speed up execution.

2. Installation process

2.1 Environmental preparation

2.2 Installation of saltstack

master machine

1. Load the saltstack library and key

[root@saltstack-master ~]# yum install -y https://repo.saltstack.com/yum/redhat/salt-repo-latest.el7.noarch.rpm

2. Clear the cache

[root@saltstack-master ~]# yum clean expire-cache

3. Install salt-master service

[root@saltstack-master ~]# yum install -y salt-master

4. Start the master service

[root@saltstack-master ~]#  systemctl enable salt-master
[root@saltstack-master ~]#  systemctl start salt-master

minion machine

1. Load the saltstack library and key

[root@saltstack-minion1 ~]# yum install -y https://repo.saltstack.com/yum/redhat/salt-repo-latest.el7.noarch.rpm
[root@saltstack-minion2 ~]# yum install -y https://repo.saltstack.com/yum/redhat/salt-repo-latest.el7.noarch.rpm

2. Clear the cache

[root@saltstack-minion1 ~]# yum clean expire-cache
[root@saltstack-minion2 ~]# yum clean expire-cache

3. Install salt-minion

[root@saltstack-minion1 ~]# yum install -y salt-minion
[root@saltstack-minion2 ~]# yum install -y salt-minion

4. Start minion

[root@saltstack-minion1 ~]# systemctl enable salt-minion
[root@saltstack-minion1 ~]# systemctl start salt-minion
[root@saltstack-minion2 ~]# systemctl enable stal-minion
[root@saltstack-minion2 ~]# systemctl start salt-minion

Service configuration

The following minion configuration operates in one explanation and the other in the same way
1.master defaults to monitor 4505 and 4506 ports on all network cards. Modifying the configuration file will make the service monitor at the unique address.

[root@saltstack-master ~]# vim /etc/salt/master
interface: 10.20.3.10
[root@saltstack-master ~]# systemctl restart salt-master

2. Modify the minion configuration file and add the master address

[root@saltstack-minion1 ~]# vim /etc/salt/minion
master: 10.20.3.10
[root@saltstack-minion1 ~]# systemctl restart salt-minion

3. Establishment of mater and minion communication keys
The master is requested to send a certificate to the minion after it starts. When the certificate is issued, it indicates that the master can join the minion.

[root@saltstack-master ~]# salt-key -L

You can see that two minion clients have established contact with the server, and the master has acquired the minion public key, but the master has not accepted the minion key yet, and is waiting for further instructions on whether to accept the minion.

Make master accept minion's key

[root@saltstack-master ~]# salt-key -a saltstack-minion1
[root@saltstack-master ~]# salt-key -a saltstack-minion2

At this point, the master has accepted minion's key

You can also use the following command to accept all minion key s at once
salt-key -A -y

4. Simple Testing
master ping minion

[root@saltstack-master ~]# salt '*' test.ping

View minion machine load

[root@saltstack-master ~]# salt '*' cmd.run 'uptime'

So far, saltstack has been built.

3. Use of saltstack

3.1 Common commands for salt

salt-key key key management

salt-key -L # View the key status of all minion s
salt-key -a <node id> # Accept a minion key
salt-key -A # Accept all minion key s
salt-key -d <node id> # Delete the key of a minion
salt-key -D # Delete all minion key s

salt-run executes the runner function

salt-run [option] [runner.func]

salt-run manage.status # View the status of all minion s
salt-run manage.down # Check the minion down loaded
salt-run manage.up # View minion of up

3.2 grains module

The module collects the static information of the system, including cpu, operating system, file system, hard disk and so on.
Display all minion grians information

[root@saltstack-master ~]# salt '*' grains.ls

List all minion grains details

[root@saltstack-master ~]# salt '*' grains.items

grains usage scenario

1. View the operating systems of each minion

[root@saltstack-master ~]# salt '*' grains.item os

2. Classification Search
If you find out that the cpu architecture is x86 machine, check the number of cpu cores
You can use the - G parameter to represent matching minion using variable information in grains

[root@saltstack-master ~]#  salt -G 'cpuarch:x86_64' grains.item num_cpus

You can customize grains

Here we customize grains for minion1
1 Modify / etc/salt/minion file

[root@saltstack-minion1 ~]# vim /etc/salt/minion
grains:
  services:
    - webserver
    - redis
  site: beijing1
  department: yanfa
[root@saltstack-minion1 ~]# systemctl restart salt-minion

Here's another look at the master, and you can see the properties we define ourselves

2 You can also modify the / etc/salt/grains file

[root@saltstack-minion1 ~]# vim /etc/salt/grains
 services:
   - webserver
   - redis
 site: beijing1
 department: yanfa

3. You can also write grains module on master

[root@saltstack-master ~]# vim /srv/salt/_grains/test.py
def use():
    useage = {}
    useage['use'] = 'docker'
    return useage
//Synchronize to minion
[root@saltstack-master ~]# salt '*' saltutil.sync_grains

See

The files distributed by the master can be seen in minion/var/cache/salt/minion/files/base/

3.3 pillar module

Pillar can specify that some information is sent to the specified minion, and the stored data can be dynamic. pillar is written in sls, in the form of key-value pairs.
Unlike the grains module, grains is synchronized to all minions by master, while pillar is only synchronized to specified minions.
Implementing a pillar process

Create pillar directory
[root@saltstack-master ~]# mkdir /srv/pillar
 Create a pillar data file
[root@saltstack-master ~]# vim /srv/pillar/test.sls
pod: '09'
disk: 'ssd'
Create top file files (specify which minion s to pillar data files, i.e. nodes to distribute)
base:
  'saltstack-minion1':
    - test
 Refresh pillar data
[root@saltstack-master ~]# salt '*' saltutil.refresh_pillar

Looking at it, you can see that only the minion we specified received the data

Here's another pillar process using jinja syntax in conjunction with grains

Create a pillar data file
[root@saltstack-master ~]# mkdir /srv/pillar/web
[root@saltstack-master ~]# vim /srv/pillar/web/apache.sls
{% if grains['os_family'] == 'RedHat' %}
apache: httpd
{% elif grains['os_family'] == 'RedHat' %}
apache: apache2
{% endif %}
//Create top file file
[root@saltstack-master ~]# vim /srv/pillar/top.sls
base:
  '*':
    - web.apache
//Refresh pillar data
[root@saltstack-master ~]# salt '*' saltutil.refresh_pillar

Look, minion1 and minion2 are centos systems. All web s are httpd

4. Reference Documents

https://repo.saltstack.com/#rhel