SaltStack之配置管理系统介绍

前言：
此博文主要以介绍salt配置管理理论为主，关于一些项目的实战将在后续的博文中展开。

Salt配置管理系统介绍
salt的配置管理系统与远程执行都是salt的核心功能，关于远程执行更多的介绍请参考上一篇博文《SaltStack远程执行常用模块使用》。这里我将介绍salt的另一个核心功能，配置管理系统，通过配置管理系统我们可以完成服服器的个性化配置文件管理，复杂的一些应用部署，比如LAMP源码部署，根据系统版本初始化系统配置等更多的功能。
salt配置管理系统依赖于state状态管理，而我们管理需要state状态文件，这些文件必须以 .sls 结尾，需要由我们自己来编写。此文件格式与YAML语法格式相同，并且还可以使用Jinja（Python的模块引擎），通过它我们可以完成一些个性化配置等功能，本文后面将会对YAML，Jinja，还有一点特殊的状态文件以及Salt环境作一些介绍。

环境介绍

环境里面主要就是存放我们的一些状态文件，配置文件等，我们的这些文件可以是生产环境 （Prod），或者开发环境（Dev）等，当然我们可以按我们的服务器种类，来分或者其它方法分，最主要是适用。我们安装好服务端（Salt-master）后默认有一个基础环境（Base）,下面我们来自定义我们的环境。
修改服务端配置文件：/etc/salt/master

#在配置文件最后加入以下内容，可以在配置文件里查找“file_roots:”关键字，找到相关例子和说明
file_roots:
base:
- /srv/salt/base
test:
- /srv/salt/test

以上配置文件我们定义了2个环境，分别为base，test，其中base环境为必须有的，且名称不可更改，其它我们可以自定义，接来下我们需要创建我们的目录，然后重启服务端服务

mkdir /srv/salt/{base,test}
systemctl restart salt-master

YAML语法介绍

关于yaml语法在salt客户端配置文件，服务端配置文件和state状态文件都是采用此讲法结构，所我们很有必要撑握此语法的使用。此语法有以下几个要点
缩进：缩进必须两个空格，不可以使用tab，主要用来表示层级关系

冒号：只要是以冒号结尾的行的下一行必须缩进两个空格，相当于Python里面的key-value。当然如果我们的key只有一个值的话我们可以写成一行，中间空一格即可。如果我们的key的值为一个列表，那么就需要另起一行，并且缩进两个空格以 - 开头

短横线：如上一条所说，一个短模线就相当于一个列表里面的一个元素，我们可以有多个元素。并且短模线的后面必须要有一个空格

例如，我们可以将服务端配置文件里面的file_roots改成如下配置：

file_roots:
base: /srv/salt/base
test:
- /srv/salt/test1
- /srv/salt/test2

将以上内容转换为我们Python的字典如下：

{'file_roots': {'test': ['/srv/salt/test1', '/srv/salt/test2'], 'base': '/srv/salt/base'}}
#我们可以使用python的yaml模块（pyyaml包）进行yaml和dict之间的转换测试

top.sls介绍

此文件文件名固定为top.sls，用来定义环境的总入口配置文件，当使用以下命令的时候就会调用
salt [TARGET] state.highstate <ENV>（state模块的highstate方法）时就会自动调用对应环境的top.sls，那么如果不使用state.highstate，而使用salt [TARGET] state.sls [State_File] <ENV>可以指定执行某一个状态文件，这样就不需要调用top.sls这个总入口文件了。如果不指定环境，那么默认调用base环境的状态文件。上面我们讲过所有state状态文件（以.sls结尾）都是使用yaml格式，下面我们看一个例子：

base:           #第一行为环境的名称，与file_roots保持一致，如果是test环境那就这里就是test
'*':         #指定主机，可以使用所有的target,如通配符,regex,grain,pillar,nodegroups等
- init.init_env #要执行的状态文件，以环境根目录开始，父目录与子目录用点分隔，非常像Python的模块调用
'os:CentOS':
- match:grain  #指定要使用的target
- httpd_install

可能你看完这小节感觉不是特别理解，比如什么是target，为什么这样调用state状态文件，state.highstate又是什么意思。关于什么是target，参考另一篇博文《Salt之target介绍》，那么关于剩下的问题我将在本博文后面以一个小例子来让大家明白

init.sls介绍

关于此文件用得不是特别广范，但还是需要给大家介绍我们来看一个例子，先来看看我们的目录结构，这里test环境根目录下面的jdk目录结构。主要用来安装使用源码安装jdk7

