@cdmonkey 2017-04-21T09:58:46.000000Z 字数 10963 阅读 1557

Saltstack（1）入门

Saltstack

此处输入图片的描述
http://www.saltstack.cn
http://docs.saltstack.cn/zh_CN/latest
http://www.0550go.com/automation-deployment/saltstack/saltstack-install.html
Official Documents: https://docs.saltstack.com/en/latest/

一、简介

具体内容请见学习笔记。

二、安装

注意，于生产中使用“Saltstack”过程中是使用DNS对主机名进行解析的。

此处输入图片的描述

1. 安装eple源

[root@salt-master ~]# rpm -ivh http://mirrors.sohu.com/fedora-epel/6/x86_64/epel-release-6-8.noarch.rpm
Retrieving http://mirrors.sohu.com/fedora-epel/6/x86_64/epel-release-6-8.noarch.rpm
warning: /var/tmp/rpm-tmp.MqJehV: Header V3 RSA/SHA256 Signature, key ID 0608b895: NOKEY
Preparing...                ########################################### [100%]
   1:epel-release           ########################################### [100%]

官方安装：
https://docs.saltstack.com/en/latest/topics/installation/rhel.html

2. 安装服务器端与客户端

如果我们使用“Master/Minion”模式，当然，这也是最为常用的模式，那么我们需要分别于服务器端及客户端（被管理的节点）进行安装操作。还有就是真的不要太纠结于如何进行安装，简单易用就好，当然根据企业特点定制的rmp包是非常不错的选择，如果没有，直接进行YUM安装就好了。

Master

# Install Master：
[root@salt-master ~]# yum install -y salt-master
[root@salt-master ~]# /etc/init.d/salt-master start
Starting salt-master daemon:                               [  OK  ]
[root@salt-master ~]# chkconfig salt-master on
--------------------
[root@salt-master ~]# ll /etc/salt/
total 32
-rw-r----- 1 root root 26614 Apr  7 22:22 master
drwxr-xr-x 3 root root  4096 Apr 30 16:52 pki
--------------------
# Check port:
[root@salt-master ~]# netstat -lntup|grep python
tcp        0      0 0.0.0.0:4505        0.0.0.0:*           LISTEN      31697/python2.6     
tcp        0      0 0.0.0.0:4506        0.0.0.0:*           LISTEN      31709/python2.6

能够看到，控制节点（Master）默认监听两个端口：

4505（publish_port）：消息发布系统。
4506（ret_port）：客户端与服务端通信的端口。

Minion

首先，你需要告诉你的被控节点怎样找到并连接到你的主控节点。即使你运行主控节点与被控节点在同一台服务器上，你仍然要告诉被控节点你的“master”在哪里。

# Install Minion：
[root@Node-A2 ~]# yum install -y salt-minion
[root@Node-A2 ~]# vim /etc/salt/minion
master: 172.16.1.21
cachedir: /etc/salt/modules
log_file: /var/log/salt/minion.log
log_level: warning
# 假如主控和被控节点运行在同一台服务器上，那么需要改为：master: 127.0.0.1
--------------------
[root@Node-A2 ~]# /etc/init.d/salt-minion start
Starting salt-minion daemon:                               [  OK  ]
[root@Node-A2 ~]# chkconfig salt-minion on
# 若需要重新加载配置文件：

至此能够于控制端查看下当前有哪些客户端可以识别到：

[root@salt-master ~]# salt-key 
# OR:
[root@salt-master ~]# salt-key -L
Accepted Keys:
Denied Keys:
Unaccepted Keys:
Node-A2    # Minion ID，默认显示的是主机名（FQDN），生产场景中可直接使用主机名。
Node-A3
Rejected Keys:

因为当前没有将任何的被控节点纳入到控制节点的控制之下，所以虽然可以识别到有两个被控节点，但是它们是处于未被认证、接受的状态。我们接下来要做的就是在控制端上进行对被控节点（或者说是客户端）进行认证、添加。

当然我们也可为被控节点指定专门的标识“Minion ID”，而替代主机名。如果于实际生产中主机名能够很好的反映出主机的相关信息，那么我们直接使用主机名即可。如果有特殊需求，我们也可另行指定“Minion ID”给被控端节点。下面的实验中，我们就使用这个指定的标识。

