第六话 用 highstate 复合主机状态

环境准备：

	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 分布式文件系统部署