Saltstack (b)

Saltstack Configuration Management

Saltstack configuration management, also known as state management, Saltstack cannot rollback a state. When we write the SLS file, to support multiple executions, such as: Write the Software Installation module, each time you execute this state, will check whether the software is installed.

The SLS description file written in Saltstack is essentially an abbreviation for the salt stack, using the descriptive syntax of YAML.

SLS File Description

# Cat/srv/salt/web/apache.sls Apache-install: #ID声明, id must be unique pkg.installed: #state声明, State Declaration, what action to perform-names: #选项声明, specific behavior Parameters-Httpd-httpd-devel

The SLS file format is written in a variety of ways, typically with these three parts, with multiple parameters using the '-' list, using hierarchical progression relationships.

Installing Lamp with Saltstack

When installing the lamp environment, use a different configuration file to complete the installation and deployment of the remediation environment. The whole process can be divided into three steps:

1. Install package using PKG module

2. Modify the configuration file using the file module

3. Use service module to start services

PKG Module

Https://docs.saltstack.com/en/latest/ref/states/all/salt.states.pkg.html#module-salt.states.pkg

You can install multiple packages at the same time using pkg.installed:

Common_packages:pkg.installed:-pkgs: #指定多个包-unzip-dos2unix-salt-minion:2015.8.5-1.el 6 #末尾指定版本

Some other common methods in Pkg are:

pkg.installed # Install Pkg.latest # Make sure the latest version Pkg.remove # uninstall Pkg.purge # Uninstall and delete the configuration file

For apache,mysql,php installation in lamp, first create the catalog and SLS files:

Mkdir/srv/salt/lampvim/srv/salt/lamp/lamp.sls

installation of the lamp environment written configuration:

Lamp-pkg:pkg.installed:-pkgs:-Httpd-php-mariadb-mariadb-server-php-mysql- Php-cli-php-mbstring

File module

Https://docs.saltstack.com/en/latest/ref/states/all/salt.states.file.html#module-salt.states.file

When you need to modify the configuration of the installed services, through the file module to distribute the corresponding configuration file, for different services must use a different ID, under the same ID can not have two or more module method behavior. As in the following Lamp.sls file, there can be only one file.managed method call under an ID.

For apache,mysql,php file configuration in lamp, add the following to Lamp.sls:

apache-config:  file.managed:    -  Name: /etc/httpd/conf/httpd.conf    - source: salt://lamp/files/httpd.conf      - user: root    - group: root     - mode: 644php-config:  file.managed:    - name :  /etc/php.ini    - source: salt://lamp/files/php.ini # This represents the root directory of the current environment (the current environment is divided into base, Dev, pro)     - user: root    -  group: root    - mode: 644mysql-config:  file.managed:     - name: /etc/my.cnf    - source: salt://lamp/files/ my.cnf    - user: root    - group: root     - mode: 644 
 

For the path specified in source, the root directory of the current environment must be the starting path, as in the configuration file for master, the base environment is/srv/salt. The dev Environment and pro Environment specify the corresponding starting path in the master configuration file, respectively.

The configuration files required for each service are placed in the specified path, and if they are not available, the corresponding software can be installed on a single machine, and the configuration file will be copied to the specified path (in this case the/srv/salt/files specified in the source file):

cp/etc/httpd/http.conf/srv/salt/lamp/files/cp/etc/php.ini/srv/salt/lamp/files/cp/etc/my.cnf/srv/salt/lamp/ files/

This will automatically distribute the configured configuration file to the corresponding directory when the File.managed module is executed.

Service Module

The service module is used to enable services, and at the end of the Lamp.sls file, add the following:

Apache-service:service.running: #启动服务模块-name:httpd #需要指定服务名称, otherwise the ID name will be used as the service name and error-Enable:true #开机自 Start-Reload:true #重载mysql-service:service.running:-Name:mariadb-enable:true-reload:true

To execute a deployment command on master:

# Salt ' node2 ' State.sls lamp.lamp

On Node2, these services are installed automatically, replace files, and start.

Because the same ID and the same state module can only be used once, the above configuration file can also be written according to the deployment process of a single service, and define a series of actions for a service under an ID:

Apache-service:pkg.installed:-pkgs:-httpd file.managed:-Name:/etc/httpd/conf/httpd.conf-source:          salt://lamp/files/httpd.conf-user:root-group:root-mode:644 service.running:-name:httpd -Enable:true-reload:true

Note: The parsing mode of the SLS file is from top to bottom, in order, and when writing the module, be aware of the order, for example, to configure and start the service when it is installed.

Relationship between states

When each module calls each other, it involves a sequence of problems, such as when we need to start a service, we must ensure that the service is installed before the configuration is completed to start. For complex calls between modules, you need to have a way to define it to specify the relationship between states.

There are some interactions between States, mainly the following relationships:

1, relying on who require, such as the module running the start service must first run the installation module, but also depends on the configuration module

2, by WHO relies on require_in, the installation module is dependent on the boot module

3, monitor who watch, if the Monitoring module status changes reload, if there is no reload parameter, it will be restarted.