# 默认标识存放的位置：
[root@Node-A2 ~]# ll /etc/salt/
total 40
-rw-r----- 1 root root 24880 Jun 14 15:44 minion
drwxr-xr-x 2 root root  4096 Jun 14 09:51 minion.d
-rw-r--r-- 1 root root     7 Jun 14 09:51 minion_id    # 这个文件存储着当前的被控端标识，默认是主机名。
drwxr-xr-x 3 root root  4096 Jun 14 09:51 pki
[root@Node-A2 ~]# cat /etc/salt/minion_id 
Node-A2
# 如果你要指定标识则需要删除这个文件（否则的话两个ID都会显示出来）：
[root@Node-A2 salt]# mv minion_id /tmp
---------------------
# Configure Minion ID：
[root@Node-A2 ~]# vim /etc/salt/minion
id: node2.cdmonkey.com

完成上述设定之后需要重启服务：

[root@Node-A2 ~]# /etc/init.d/salt-minion restart
Stopping salt-minion daemon:                               [  OK  ]
Starting salt-minion daemon:                               [  OK  ]

实际证明：新旧两个“Minion ID”还是都会被显示出来，比较操蛋。可使用下面的指令将多余的ID移除：

[root@test-ngx ~]# salt-key -d test-mbs
The following keys are going to be deleted:
Unaccepted Keys:
test-mbs
Proceed? [N/y] y
Key for minion test-mbs deleted.

三、认证

1. 认证节点

目前你的被控节点已经知道到主控节点于哪里，接下来让他们进行彼此验证，Salt使用公共密钥加密来确保主控及被控节点间的安全通信。你需要通过于控制端验证被控节点的证书来明确它们之间的是受信的。

控制端节点是依靠“openssl”证书来与受控端主机认证通讯的，受控端启动后会发送给控制端一个公钥证书文件，而主控端使用“salt-key”命令来管理证书。认证被控端的证书使同样使用该命令，Salt自动生成这些证书，你需要做的仅仅是认证你需要的证书。我们首要做的就是要进行客户端节点的身份验证，也就是说要将这个被控端节点加进来。

# 使用下面的方法添加某一被控节点：
[root@salt-master ~]# salt-key -a node2.cdmonkey.com
The following keys are going to be accepted:
Unaccepted Keys:
node2.cdmonkey.com
Proceed? [n/Y] Y
Key for minion node2.cdmonkey.com accepted.
# 如法炮制，我们将另一个节点也添加进来：
[root@salt-master ~]# salt-key -a node3.cdmonkey.com

控制端及被控端的证书默认都存放在/etc/salt/pki/目录中，如果遇到证书不生效的情况下，可于控制端证书存放目录移除被控端证书，重新认证一下。也可以接受所有请求的证书：

# Accept all minions:
salt-key -A

认证添加完成之后，我们可以执行一个探测指令：

[root@salt-master ~]# salt '*' test.ping
node2.cdmonkey.com:
    True
node3.cdmonkey.com:
    True
# 以上输出说明服务端到客户端通信正常，基础环境搭建成功。
# 星号表示对所有的节点执行相应指令，但是有时我们又需要指定具体的节点进行操作：
[root@salt-master ~]# salt node2.cdmonkey.com test.ping
node2.cdmonkey.com:
    True

注意：生产中可别直接使用星号来匹配所有的节点。

2. 移除节点

salt-key -d

移除被控节点时最好将该节点的客户端服务进程关闭，否则有时会导致移除后又会自动加回来。

3. 关于密钥

无论是控制节点还是被控节点都会生成密钥对，实际上认证的过程就是将自己的公钥交由对方，这对控制端和被控端来说都一样。下面是被控端存储的密钥信息：

[root@Node-A2 minion]# ll
total 12
-r-------- 1 root root 1675 Jun 14 09:51 minion.pem    #自己的私钥。
-rw-r--r-- 1 root root  451 Jun 14 09:51 minion.pub    #自己的公钥。
-rw-r--r-- 1 root root  451 Jun 14 16:12 minion_master.pub    #控制端节点的公钥。

