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