持续集成之“自动化部署”(2)

　　对环境管理进行版本控制，杜绝对生产环境的手工直接修改

　　“听上去，对于配置文件、脚本等进行版本管理的确是解决了运维部署的很多问题。但如何对环境管理进行版本控制呢?”Tom问道。

　　Joe想了想，说道：“环境管理比较复杂。一般来说，环境包括几个层次，包括硬件及网络配置、操作系统、我们的应用程序所依赖的软件堆栈及其配置、以及我们的应用程序运行时所需的数据及其配置。目前对我们来说，对于硬件及网络配置、操作系统这两层来说，有两种方式进行管理。一种是利用一些专用软件进行自动化的远程配置，即只要给机器加电，就可以通过一些技术对一台机器进行系统的安装与配置。另一种是使用虚拟化技术来进行系统配置管理。对我们现在的游戏平台来说， 使用后者即可。只要将基本的环境做成虚拟机镜像文件，并将其作为环境基线进行版本管理。当然，由于镜像通常较大，所以最好不要使用常见的版本控制工具(如subversion，Git等)进行，而使用某种简单的机制即可。”

　　Joe停了一下，看看大家没有提问的意思，于是接着说道：“至于基于其上的软件堆栈及堆栈中各软件的配置管理完全可以利用类似于CfEngine，Puppet或Chef的工具进行。这些软件环境管理工具都提供某种领域专属语言来描述软件堆栈配置，并保存在文本文件中。这些工具一般通过服务器/客户端的工作方式运行，客户端向服务器发送请求，验证本机器节点的软件配置是否与服务器中的设置相符，如果不符，就会自动更新。尤其重要的是，这些更新操作都是幂等的，即无论这些配置在该客户机上执行多少遍，每次的结果状态都是相同的。另外，它们通常能与版本控制工具集成。所以，只要将我们的软件堆栈配置管理信息放到版本控制库中，就可以同时管理数台机器。”

　　“oh, 对不起，Joe，我想打断一下，”Tom问道：“你能画一个图来解释一下你刚才所说的这种软件环境配置管理工具吗?”

　　“当然没问题。”Joe拿起笔在白板上画了一个Puppet的工作示意图，如下图所示。

　　“看上去清楚多啦。”Tom笑道，“通过这种方式，我们就只需要将版本控制库中保存的配置信息签出到本地，进行相应的修改，再提交到版本控制库中，这种工具就会自动帮我们完成必要的配置更新了。是这样的吗?”

　　“对，”Joe点了点头，说道，“如果我们的部署脚本也是通过这种方式来做的，那么我们就根本没有必要登录到生产环境的机器上，进行手工操作了。而且，Puppet还提供一种Try Run功能，可以进行配置变更的模拟，让你能够对比一下变更前后的不同之处。”

　　Tom说道：“你说的这些听上去都不错。但并不是所有人都能够修改生产环境的配置信息的。所以我们还是需要一个软件平台来管理上线的申请审批流程。”

　　“在任何企业中，这种申请审批流程和生产环境变更的授权都是必要的，但这仅仅是审核流程的操作。而真正与软件部署相同的具体操作都不应该在这种审批流程当中。”Joe回答道。

　　Tom接过话来，说道：“嗯，这样的话，我们仍旧能够做到：有权限的人才能真正修改生产环境的配置文件，同时达到了无人真正直接操作生产环境的目的，避免了手工误操作带来的问题。”

　　参加本次会议的测试人员和运维人员对这种做法产生了浓厚的兴趣，并要求开发人员给予配合，将目前游戏平台的部署自动化。Tom说道：“这就是我们运维工作的一个方向。让枯燥易出错的重复性手工操作变成受控的自动化，从而解放运维人员，让我们可以关注于更加有价值的运行监控等工作中。”

　　Alice说道：“这看上去还是有一定的工作量啊。”

　　“当然，我们可能需要做一些工作，但我想这些投入是值得的。”Joe回答道。“同时，还需要各种角色之间更紧密的配合，而不是像之前那样，通过一个代表上个世纪八十年代先进技术的办公自动化平台来描述部署上线步骤这类关键的业务操作信息。”

　　Tom也点了点头，说：“嗯，应该使用版本控制方式。但我们还是需要一个上线审批的流程，只不过，这个流程中不再保存上线步骤这类与实际部署相关的业务信息，而只是为了部署人员的资格审核与信息周知的目标。”

　　经过一番讨论，开发、测试和运维团队在这件事情上达成了一致，并按计划开始实施了。

　　需要注意的是，他们似乎没有谈到数据管理。他们会遇到相关的问题吗?

原文转自：http://www.ltesting.net