控制端存储密钥的目录就要相对复杂些：

[root@salt-master master]# ll
total 28
-r-------- 1 root root 1679 Jun 14 09:40 master.pem
-rw-r--r-- 1 root root  451 Jun 14 09:40 master.pub
drwxr-xr-x 2 root root 4096 Jun 14 16:14 minions
drwxr-xr-x 2 root root 4096 Jun 14 09:40 minions_autosign
drwxr-xr-x 2 root root 4096 Jun 14 09:40 minions_denied
drwxr-xr-x 2 root root 4096 Jun 14 16:14 minions_pre
drwxr-xr-x 2 root root 4096 Jun 14 09:40 minions_rejected
[root@salt-master master]# cd minions    #所有被认证并添加的被控端的公钥都会存储到这个目录内，如下所示：
[root@salt-master minions]# ll
total 8
-rw-r--r-- 1 root root 451 Jun 14 15:53 node2.cdmonkey.com
-rw-r--r-- 1 root root 451 Jun 14 15:54 node3.cdmonkey.com

控制端与被控端一旦完成认证，双方就会建立长连接，如下所示，所以控制端通过4505端口发出的指令能够很快的被控制端所接收。

[root@salt-master ~]# lsof -i:4505
COMMAND     PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
salt-mast 39885 root   12u  IPv4 103590      0t0  TCP *:4505 (LISTEN)
salt-mast 39885 root   14u  IPv4 103622      0t0  TCP Node-A1:4505->Node-A3:40623 (ESTABLISHED)
salt-mast 39885 root   15u  IPv4 105515      0t0  TCP Node-A1:4505->Node-A2:33903 (ESTABLISHED)

四、远程执行

https://docs.saltstack.com/en/getstarted/fundamentals/remotex.html

于远程主机上运行预定义或任意的命令，即远程执行，为“Saltstack”的核心功能。

注意：远程执行是Salt的根基所在。

很多时候我们需要临时的查看一台或多台机器上的某个文件，或者执行某个命令，最通用的模块是“cmd.run”。我们能够使用该模块来对被控端节点执行任何的系统指令，但是如果服务器规模小还可以这样操作，但如果规模很大，就不建议使用该命令，因为容易造成误操作，万一误运行了移除指令那就太危险了，因而大规模的服务器或者是大的团队都不建议使用它。

[root@salt-master ~]# salt '*' cmd.run 'uptime'
node3.cdmonkey.com:
     16:21:13 up  4:25,  2 users,  load average: 0.00, 0.00, 0.00
node2.cdmonkey.com:
     16:21:13 up  4:17,  3 users,  load average: 0.00, 0.00, 0.00
---------------------
#指令的格式：
salt <target> module.method <parameter>

模块是远程执行的基础。它提供了一系列的功能，比如安装软件包，重启一个服务，运行名称命令，传输文件等等。

五、配置管理

顾名思义就是将被控节点的设定文件进行管理，用主控节点的文件内容来控制被控节点相应文件的内容，即主控节点的文件是什么内容，那么被控节点的文件就是什么内容。控制节点会去将自身保存的文件的“MD5”码及文件内容与被控节点进行对比，如果不同，那么会同步一份给被控节点，从而保证主控节点与被控节点的文件一致。

当然，配置管理不仅限于对设定文件的管理，好包括操作系统安装了那某些软件包、安装了哪些服务及其运行状态。换句话说，这是一种对“状态”的管理，控制节点的salt中描述了哪些状态（有哪些内容的设定文件、软件包的安装、服务的启停等），那么被控节点就要处于该种状态。

该管理框架是创建于远程执行的核心功能之上。使用小的、易读易理解的sls文件表示被控节点的状态。

1. Config master

说到设定文件，首先得说下默认的设定文件的路径，就是说使控制端节点知道设定文件放于什么地方。

[root@salt-master ~]# vim /etc/salt/master
default_include: master.d/*.conf */
interface: 0.0.0.0      # 服务端监听的地址，这里表示监听所有地址。
file_roots:      # 指定配置文件的存放地点，目录可以任意指定。与远程管理相关配置文件全部都在这个目录下。
  base:          # 基本内容是必须要指定的。
    - /etc/salt/states
  prod:
    - /etc/salt/states/prod
