环境准备:
master 服务端 | minion 客户端01 | minion 客户端02 | |
---|---|---|---|
IP | 10.20.2.94 | 10.20.0.30 | 10.20.5.71 |
查看系统版本 # cat /etc/redhat-release | CentOS release 6.5 (Final) | CentOS release 6.5 (Final) | CentOS release 6.5 (Final) |
查看系统内核版本 # uname -r | 2.6.32-431.el6.x86_64 | 2.6.32-888.el6.x86_64 | 2.6.32-431.el6.x86_64 |
查看selinux的状态(未关闭则先关闭) # getenforce | Disabled | Disabled | Disabled |
一、highstate 组织多个状态配置
实际生产环境会存在大量的主机角色,如果每种主机角色都维护一个状态文件会使维护变得混乱不堪,我们需要通过拆分和复用让状态文件更加模块化,同时需要能整体性组织和管理这些模块。
怎样才能达到这一目的?Salt 提供了 highstate 模块可以轻松完成这个任务。
二、用 top.sls 文件管理状态文件
在第四话中,曾使用了 top.sls 文件将 Pillar 文件定位到不同的 minion。top.sls 也可以用来在状态系统中将不同的状态文件定位到不同的 minion 中。highstat 函数正式通过 top.sls 文件作为入口对模块和主机进行管理的,下面首先学习用 highstate 函数配合 top.sls文件来管理状态文件。
三、状态文件的拆分和复用
四、多环境的配置和管理
通过 top.sls 配置文件和模块的拆分可以对多种状态和多组 minion 进行同时管理,只需要执行一条 # salt '*' state.highstate 就能完成 base 环境内所有 minion 的管理。
top.sls 都会包含一个 base:配置项,这个其实是 Salt 配置文件中默认的环境目录,可以查看 /etc/salt/master 中对应的部分。
## vim /etc/salt/master
# Example:
# file_roots:
# base:
# - /srv/salt/
# dev:
# - /srv/salt/dev/services
# - /srv/salt/dev/states
# prod:
# - /srv/salt/prod/services
# - /srv/salt/prod/states
#
#file_roots:
# base:
# - /srv/salt
file_roots 这个配置项指明了我们的环境目录所在,Salt 执行对应的 SLS 状态文件都会从默认的目录去寻找。
Salt 的环境配置可以带来巨大的便利,一般都会有开发环境、测试环境和生产环境。这些环境如果都放在默认的 base 内进行管理会比较混乱,为了区分和便于管理,可以对不同的环境配置不同的目录,我们修改 /etc/salt/master:
## vim /etc/salt/master
state_top: top.sls #定义 top 入口文件,告诉 state 用来映射什么 sls 模块,然后安装到相应的软件或部署相应的文件到 minions上面。
file_roots: #相当于是项目的目录路径,之后批量管理客户的时候的配置文件就定义在这些目录里面
base:
- /etc/salt/states
dev:
- /etc/salt/states/dev
prod:
- /etc/salt/states/prod
重启 salt-master:
# /etc/init.d/salt-master restart
或
# service salt-master restart
创建项目目录和文件:
# mkdir -p /etc/salt/states/prod
# mkdir -p /etc/salt/states/dev
# mkdir -p /etc/salt/states/init
建立多个环境目录后可以通过维护过个 top.sls 配置文件来管理各自的环境,也可以通过维护一个 top.sls 来进行管理,它们的原理都是一样的。多个环境的 top.sls 在最终执行 salt '*' state.highstate 命令时也会合成为一个文件。
五、实战案例:keepalived + Redis 高可用架构
六、实战案例:MooseFS 分布式文件系统部署