saltstack批量部署并配置nginx

最近应别的部门要求研究了一下saltstack，感觉很好用哈！虽然我现在生产环境用的puppet，想以后逐渐用这个去替代puppet，至于ansible还没研究，以后有时间再看看吧！

一、Saltstack是什么?

saltstack是一种全新的基础设施管理方式，部署轻松，在几分钟内可运行起来，扩展性好，很容易管理上万台服务器，速度够快，服务器之间秒级通讯。

saltstack底层采用动态的连接总线。使其可以用于编配，远程执行，配置管理等等。

二、实验目的：

根据不同的业务需求来分组部署和配置nginx服务器。三台服务器均采用CentOS6.5系统版本且最小化安装，要求能上互联网。Selinux和防火墙均已关闭。生产环境务必开启。

注意点：三台服务器一定要设置完整的fqdn，和域名一样的形式，不然下面你在主控端执行远程执行或者配置的时候等待的时间巨慢甚至还会出线其它不可控的问题。这个是血的教训。

三、实验环境信息：

角色	主机名	IP地址	组名	cpu个数	Nginx根目录
master	master.saltstack.com	192.168.2.20	—	—
minion	web01.saltstack.com	192.168.2.21	web01group	1	/data
minion	web02.saltstack.com	192.168.2.22	web02group	2	/www

四、实验步骤：

1、首先三台服务器上都需要安装epel源。因为后面需要安装saltstack服务端和客户端，也包括后面的nginx。

rpm -ivh 

截图如下：

 

两台minion安装epel源就不再截图。

2、主控端（也就是master）上安装saltstack软件。

yum install salt-master -y

被控端（也就是两台minion）上安装saltstack软件。

yum install salt-minion -y

安装过程不截图

3、配置主控端配置文件/etc/salt/master（注意默认的master文件全部是注释的）

修改15行的监听地址，注意为了安全，监听的地址一定要写内网地址。

 

修改为如下所示

 

修改215行的主控端会自动认证被控端的认证，只要被控端设置完主控端的IP地址后启动服务，主控端就会允许被控端自动认证。避免以后每次运行salt-key来确认证书信任。

 

修改为如下所示：

 

修改416行saltstack文件根目录位置，注意这个目录默认没有，需要创建。

修改为如下所示：

修改706行的组分类

注意上图L@表示后面的主机名格式为列表，即主机名以逗号分隔，G@表示以grain格式描述。我这里因为每个组只有一台服务器，所以配置更简单。

在下面空行处添加如下所示：

修改552行的pillar开启功能

 修改为如下图所示：

 

修改529行的pillar的主目录，注意这个目录默认没有，需要创建。

 

修改为如下图所示：

 

主控端主要修改了以下内容：

主控端做完上述操作后启动salt-master服务。

启动完后监听TCP4505、TCP4506端口。生产环境如果启用防火墙建议主控端开放这两个端口。

创建salt文件根目录及pillar目录

4、配置两台被控端配置文件/etc/salt/minion（注意默认的master文件全部也是注释的）

修改16行的连接主控端的IP地址

修改为如下图所示：

修改72行的被控端id，配置被控端的主机名

修改为如下图所示：

注意另外一台修改为

 

分别启动两台被控端服务

 

在主控端上简单测试一下主控端和被控端通信状态，如果返回都是True说明正常。注意这里的ping和我们平时用的ping命令不同。它只是test类下面的一个方法而已。是验证主控端和被控端的通信状态。注意*表示所有通过认证的被控端。还可以支持其它很多正则表达式的匹配。

如果不是True的那么请自行排查错误。

下面我们主要利用saltstack的几个组件完成nginx的安装和配置工作。主要用到grains、pillar、state三个重要的组件完成。grains和pillar都是采集被控端数据的。但是grains的特性在每次启动汇报，没有pillar灵活，要知道pillar是随时可变的，只要在master端修改了那一般都会立刻生效的。所以grains更适合做一些静态的属性值的采集，例如设备的角色、磁盘个数等诸如非常固定的属性。那么我们就可以得到一个大致的判断，如果你想定义的属性值是经常变化的，那请采用pillar，如果很固定、不易变得那请用grains。

在配置之前首先我们拆分一下nginx的主配置文件，里面要根据当前CPU个数设置一些值、设置一些打开文件句柄数等等。

上述说到grains可以采集被控端主机的一些值，一般定义grains数据的方法有两种，其中一种为在被控主机定制配置文件，另外一种是通过主控端扩展模块API实现，区别是模块更灵活。下面我们用自定义的方式进行。

通过下面的命令可以查看被控机web01主机的grains所有值。但是很遗憾默认打开的文件句柄数1024在被控端没有，需要我们自定通过python脚本获取。下图没截全。全部内容大家可以自行参考自己的实验环境。

state组件是saltstack核心功能，通过预先定制好的文件对被控机进行状态管理，支持包含程序包（pkg）、文件（file）、网络配置（network）、系统服务（service）、系统用户（user）等。也就是定义好相关动作让被控机去执行。

5、首先创建grains目录，需要将目录下的定制文件同步到被控机上运行，然后能正常获取被控机打开文件句柄数。

 

上述脚本的含义就是让被控机获取它当前打开文件句柄数。

在同步到被控端之前我们先执行一下如下命令，确认在主控端是否能获取被控端的max_open_file值？

从上图中我们看到不能获取到max_open_file的值，那么需要同步grains模块，在主控端运行如下命令：

被控端文件存放在/var/cache/salt目录下

我们再次来获取一下max_open_file的值试试看，一会我们可以用grains获取到这个值配置nginx主配置文件的每个线程打开的连接数。

6、配置pilllar

在主控端上创建top.sls，内容如下：

再分别定义不同业务nginx的根目录，也通过pillar配置。

7、配置state

首先定义state的入口top.sls文件，注意和pillar的入口文件名字一样，别弄错了。内容如下：

其次定义被控机执行的状态，安装nginx软件、配置、启动。

使用jinja模板定义nginx配置文件nginx.conf，首先创建一个nginx目录，因为上面定义了nginx配置文件的源路径。

nginx.conf配置文件大家可以根据自己的需求进行编写。

现在我们就可以在主控端执行刷新state配置，让两台被控端去执行安装nginx并配置。

通过上图我们看到了三个ID，相当于三个任务，第一个安装，第二个配置，第三个启动。而且显示三个都成功了。失败的零个。如果不放心也可以去被控端看看nginx是否启动？

我们再看看web01.saltstack.com节点的nginx主配置文件nginx.conf

 

中间截图省去一些部分......

我们再看看web02.saltstack.com节点的nginx主配置文件nginx.conf

中间截图省去一些部分......

这样基本就完成了通过saltstack批量部署nginx并配置。更多功能也可以利用这个思路扩展到其它功能平台。