Quick introduction to SaltStack

Quick introduction to SaltStack
1. Introduction

A set of C/S architecture configuration management tools developed based on Python. The underlying layer uses ZeroMQ Message Queue pub/sub for communication and SSL certificate issuance for authentication management.

2. Environment preparation 2.1 installation

This document uses the salt-bootstrap Method for installation. Salt-bootstrap is a separate project of SaltStack. It is mainly used to deploy the SaltStack environment on multiple platforms with one click.

Download installation script

curl -L https://bootstrap.saltstack.com -o install_salt.sh

 

Install salt-master

Sh install_salt.sh-M # Install the latest stable versions of salt-master and salt-minion

 

Install salt-minion

Sh install_salt.sh # Install salt-minion of the latest stable version

 

2.2 Configuration

(1) configure the hosts file for all master and minion nodes (use DNS in the production environment)

Host Name	IP	Description
Node1	172.16.37.23	Master
Node2	172.16.37.35	Minion
Node3	172.16.37.41	Minion
Node4	172.16.37.39	Minion
Node5	172.16.37.43	Minion

 

 

 

 

 

 

 

(2) Master firewall rules

After the salt master is started, it listens to two ports by default:

4505/tcp, publish_port, provides the remote command sending Function

4506/tcp, ret_port, used for file service, authentication, result collection, and other functional interfaces

 

(3) Minion Configuration

Modify/etc/salt/minion

A) modify the master of minion

Find the following line '# master: salt', uncomment, and change it to the actual master host name.

Master: node1

B) Specify the id for minion

Locate '# id:' In the following line, uncomment, and set it to the minion Host Name (not necessarily the same as the host name), as shown in

Id: node2

 

Restart salt master and salt minion

systemctl restart salt-master salt-minion # Mastersystemctl restart salt-minion             # Minion

 

2.3 Certificate Management

SaltStack uses SSL visa for Security Authentication and communication encryption

After Minion is started for the first time, it will generate a Public Key key in/etc/salt/pki/minion, and then send the public key to the Master, waiting for the Master to accept

The Master can establish communication with the Minion only after issuing a certificate for it.

 

Related commands

# View certificate issuance information salt-key-L # issue a certificate salt-key-A node2 for node2 # issue a certificate salt-key-A for all the Minion awaiting acceptance

3. Remote Command Execution

Salt 'target machine 'function [parameter] (for detailed usage, see 'Salt-H ')

Remotely execute the ping function (/usr/lib/python2.7/site-packages/salt/modules/test. py) in the test module on all Minion instances. This function returns True directly)

salt ‘*’ test.ping

 

View Function Description

salt ‘node2’ sys.doc test.ping

 

Remote command execution module cmd (/usr/lib/python2.7/site-packages/salt/modules/cmdmod. py)

salt ‘*’ cmd.run “hostname”

 

List cmd module functions

salt 'node2' sys.list_functions cmd

 

View Function Description

salt 'node2' sys.doc cmd.run

 

The principle is to execute functions in the python module on the Matching target machine. You can write a custom python module and push it to Minion.

4. Status system 4.1 Status System Description

Describes the State of Minion In the SLS (SaLt State) file. The State module of SaltStack ensures that Minion is in this State at the underlying layer.

For example, to install the httpd service, run the following remote command:

salt ‘node2’ pkg.install httpd

 

The status file is described as follows:

Then, the status module ensures that the httpd service on the target machine is in the pkg. installed status:

salt ‘node2’ state.apply apache

 

Both of them achieve the purpose of deploying the httpd service on the target machine. However, the same logic and command are executed every time the remote command is executed, and the state file puts the Minion in the specified state according to the description, the operation is performed only when the current status and the required status are different.

The remote command execution method belongs to the execution module. View All execution modules

salt 'node2' sys.list_modules

 

View All functions in the pkg execution module

salt 'node2' sys.list_functions pkg

 

Status files belong to the status module. View All status modules

salt 'node2' sys.list_state_modules

 

View All functions in the pkg Status Module