state_top: top.sls     # 该文件是配置管理的入口，这行注释打不打开皆可，因为是默认的。
# Be careful: To follow the "YAML" syntax format.
-----------------
# 按照上面的内容创建目录：
[root@salt-master ~]# mkdir -p /etc/salt/states/prod
# Restart the service:
[root@salt-master ~]# /etc/init.d/salt-master restart

如上所示，设定文件是分场景的安排的，分为了基本（base，是必备的）及生产（prod）场景。

Log file

[root@salt-master ~]# ll /var/log/salt/master 
-rw-r--r-- 1 root root 0 Apr 30 16:52 /var/log/salt/master

2. Create Status file

http://blog.liuker.cn/index.php/saltstack/9.html

top.sls

默认情况下top.sls是设定管理的入口文件（引导设定文件），一切都是从它开始，我们要将所有要控制的节点写入到该文件中。当然你可于主设定件中将其指定为自定义的文件名。注意，该文件要位于“base”的根目录下。

# 设置配置入口文件的配置项为下面这项，默认是注释掉的，也就是默认的。
state_top: top.sls

我们于生产中应该把不同的设定管理按其功能进行归类，以文件夹的形式进行组织。例如我们将服务器系统初始化的管理归为一类：

# 创建系统初始化的目录，那么我们以后就把所有的与初始化相关的状态文件都放到该目录下。
[root@salt-master states]# mkdir init
[root@salt-master ~]# cd /etc/salt/states/
[root@salt-master states]# vim top.sls
base:      # 要首先声明适用的场景。
  'node2.cdmonkey.com':      # Matching
    - init.pkg     # 状态文件的路径，表示我们将会使用初始化目录中的“pkg”状态文件。

引导设定文件top.sls的作用为用来说明什么场景下匹配的目标要执行什么状态文件。其默认是从“base”标签开始解析执行，下一级是操作的目标，能够经由正则、grain模块或者分组名，来进行匹配，再下一级是要执行的状态文件（不包含扩展名），如图所示：

此处输入图片的描述

注意状态文件的书写：点号前面为该场景根目录下的子目录，点号后面为该目录内的文件。
引导设定文件修改后无需重启控制端的服务进程，因为每次执行salt指令时都会读取该文件。

Install package

我们首先进行的是软件包的安装。因为前面我们已经规划好了初始化目录，所以接下来要在该目录下创建状态文件：

[root@salt-master ~]# cd /etc/salt/states/init
[root@salt-master init]# vim pkg.sls
init.pkg:      # 为我将要进行的操作起个ID（描述信息），声明一个名称。因为其仅仅是一个名字，因而能任意指定。
  pkg.installed:      # 定义一个模块的方法，pkg是一个状态模块（包的管理模块），是关键字。
    - names:          # 指定要安装的包的名称。
      - nmap
      - lrzsz

sls1.png-4.3kB

注意：使用“YAML”的语法进行书写，其中的冒号表示“键值对”，而缩进则表示层级关系。

我们总结下状态天文件的写法：

ID:    # String that describes this state. Must be unique.
  module.function:   # The State module and function that you want to call.
    - name: name     # Every function takes 'name' as the first argument.
    - argument: value     # Other arguments are listed under the function.
    - argument:
      - value1
      - value2

我们先使用第一种同步状态的指令：

[root@salt-master init]# salt '*' state.sls init.pkg
node2.cdmonkey.com:      # 首先显示的是节点主机。
----------
          ID: init.pkg        # 声明的操作代号。
    Function: pkg.installed   # 使用的模块及其方法。
        Name: nmap
      Result: True
     Comment: The following packages were installed/updated: nmap.
     Started: 14:26:11.772996     # Start time
    Duration: 194830.755 ms       # Duration time
     Changes:   
              ----------
              nmap:
                  ----------
                  new:
                      5.51-4.el6
                  old:
----------
          ID: init.pkg
    Function: pkg.installed
        Name: lrzsz
      Result: True
     Comment: Package lrzsz is already installed.
     Started: 14:29:26.604043
    Duration: 0.551 ms
     Changes:   
