saltstack syndic安装配置使用

salt-syndic是做神马的呢?如果大家知道zabbix proxy的话那就可以很容易理解了,syndic的意思为理事,其实如果叫salt-proxy的话那就更好理解了,它就是一层代理,如同zabbix proxy功能一样,隔离master与minion,使其不需要通讯,只需要与syndic都通讯就可以,这样的话就可以在跨机房的时候将架构清晰部署了,建议zabbix proxy与salt-syndic可以放在一起哦

本次我萌使用node2作为node3的代理让他收到node1(master)的控制

在node1(master)上配置

1 [[email protected] ~]# grep "^[a-Z]" /etc/salt/master
2 default_include: master.d/*.conf
3 file_roots:
4 order_masters: True                        # 修改这里,表示允许开启多层master

在node2上安装配置

 1 [[email protected] salt]# yum install salt-syndic -y
 2 [[email protected] salt]# cd /etc/salt/
 3 [[email protected] salt]# grep "^[a-Z]" proxy
 4 master: 192.168.56.11                                    # proxy文件里
 5 [[email protected] salt]# grep "^[a-Z]" master
 6 syndic_master: 192.168.56.11                            # master文件里
 7 [[email protected] salt]# systemctl start salt-master.service
 8 [[email protected] salt]# systemctl start salt-syndic.service
 9 [[email protected] salt]# netstat -tpln
10 Active Internet connections (only servers)
11 Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
12 tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      1/systemd
13 tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      998/sshd
14 tcp        0      0 0.0.0.0:4505            0.0.0.0:*               LISTEN      6013/python
15 tcp        0      0 0.0.0.0:4506            0.0.0.0:*               LISTEN      6019/python
16 tcp6       0      0 :::111                  :::*                    LISTEN      1/systemd
17 tcp6       0      0 :::22                   :::*                    LISTEN      998/sshd      

node3上正常安装minion

1 [[email protected] salt]# yum install salt-minion -y
2 [[email protected] salt]# cd /etc/salt/
3 [[email protected] salt]# grep "^[a-Z]" minion
4 master: 192.168.56.12                                # 此时只需要认定node2就好,不需要知道node1的存在
5 [[email protected] salt]# systemctl start salt-minion

然后回到node2(syndic)

1 [[email protected] salt]# salt-key -L
2 Accepted Keys:
3 Denied Keys:
4 Unaccepted Keys:
5 linux-node3.example.com
6 Rejected Keys:
7 [[email protected] salt]# salt-key –A                # 把key接受了

最后回到node1(master)

 1 [[email protected] ~]# salt-key –L                    # 发现并没有linux-node3.example.com
 2 Accepted Keys:
 3 linux-node1.example.com
 4 linux-node2.example.com
 5 Denied Keys:
 6 Unaccepted Keys:
 7 Rejected Keys:
 8 [[email protected] ~]# salt ‘*‘ test.ping
 9 linux-node2.example.com:
10     True
11 linux-node1.example.com:
12     True
13 linux-node3.example.com:                        # 但是它会出现效果
14 True

其他的同层代理及多层代理的配置也是相同的,只需要分清每个代理的上层master就好

这里有一些常见的问题

1.我代理之下控制的是否可以重名?举个例子就是node3的id改成node2,然后在总master上执行会有什么情况?

首先我萌要涉及到修改id啦,小伙伴还记得修改id的流程吗~~

 1 [[email protected] salt]# systemctl stop salt-minion.service    # 停止minion
 2 [[email protected] salt]# salt-key –L            # 注意是在node2(syndic)上哦,因为node3的眼里的master是node2,并且把key是发送给node2了哦,删除它
 3 Accepted Keys:
 4 linux-node3.example.com
 5 Denied Keys:
 6 Unaccepted Keys:
 7 Rejected Keys:
 8 [[email protected] salt]# salt-key -d linux-node3.example.com
 9 The following keys are going to be deleted:
10 Accepted Keys:
11 linux-node3.example.com
12 Proceed? [N/y] y
13 Key for minion linux-node3.example.com deleted.
14 [[email protected] salt]# rm -fr /etc/salt/pki/minion/            # 删除minion端/etc/salt/pki/minion下所有文件
15 [[email protected] salt]# grep "^[a-Z]" /etc/salt/minion        # 修改新id
16 master: 192.168.56.12
17 id: linux-node2.example.com                                # 配置一个已有的重复id做测试
18 [[email protected] salt]# systemctl start salt-minion.service    # 再次启动minion
19 [[email protected] salt]# salt-key –L                        # 回到node2再次接受新id的key
20 Accepted Keys:
21 Denied Keys:
22 Unaccepted Keys:
23 linux-node2.example.com
24 Rejected Keys:
25 [[email protected] salt]# salt-key -A
26 The following keys are going to be accepted:
27 Unaccepted Keys:
28 linux-node2.example.com
29 Proceed? [n/Y] Y
30 Key for minion linux-node2.example.com accepted.
31 [[email protected] salt]# salt ‘*‘ test.ping                    # 简单测试下
32 linux-node2.example.com:
33 True
34
35 最后验证我们的测试,回到node1(master)
36 [[email protected] ~]# salt ‘*‘ test.ping
37 linux-node2.example.com:
38     True
39 linux-node1.example.com:
40     True
41 linux-node2.example.com:
42     True
43 我萌发现,wtf,什么鬼,linux-node2.example.com居然出现了两次,虽然已经想过这种情况,但是在实际使用中我肯定是分不清谁是谁了,所以这种使用了代理后依然id重名的方式依然是很不好的,所以还是建议大家把id要分清楚哦,最简单的方式就是设置合理的主机名,这样所有的机器都不会重复,而且连设置id这个事情都可以省略了(我已经将node3的id改回去了)

2.远程执行没有问题了,这种架构下状态文件的执行会不会有影响呢?

  1 [[email protected] base]# pwd                    # 我们在master上定义top
  2 /srv/salt/base
  3 [[email protected] base]# cat top.sls                 # 其实就是给大家传输了个文件
  4 base:
  5   ‘*‘:
  6     - known-hosts.known-hosts
  7 [[email protected] base]# cat known-hosts/known-hosts.sls
  8 known-hosts:
  9   file.managed:
 10     - name: /root/.ssh/known_hosts
 11     - source: salt://known-hosts/templates/known-hosts
 12     - clean: True
 13 [[email protected] base]# salt ‘*‘ state.highstate
 14 linux-node3.example.com:
 15 ----------
 16           ID: states
 17     Function: no.None
 18       Result: False
 19      Comment: No Top file or master_tops data matches found.
 20      Changes:
 21
 22 Summary for linux-node3.example.com
 23 ------------
 24 Succeeded: 0
 25 Failed:    1
 26 ------------
 27 Total states run:     1
 28 Total run time:   0.000 ms
 29 linux-node2.example.com:
 30 ----------
 31           ID: known-hosts
 32     Function: file.managed
 33         Name: /root/.ssh/known_hosts
 34       Result: True
 35      Comment: File /root/.ssh/known_hosts updated
 36      Started: 11:15:35.210699
 37     Duration: 37.978 ms
 38      Changes:
 39               ----------
 40               diff:
 41                   New file
 42               mode:
 43                   0644
 44
 45 Summary for linux-node2.example.com
 46 ------------
 47 Succeeded: 1 (changed=1)
 48 Failed:    0
 49 ------------
 50 Total states run:     1
 51 Total run time:  37.978 ms
 52 linux-node1.example.com:
 53 ----------
 54           ID: known-hosts
 55     Function: file.managed
 56         Name: /root/.ssh/known_hosts
 57       Result: True
 58      Comment: File /root/.ssh/known_hosts is in the correct state
 59      Started: 11:15:35.226119
 60     Duration: 51.202 ms
 61      Changes:
 62
 63 Summary for linux-node1.example.com
 64 ------------
 65 Succeeded: 1
 66 Failed:    0
 67 ------------
 68 Total states run:     1
 69 Total run time:  51.202 ms
 70 ERROR: Minions returned with non-zero exit code
 71 显而易见的node3发生了错误,而node1跟node2正常(很好理解),我们去看node3报出的“No Top file or master_tops data matches found”,言简意赅没有找到匹配的top执行文件,简单推断出是因为node3认证的master是node2,但是node2上没有写top,我们去node2上写一个不同的top再次测试下
 72 [[email protected] base]# pwd
 73 /srv/salt/base
 74 [[email protected] base]# cat top.sls                     # 这个更简单了,就是ls /root
 75 base:
 76   ‘*‘:
 77     - cmd.cmd
 78 [[email protected] base]# cat cmd/cmd.sls
 79 cmd:
 80   cmd.run:
 81     - name: ls /root
 82 好的我们回到master上再次测试,我将node1、2正常执行的信息省略
 83 [[email protected] base]# salt ‘*‘ state.highstate
 84 linux-node3.example.com:
 85 ----------
 86           ID: cmd
 87     Function: cmd.run
 88         Name: ls /root
 89       Result: True
 90      Comment: Command "ls /root" run
 91      Started: 11:24:42.752326
 92     Duration: 11.944 ms
 93      Changes:
 94               ----------
 95               pid:
 96                   5095
 97               retcode:
 98                   0
 99               stderr:
100               stdout:
101                   lvs.sh
102
103 Summary for linux-node3.example.com
104 ------------
105 Succeeded: 1 (changed=1)
106 Failed:    0
107 ------------
108 Total states run:     1
109 Total run time:  11.944 ms
110 我们已经可以看出一些端倪,我们再次修改master的配置文件并执行测试
111 [[email protected] base]# cat top.sls
112 base:
113   ‘linux-node3.example.com‘:                        # 只定义执行node3
114     - known-hosts.known-hosts
115 [[email protected] base]# salt ‘*‘ state.highstate
116 linux-node3.example.com:
117 ----------
118           ID: cmd
119     Function: cmd.run
120         Name: ls /root
121       Result: True
122      Comment: Command "ls /root" run
123      Started: 11:28:20.792475
124     Duration: 8.686 ms
125      Changes:
126               ----------
127               pid:
128                   5283
129               retcode:
130                   0
131               stderr:
132               stdout:
133                   lvs.sh
134
135 Summary for linux-node3.example.com
136 ------------
137 Succeeded: 1 (changed=1)
138 Failed:    0
139 ------------
140 Total states run:     1
141 Total run time:   8.686 ms
142 linux-node2.example.com:
143 ----------
144           ID: states
145     Function: no.None
146       Result: False
147      Comment: No Top file or master_tops data matches found.
148      Changes:
149
150 Summary for linux-node2.example.com
151 ------------
152 Succeeded: 0
153 Failed:    1
154 ------------
155 Total states run:     1
156 Total run time:   0.000 ms
157 linux-node1.example.com:
158 ----------
159           ID: states
160     Function: no.None
161       Result: False
162      Comment: No Top file or master_tops data matches found.
163      Changes:
164
165 Summary for linux-node1.example.com
166 ------------
167 Succeeded: 0
168 Failed:    1
169 ------------
170 Total states run:     1
171 Total run time:   0.000 ms
172 ERROR: Minions returned with non-zero exit code
173 我们发现这次node1跟node2出刚才问题了,而node3执行的是node2上定义的top,好吧,这时候就要发挥小北方的作用!
174 北方的总结:
175 每个minion会去找自己master里定义的top并执行,即node1、2找的是master的,而node2找的是syndic(node2)的
176
177 “No Top file or master_tops data matches found”出现是因为我每次执行都是salt ‘*‘ state.highstate,即让所有机器都查找top文件并执行对应操作,第一次node3出现问题是因为它听从的top文件在syndic上,当时syndic上我还没有写top所以他找不到匹配自己的;第二次我把top里执行的*换成了node3单独一个,没有node1跟node2的相关操作了,他们接受到指令并来查找top文件想执行相关操作发现没匹配自己也因此报错,就跟刚才node3找不到是一个意思
178
179 一下子还是无法理解呢,那么怎么办呢,有一个规范的做法就是,将master的文件目录直接拷到所有的syndic上,这样就可以保证所有的操作都是统一的了,如同没有代理的时候一样

3.top好麻烦呀,那么我普通的执行sls文件会怎么样呢?

 1 [[email protected] base]# salt ‘*‘ state.sls  known-hosts.known-hosts
 2 linux-node3.example.com:
 3     Data failed to compile:
 4 ----------
 5     No matching sls found for ‘known-hosts.known-hosts‘ in env ‘base‘
 6 linux-node2.example.com:
 7 ----------
 8           ID: known-hosts
 9     Function: file.managed
10         Name: /root/.ssh/known_hosts
11       Result: True
12      Comment: File /root/.ssh/known_hosts is in the correct state
13      Started: 11:46:03.968021
14     Duration: 870.596 ms
15      Changes:
16
17 Summary for linux-node2.example.com
18 ------------
19 Succeeded: 1
20 Failed:    0
21 ------------
22 Total states run:     1
23 Total run time: 870.596 ms
24 linux-node1.example.com:
25 ----------
26           ID: known-hosts
27     Function: file.managed
28         Name: /root/.ssh/known_hosts
29       Result: True
30      Comment: File /root/.ssh/known_hosts is in the correct state
31      Started: 11:46:05.003462
32     Duration: 42.02 ms
33      Changes:
34
35 Summary for linux-node1.example.com
36 ------------
37 Succeeded: 1
38 Failed:    0
39 ------------
40 Total states run:     1
41 Total run time:  42.020 ms
42 ERROR: Minions returned with non-zero exit code
43 我么看到node3又报错了,“No matching sls found for ‘known-hosts.known-hosts‘ in env ‘base‘”,我甚至都不需要验证都知道是怎么回事了,直接复制下来
44
45 每个minion会去找自己master里定义的sls并执行,即node1、2找的是master的,而node2找的是syndic(node2)的
46
47 所以如果你在syndic定义个known-hosts但是里面执行些其他操作那么node3就会按这个来了,但是没有人会这么乱七八糟的搞,因此:保证各个syndic与master的文件目录保持统一!
时间: 2024-11-06 03:40:27

saltstack syndic安装配置使用的相关文章

saltstack - salt-api安装配置

环境说明 操作系统:centos 7.0 salt master/minion/版本2014.7.1 Salt-api安装 salt-api 使用pip安装 [[email protected] ~]# pip install CherryPy [[email protected] ~]# pip install salt-api Salt-api配置 [[email protected] ~]# cd /etc/pki/tls/certs/  # 生成自签名证书,用于ssl [[email p

saltstack 快速安装配置

saltstack_quickstart.sh ## 0.Introduction Salt is: -- a configuration management system, capable of maintaining remote nodes in defined states (for example, ensuring that specific packages are installed and specific services are running) -- a distrib

SaltStack安装配置与远程执行测试

SaltStack是基于Python开发的服务器基础架构集中管理平台,也称为自动化运维工具,具备远程执行.配置管理.云管理三大功能.管理端称为Master,被管理端称为Minion,Master和Minion通过密钥认证进行加密通信,通过消息队列软件ZeroMQ进行内容传输,使用的默认端口为4505和4506.本文的主要内容为SaltStack的安装配置与远程执行测试. 一.环境准备 1.使用3台Redhat 6.5的服务器,分别是: salt-master:192.168.10.120 sal

saltstack安装配置(syndic)

syndic是saltstack用来做集群部署的,一般结构如图: syndic是一个特殊的minion,syndic类继承于minion类,syndic可以看作一个代理,只做数据传递. CentOS上安装master的时候就已经安装了Syndic.设置的时候只需将TopMaster的order_master设置为True,将Syndic的syndic_master 设置为 topmaster的hostname或IP即可. 下面是一个实例. role service hostname ip top

saltstack 安装配置详解

SaltStack是一个服务器基础架构集中化管理平台,具备配置管理.远程执行.监控等功能,一般可以理解为简化版的puppet和加强版的func.SaltStack基于Python语言实现,结合轻量级消息队列(ZeroMQ)与python第三方模块(Pyzmq.PyCrypto.Pyjinjia2.python-msgpack和PyYAML等)构建. 通过部署SaltStack环境,我们可以在成千上万台服务器上做到批量执行命令,根据不同业务特性进行配置集中化管理.分发文件.采集服务器数据.操作系统

saltstack安装配置(master&minion)草稿

操作系统centos6.3,centos6.4,windows server2008R2. 文中的下载链接可能会随着saltstack官网上版本的更新,而出现变动或错误,请以你需要安装的版本链接为准.我写上具体链接是为了近段时间重复操作时方便. 本文中,linux采用EPEL安装,windows选择exe安装包. 1.在你的系统中如果EPEL当前并不是enabled状态,你可以通过如下命令启用它. 对于RHEL 5: rpm -Uvh http://mirror.pnl.gov/epel/5/i

Saltstack 安装配置 及 简单操作示例

Saltstack 介绍 通过部署 Saltstack环境,可以在成千上万台服务器上批量执行命令.对于不同的业务进行集中管理.分发文件.采集数据.软件包管理等,有利于运维人员提高工作效率,规范业务配置和操作. Saltstack由 Master和 Minion构成, Master是服务端,表示一台服务器; Minion是客户服务端,表示多台服务器.在 Master上发送命令给符合条件的 Minion, Minion就会执行相应的命令, Master和 Minion之间是通过 Zeromq(消息队

saltstack之多节点nginx安装配置

多节点nginx安装配置 定义多节点 cd /srv/salt vim top.sls base:  'server4.lalala.com':    - nginx.install  'server1.lalala.com':    - nginx.install 把要共享的文件放在指定目录 [[email protected] files]# pwd /srv/salt/nginx/files [[email protected] files]# ls n ginx-1.10.1.tar.g

学习记录: 安装配置自动化工具ansible

学习记录:  安装配置ansible 更新日期: 2016-11-30 系统环境    :centos6.5 本机ip        :192.168.233.123 被管理机ip :192.168.233.124 ------------------------------------- py版本       :   默认python2.6 ansible版本:ansible 1.7.2 ansible参数:             -m  模块名(执行命令)              -a