一个通用应用运维管控平台的设计实现

编写完成后解析成格式化的数据，比如下面表格：

key value region.id 7001 region.name js region.mongodb.hosts [‘172.27.117.201’，’172.27.117.202’，’172.27.117.203’] region.mongodb.port 27017

用户可以选择两种可视化方式，但使用的时候需要按照解析后格式化的方式来使用，比如用户在模板中需要使用某个region的mongodb的服务器列表，则需要这种方式来使用：region.mongodb.hosts ， 如果需要进一步处理该数据，可以在模板文件中直接使用Python语法处理，这个在模板管理中再介绍。

之所以需要有变量管理，就是因为模板管理的存在，很多配置需要按照不同的环境生成，而这些环境就需要有变量管理这个功能来控制。

变量管理细分可以分为几个维度：

■全局变量

全局变量指的是那些在任何场景下都只有一个的变量，可能会改变，但全局只有这一个变量，它一变会影响到所有的使用它的模板。

■组变量

组变量是指和分组管理结合后对某个分组设置的变量，组变量的使用场合比较多，而且不同的分组之间可能还有优先级的问题，因此需要在分组的时候设置组的优先级。

建议将组的优先级分为如下几类：

■全局组(级别最低)

■IDC组(级别次之)

■Set组(级别次之)

■自定义组(级别次之)

■主机变量

主机变量是主机级别的动态变量，具有较高的优先级，建议结合资源管理系统使用，可以给每一台物理主机(虚拟主机)都设置一组相应的动态变量，比如某个set的某些mongodb集群，需要区分主、从，设置的变量可以这个样子：

172.27.117.252 id=0 priority=2 arbiterOnly=False 172.27.117.248 id=1 priority=1 arbiterOnly=False 172.27.117.247 id=2 priority=0 arbiterOnly=True

在服务部署的时候可以根据相应的优先级决定生成的配置文件的不同，甚至执行脚本的不同。

■任务变量

任务变量是具有最高优先级的变量，这个变量只有任务执行的时候，通过输入的参数来控制，该变量实际并不进行管理，使用用户在使用的时候输入而已，一次性的操作。

6) 模板管理

模板管理就是管理各种配置文件的管理系统。

配置文件之所以需要管理，是因为两个原因：

1、在不同的环境中配置文件的内容可能是不同的

2、配置文件中的某些内容可能是会被修改的

我们以下面的配置文件为例，分别说说这两种情况下使用模板管理的必要性：

[common]region = {{ region.id ｝｝set = 1instance = 1...[network]listen-ip = {{ inventory_hostname ｝｝file_ulimit = {{ global.file_ulimit ｝｝

上面配置文件中的 {{ region.id ｝｝以及{{ inventory_hostname ｝｝说的就是第一种情况， 而{{ global.file_path ｝｝就是第二种情况。

第一种情况中，在不同的region之间，文件的格式不变，但region.id的值是有变化的;inventory_hostname这里表示的是某个服务器的ip地址，这个在服务器级别都是变化的。因此这类文件需要是需要进行模板管理的。

第二种情况中，所有的file_ulimit都是一样的，那我们为什么不写死在文件里而把它变成变量呢?是因为这个配置，虽然现在没有变化，但将来可能会发生变化，在变量管理中直接修改一下，那新的配置文件就都会按照这个生成了，比起去改一个文件内容还有可能产生格式错误的风险来说，这种方式是不是简单多了。

至于模板文件如何编写，这里将会使用python的最通用的模板引擎jinja2引擎，所有的语法都必须遵循jinja2的引擎即可，变量使用变量管理中定义的变量，对于每一台主机都是在使用的时候动态生成最新的临时文件，并通过文件分发的方式传输就可以了。

7) 软件管理

所谓的软件管理，也就是软件包的管理，软件包的管理有两种：

1、rpm或yum，npm，pip等安装的软件包，具有明确的包管理工具。

2、压缩包或目录格式的代码版本。

具有软件包管理工具的代码，比较容易进行管理，只要通过每台服务器自动的Agent定期执行list操作将所需要跟踪的软件包的版本进行跟踪，并汇报到中心管理数据库即可。

而压缩包或目录格式的代码版本则比较麻烦，需要对比MD5值，以及具有参照样本才可以管理。

这些所有的软件包都需要有一个最新可用的全局版本管理，用于进行版本对比操作，甚至可以直接点击升级。

总之，最终的软件管理的结果会呈现如下的形态，以某台服务器为例：

服务器ip： xxx.xxx.xxx.xxx| 软件包名称| 版本号 | 是否是最新可用版本| 点击升级| ：—-|：—-|| nodejs| v0.1.1| 是|| libvirt| x.x.x| 是|| zookeeper| 3.3.5| 否| 升级

当然有了软件管理之后，当我们有某种类似如： 将某些服务器上面的某个软件包升级! 这样的问题的时候，无论是获取基准ip列表，还是后续的升级工作，都十分简单了。

当然版本升级工作会和作业管理相结合，每个版本升级都会是一个单独的作业，这样版本升级的进度，结果也都一目了然，而且还可以做到灰度。

8)服务管理

服务管理有点类似监控工具，它所层显的状态和版本管理类似，实现的方式也类似，都是通过Agent定时上报的机制获取最新的数据。

所谓的服务管理，就是讲每一台服务器上所运行这些进程进行管理，当然不是全部进程，而是我们所关注的服务进程，呈现的状态如：

以服务器：xxx.xx.xxx.xxx为例：| 进程id| 进程名称| 启动时间| 检查时间|运行时间 | 运行用户| 运行状态| 操作|：—-：| 1234| uhost-action| 2016-2-07 10：00：00| 2016-2-17 10：00：00 | 10day | root|运行中 | 重启/停止| 2345| uimage3-action| 2016-2-07 10：00：00 |2016-2-17 10：00：00| 8day | root|已停止 | 启动

上面是某台服务器上的服务管理的实时情况，每一个任务都可以有详细的跟踪记录，可以用于问题跟踪，服务报警，dashborad展现等等。

另外服务管理可以和作业管理相结合，实现服务的重启，停止，启动等功能。