Summary
------------
Succeeded: 2 (changed=1)
Failed:    0
------------
Total states run:     2

控制端对目标主机（targeted minions）发出指令运行指定的模块，目标主机首先会对top.sls下载，并进行解析，然后依照top.sls内匹配规则内的定义的模块将被下载、解析、执行，然后将结果反馈给控制端。

File Management

对于文件进行管理，首先创建状态文件：

[root@salt-master ~]# cd /etc/salt/states/init/
[root@salt-master init]# vim limit.sls
limit-conf:       # Declare the name of the state (operation).
  file.managed:   # Module & Method
    - name: /etc/security/limits.conf          # Target file
    - source: salt://init/files/limits.conf    # Also supports HTTP FTP and other protocols
    - user: root
    - group: root
    - mode: 644
# 依照上述的配置内容创建相应的目录：
[root@salt-master init]# mkdir files
[root@salt-master init]# cd files/
[root@salt-master files]# cp /etc/security/limits.conf .
# 我们可以将该源文件进行一些修改，以便将修改过的文件同步到被控端节点上去：
[root@salt-master files]# vim limits.conf
65535 --> 65530

创建好状态文件后，千万不要忘记在top.sls上添加相应的内容：

[root@salt-master states]# vim top.sls
base:
  'node2.cdmonkey.com':
    - init.pkg
    - init.limit

最后于控制节点上执行“salt”指令（第二种同步状态的指令）：

[root@salt-master ~]# salt '*' state.highstate
node3.cdmonkey.com:     # 该节点因为没有在“TOP”文件中定义，所以这里显示该节点没有被匹配到。
----------
          ID: states
    Function: no.None
      Result: False
     Comment: No Top file or external nodes data matches found
     Started: 
    Duration: 
     Changes:   
Summary
------------
Succeeded: 0
Failed:    1
------------
Total states run:     1
node2.cdmonkey.com:
----------
          ID: init.pkg
    Function: pkg.installed
        Name: nmap
      Result: True
     Comment: Package nmap is already installed.
     Started: 10:36:09.653215
    Duration: 949.957 ms
     Changes:   
----------
          ID: init.pkg
    Function: pkg.installed
        Name: lrzsz
      Result: True
     Comment: Package lrzsz is already installed.
     Started: 10:36:10.603377
    Duration: 0.592 ms
     Changes:   
----------
          ID: limit-conf
    Function: file.managed
        Name: /etc/security/limits.conf
      Result: True
     Comment: File /etc/security/limits.conf updated
     Started: 10:36:10.691404
    Duration: 31.763 ms
     Changes:
              ----------
              diff:     # 由这里开始显示的就是源文件和目标文件的差异了。
                  ---
                  +++
                  @@ -48,4 +47,4 @@
                   # End of file
                  -*               -       nofile          65535 
                  +*               -       nofile          65530 
Summary
------------
Succeeded: 3 (changed=1)
Failed:    0
------------
Total states run:     3

如果使用上面这种ID声明的方法，则需要注意，同一个ID下，同样类型的“模块”只能使用一次。

state.sls & state.highstate

能够看到，这两个状态同步的“模块·方法”的运行是不同的：

state.sls：其默认的运行场景是“base”场景，但它并不读取top.sls引导设定文件，因而使用该指令时需指定执行某个状态文件。其也能够指定其他场景：state.sls salt_env='prod' xxx.sls
state.highstate：适用于全局的所有场景，且所有状态都生效。它会读取每一个场景的top.sls文件，并且执行里面定义的全部状态文件，使所有的状态都生效，而top.sls文件里面没有记录的状态文件则不会被执行。

highstate：
# 给被控节点永久的添加状态，从.sls文件读取到的，即同步状态配置。

3. About SLS

SLS：SaLt State
它是整个系统的核心。该类文件描述了系统的目标状态，由格式简单的数据构成。其主要用来描述系统，软性，服务，配置文件应该处于的状态，常常被称为配置管理。

Name Space

子目录可以更好的组织，每个子目录都由一个点来表示。如果子目录创建一个init.sls的文件，引用的时候仅指定该目录即可。