4, by WHO monitor watch_in, and watch function is the same, the module object and location is corresponding.

5, reference who include direct import to execute other files and execute, you can specify multiple files to run.

6, expand Who

As in the above example:

lamp-pkg:  pkg.installed:    - pkgs:      -  httpd      - php      -  mariadb-server      - php-mysql      -  php-cli      - php-mbstringapache-config:  file.managed:     - name: /etc/httpd/conf/httpd.conf    - source: salt ://lamp/files/httpd.conf          - user: root     - group: root    - mode: 644     - require:     #依赖于安装模块       - pkg:  lamp-pkg    #状态模块: idphp-config:  file.managed:    -  Name: /etc/php.ini    - source: salt://lamp/files/php.ini    - user: root     - group: root    - mode: 644     - require:     #依赖于安装模块       - pkg: lamp-pkg    #状态模块: idmysql-config:  file.managed:    - name: /etc/ My.cnf    - source: salt://lamp/files/my.cnf    - user:  root    - group: root    - mode: 644     - require:     #依赖于安装模块       -  pkg: lamp-pkg    apache-service:  service.running:    -  name: httpd    - enable: true    - reload:  true    - require:           #依赖于安装和配置模块        - pkg: lamp-pkg      - file:  apache-config    - watch:             #  Execute reload      - file:  when the Apache-config status (file) of the monitor is changed apache-config     #注意: If there is no- enable: true parameter in this state module, the service will be restarted when the state changes.        mysql-service:  service.running:    -  name: mariadb    - enable: true    - reload:  True    - require:          #此模块执行时 , dependent on lamp-pkg and Mysql-config modules       - pkg: lamp-pkg       - file: mysql-confiG 

Include, you can write the above content in separate SLS files, using the include in the master configuration file to run the different files in turn:

# cat Init.slsinclude:-Lamp.pkg-lamp.config-lamp.service

In the current directory there are Pkg.sls, Concfig.sls, SERVICE.SLS files respectively.

The Init.sls module executes directly when the salt command is executed:

Salt ' node2 ' State.sls lamp.init

If you start writing to a SLS file for all of the installation configurations of a single service that is not interdependent, you will be greatly more flexible when writing the master configuration, and you can choose the corresponding SLS part that needs to be serviced.

Through the relationship between States, the individual services can be modular, can be repeatedly called by other modules, easy to manage and configure.

Tips for writing SLS:

1, the installation status classification. Use alone will be clear.

2, according to the service classification, can be other SLS include.

Jinja templates

JINJA2 is the template language for Python. Templates are just text files that can generate any text-based format.

The template contains expressions and variables, denoted by {%...%} and {{...}} respectively. There are generally three steps when using Jinja templates:

• When using the Jinja template, you need to declare the use of Jinja in the SLS file
  

-Template:jinja

• Lists the list of parameters,

-Defaults:port:88 # indicates that the PORT variable has a value of 88

• A reference to the template,

In the distributed configuration file, you can assign the value of the port variable to the parameters of the configuration file:

Listen {{port}} # The value of the port variable is automatically added to the variable Listen 88

using grains in Jinja

You can use Salt,grains and pillar to get the parameters of the minion itself, such as the native IP address, when modifying the Minion side of a variable to modify the parameters of some minion itself.

Add the Jinja template to the SLS configuration file first

-Template:jinja

As in the example above, modify the httpd.conf file listening port:

Listen {{grains[' fqdn_ip4 '][0]}}:{{PORT}}

The FQDN_IP4 here is the output corresponding to the FQDN_IP4 obtained in the grains:

# salt ' * ' Grains.item fqdn_ip4 node2:----------fqdn_ip4:-172.16.10.61node1:----------FQDN_IP4: -172.16.10.60

Because it is a list, [0] represents the first value in the list, which is the IP address. The configuration file format corresponding to Node2 is:

Listen 172.16.10.61:88

using salt in Jinja

You can use the salt itself module to get host parameters, such as getting the MAC address of the native eth0:

# salt ' * ' network.hw_addr eth0node2:00:0c:29:04:73:9dnode1:00:0c:29:e8:97:67

You can add the following parameters to an area that needs to be populated with the native MAC address configuration:

{{salt[' network.hw_addr '] (' eth0 ')}}

The Jinja template needs to be specified in the SLS.

Using Pillar in Jinja

You can also use pillar in Jinja, if you have a custom pillar value, you can get it directly from the Jinja template, but you must first add a Jinja template.

# salt ' * ' Pillar.itemsnode1:----------node2:----------apache:httpd

Use the following parameters in the configuration file to get pillar:

{{pillar[' Apache '}}}

In this way, a httpd parameter is added to the configuration file that is distributed to the Node2.

This usage can be used to configure sensitive information such as the account password involved in the file.

defined in the SLS template

It is also possible to configure the defaults in the SLS, in the variables list.

-Template:jinja-defaults:iparrd: {{grains[' fqdn_ip4 '][0]}} port:88

You can then refer to the variable {{ipaddr}} directly in the file.

This article is from the "Trying" blog, make sure to keep this source http://tryingstuff.blog.51cto.com/4603492/1871589

Saltstack (b)