salt 'node2' sys.list_state_functions pkg

 

4.2 Highstate

Highstate manages modules and hosts through the top. sls File

With highstate, you can use top. sls to organize multiple state files, split and reuse modules, and configure and manage multiple environments.

 

The following is an example of highstate.

File_roots has only one base environment by default, which is located in/srv/salt, and top. sls is located in the root directory of the base environment. The directory structure is as follows:

 

Specify the state file or state file subdirectory in top. sls.

 

Myapp is referenced in top. sls. myapp will be referenced in the following order: If myapp. sls exists, myapp. sls will be referenced. If not, init. sls under the myapp directory will be referenced. We use subdirectories to plan directories.

 

Include various state files related to myapp in myapp/init. sls (you can split the state files into multiple ones and include them here)

 

. Myconf corresponds to the myconf. sls status file in the same directory as init. sls. The/tmp/myconf.txt status of Minion is described in this file.

 

Write arbitrary content in files/myconf.txt and run the following command to make Minion In the description state:

salt 'node2' state.apply

 

Refer:

(1) https://docs.saltstack.com/en/latest/topics/tutorials/states_pt1.html

(2) https://docs.saltstack.com/en/latest/topics/tutorials/starting_states.html

5. Grains

Components that record the static information of Minion in SaltStack (OS type, number of CPU cores, memory size, IP address, etc.) are collected and reported to the Master when Minion is started, therefore, Grains usually stores static and infrequently changed data and is stored locally in Minion.

Minion can operate its own Grains data (add, delete, modify, and delete)

 

Run the following command to view the Grains data:

salt 'node2' grains.items

6. Pillar

Similar to Grains, Pillar stores relatively changing data and stores it locally on the Master node.

Minion can only view its own Pillar data

 

Run the following command to view each Pillar data:

salt 'node2' pillar.items

7. Jinja

The Python template engine defines dynamic configurations by combining with Grains and Pillar.

For example, different Minion can obtain different host names through fqdn.

 

Next, we can use Grains to create dynamic configurations so that/tmp/myconf.txt on each target machine can display its host name.

Modify the file description in the status file and specify the template as jinja.

#cat dev/myapp/myconf.slsconf1:  file.managed:    - name: /tmp/myconf.txt    - source: salt://nginx/files/myconf.txt    - user: root    - group: root    - mode: 644    - template: jinja

 

In the file corresponding to the source{Grains ['item']}Reference Grains data

#cat dev/myapp/files/myconf.txt[BASE] /srv/salt/devMy hostname is {{ grains['fqdn'] }}

 

Put all Minion In the description state

salt '*' state.apply

 

Refer:

(1) https://docs.saltstack.com/en/latest/topics/tutorials/states_pt3.html

 

8. configure and manage multiple Environments

The following describes how to place the/tmp/myconf.txt file with different content on hosts in different environments.

To distinguish different environments, first modify the id of each Minion to add the environment id

 

Modify the file_root configuration of the master (/etc/salt/master)

file_roots:  base:   - /srv/salt/base  dev:    - /srv/salt/dev  prod:    - /srv/salt/prod

 

Maintain the top. sls under the root directory of each environment in multiple environments.

 

The top. sls instance specifies its own environment, matched target machines, and included status files/subdirectories.

 

Myapp is referenced in top. sls. myapp will be referenced in the following order: If myapp. sls exists, myapp. sls will be referenced. If not, init. sls under the myapp directory will be referenced. We use subdirectories to plan directories. Specify the status file in this subdirectory in init. sls.

 

. Myconf corresponds to the myconf. sls status file in the same directory as init. sls. The/tmp/myconf.txt status of Minion is described in this file.

 

Write different contents in myconf.txt of base‑dev1_prodenvironment. Execute the following command to make the Minion of different environments in the corresponding description state.

Salt '*' state. apply # default base environment salt '*' state. apply saltenv = dev # dev environment salt '*' state. apply saltenv = prod # prod Environment

 

Refer:

(1) https://docs.saltstack.com/en/latest/topics/tutorials/states_pt4.html