jdk/
├── 7                     #根据安装的版本来划分目录，我们还可以安装jdk8等
│   ├── files               #用于存放文件的目录
│   │   ├── jdk-7u79-linux-x64.gz   #源码包
│   │   └── jdk.sh           #环境变量配置文件
│   ├── init.sls              #占且称之为目录初始化状态文件
│   └── install.sls            #安装状态文件
└── 8
├── files
│   ├── jdk-8u102-linux-x64.tar.gz
│   └── jdk.sh
└── install.sls

再看看我们init.sls文件的内容

include:              #特殊模块，用于包含其它模块
- jdk.7.install        #被包含模块的路径，以环境根目录开始

从上面我们可以看出为什么我们jdk8的没有init.sls，这个文件有一个特殊的作用，那可有可无，下面我们将以安装jdk8和jdk7来演示为什么可有可无
安装jdk7

salt "*node1" state.sls jdk.7 saltenv=test

上面的命令我们安装jdk7我们使用的是state.sls，所以我们后面要跟模块的名称，模块名称需要从环境根目录开始，到最终我们使用的模块。但上面我们使用的是jdk.7，而7是一个目录，并不是state状态文件，所以这时候我们的init.sls就起到了这样一个作用，当最后所指的状态文件为一个目录时，那么系统会自动找到该目录下面的init.sls状态文件，而此文件我们包含了我们安装jdk所需要的模块，最后通过此文件来执行，如果该目录下面也没有init.sls那么就会直接报错，找不到可执行的状态文件。saltenv=test表示指定环境为test环境
安装jdk8

salt "*node1" state.sls jdk.8.install saltenv=test test=True

从上面的目录结构我们可以看出jdk/8/这个目录下面并没有init.sls，所以这时候我们需要最终指定一个状态文件，test=True表示不直接执行，而先测试执行过程，确认执行过程正确后再取消此选项真正的执行
注：上面所讲的方法不仅可以用于salt命令行，同样试用于state状态文件之间的引用

Jinja介绍

我们前面的博文中已经讲过salt是完全基于Python开发的自动化运维配置管理工具，Jinja是基于Python的模板引擎，我们可以通过使用jinja模板在state状态配置文件里面实现条件判断，循环，变量引用等一些功能。比如我们要部署Nginx+keepalived负载均衡，那么我们就可以通过jinja的条件判断来实现区分master和slave，又或者我们需要指定Nginx配置文件，但配置文件里面的参数都不固定我们可以通过变量来解决。所以jinja在salt的应用非常的多，很广泛，如果使用得好的话，可以让你的项目可读性，执行效率更高，更加的高大上，更能体能salt自动化的功效，我们首先介绍下几种jinja的语法：
变量

条件判断
下面将以使用salt管理客户端DNS配置文件为例来演示变量和条件判断的使用

cd /srv/salt/test        #进入我们的测试环境根目录
mkdir files           #新建一个存放文件的目录
touch files/resolv.conf     #创建DNS模板文件
touch nameserver.sls       #创建状态配置文件

#resolv.conf文件内容如下

dns manager:                   #任务的ID
file.managed:                 #状态管理模块file的managed方法，用来管理文件
- name: /etc/resolv.conf        #每个模块方法都有一个 -name 属性，此属性可写在ID处，代表ID，如果这样的话这里就需要再写 -name属性
- source: salt://files/resolv.conf   #源文件
- user: root              #定义属主
- group: root              #定义属组
- mode: 644               #定义权限
- template: jinja            #标记此状态文件为jinja，否则将视为普通状态文件调用
{% if grains['fqdn'] == "kubernetes-node1" %}    #第一个条件
DNS_SERVER: 192.168.1.10           #第一个条件为真执行的动作，定义变量
{% elif grains['fqdn'] == "kubernetes-node2" %}   #第二个条件
DNS_SERVER: 192.168.1.11           #第二个条件为真执行的动作，定义变量
{% endif %}                                        #条件结束，不管是多分支还是单分支都必须要有结束

#nameserver.sls文件内容如下

# Generated by NetworkManager
nameserver {{ DNS_SERVER }}        #引用变量

执行命令：

salt "*" state.sls nameserver saltenv=test

当执行完成命令后我们fqdn名称为kubernetes-node1的DNS将设置为192.168.1.10而kubernetes-node2的DNS将设置为192.168.1.11
扩展：在jinja里面的变量我们还可以引用pillar和salt命令执行的结果，方法如下
{{ salt['network.hw_addr']('eth0') }}
{{ pillar['apache']['PORT'] }}

循环
关于循环如果后续有时间将以实现反向代理（Nginx/HAProxy）动态添加后端服务器为例展示

最后：本博文内容不多，主要是以后面实战为主，欢迎大家收藏，关注我的博客，后续有时间会陆续补上一些实战的项目配置