Slatstack Syndic
Slatstack Syndic
当用salt管理手头的机子越来越多的时候如果只有一台master肯定会显得很吃力,而且也不便于管理,
打个比方说如果一个公司有3个子公司,每个子公司的主机都有一台master去管理 然后总公司只需要直接管理子公司的
master，也可以获取各个子公司minion端的数据。salt提供一个Syndic模式
下面开始说说我的配置：
|
1
2
3
|
master
192.168
.
6.170
secondmaster
192.168
.
6.171
id
:ceshi1
minion
192.168
.
6.172
id
：ceshi2
|
master操作:
|
1
2
3
4
|
vi
/
etc
/
salt
/
master
/
/
# 编辑master配置文件
order_masters:
True
....
/
etc
/
init.d
/
salt
-
master restart
/
/
# 重启master服务
|
secondmaster操作:
|
1
2
3
4
5
|
vi
/
etc
/
salt
/
master
/
/
# 编辑secondmaster配置文件
syndic_master:
192.168
.
6.170
...
/
etc
/
init.d
/
salt
-
master restart
/
/
# 重启master服务
/
etc
/
init.d
/
salt
-
syndic start
/
/
# 启动syndic服务
|
# master端看一下授权的key
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
# salt-key
Accepted Keys:
Unaccepted Keys:
ceshi1
ceshi3
-
win
efhsg
mfs_chunk112
mfs_chunk113
mfs_chunk114
mfs_chunk115
mfs_chunk117
mfs_chunk118
mfs_master111
Rejected Keys:
[root@test
/
etc
/
salt]
# salt-key -a ceshi1
|
# minion端:
|
1
2
3
4
5
|
vi
/
etc
/
salt
/
salt
-
minion
master:
192.168
.
6.171
...
/
etc
/
init.d
/
salt
-
minion start
/
/
# 重启minion服务
|
# secondmaster端查看key
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
# salt-key
Accepted Keys:
Unaccepted Keys:
ceshi2
Rejected Keys:
[root@salt
-
minion_6
/
etc
/
salt]
# salt-key -a ceshi2
The following keys are going to be accepted:
Unaccepted Keys:
ceshi2
Proceed? [n
/
Y] y
Key
for
minion ceshi2 accepted.
[root@salt
-
minion_6
/
etc
/
salt]
# salt-key
Accepted Keys:
ceshi2
Unaccepted Keys:
Rejected Keys:
|
# 好了所有的配置都完成了,咱们来测试一下(以下都在master端操作)
# 虽然在master端看不见minion端,但是可以向所有minion执行任何操作
|
1
2
3
4
|
[root@test
/
etc
/
salt]
# salt 'ceshi2' test.ping
ceshi2:
True
|
# 看了一下沈灿的blog 说到state配置 master端的top.sls state资源管理功能无法直接指定minion来做一些资源管理的,应该由它的master来控制(这里是secondmaster),自己验证一下
# 下面这个是我在master端做的一个文件推送功能
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
# cat top.sls
base:
'ceshi2'
:
-
test.wpython
[root@test
/
srv
/
salt]
# cat top.sls test/wpython.sls
base:
'ceshi2'
:
-
test.wpython
/
tmp
/
wpython.com:
file
.managed:
-
source: salt:
/
/
test
/
wpython.conf
-
user: root
-
group: root
-
mode:
644
-
backup: minion
|
# secondmaster端写的top.sls文件
?
|
1
2
3
4
5
6
7
8
9
10
11
|
[root@salt
-
minion_6
/
srv
/
salt]
# cat top.sls ceshi2/wpython.sls
base:
'ceshi2'
:
-
ceshi2.wpython
apache:
pkg:
-
name: httpd
-
installed
service:
-
running
|
# 然后我们在master端做以下文件的推送,瞧一下返回的结果
# 返回的结果并不是文件推送而是服务管理
|
1
2
3
4
5
6
7
8
9
|
[root@test
/
srv
/
salt]
# salt \* state.highstate
ceshi2:
-
-
-
-
-
-
-
-
-
-
ID
: apache
Function: pkg.installed
Name: httpd
Result:
True
Comment: Package httpd
is
already installed
|
总结:
以上实验验证了如上所说,master做资源管理state是不能直接指定minion的,但是可以直接管理minion执行某些命令
minionmaster和secondmaster如果有相同的top.sls文件 是不会有任何冲突的，而是master端执行资源管理state
会把任务派发到secondmaster,由secondmaster去匹配自己的top.sls