http://doc36.controltier.org/wiki/Main_Page
http://doc36.controltier.org/wiki/Main_Page
现在，服务器集群已经是司空见惯的事情了。随便一个小的互联网应用程序都需要用集群来支撑。而当采纳“持续集成”，尤其是“持续交付”实践时，在各种环境上的部署让你发疯。这些环境包括开发环境、测试环境（包括功能测试和非功能测试）、试运行环境和生产环境。而且，每种环境可能会有多套实例，而不只是一套实例。
曾经接触过的一个团队，其持续集成环境中就有260+台服务器，随着开发人员的提交，不同版本的应用程序在这些服务器上一遍又一遍地被部署、测试、卸载。而且，这些服务器的作用各不相同，有的是web服务器，有的是应用服务器，还有数据库服务器，也许还有消息服务器等等。想象一下，如果由你来管理这样一个团队中的服务器集群的部署，你的状态会是什么样子？
其实，当面对这么庞大的集群时，关键问题不仅在于知道每一步怎么做，而是：如何能够在所有的服务器上能够让所有的步骤都能够正确地被执行，而且要按照你期望的顺序，不至于各节点的执行步骤间互相受到影响。
其实，已经有很多工具解决这类问题了，ControlTier就是其中之一。它是一个跨平台软件系统，用于在多个服务节点中管理应用程序的相关操作。
它既有命令行工具，又有Web管理界面。用户可以自定义命令组，并重用它们。它与Puppet的一个区别在于：ControlTier是基于“对目标进行操作（Activity）”的工具，而Puppet则是基于“定义目标状态”的工具。所以，Puppet的“部署幂等性”在ControlTier里是很难办到的。它们在这一点上的区别也决定了它们使用层次上的不同。在《持续交付》的“环境管理”章节中，说环境配置管理的层次如下图所示：
而它们所服务的位置如下：
当然，你完全可以在系统层使用ControlTier，也完全可以在应用层使用Puppet，但是它们有各自的专长，在其它层次上使用意味着需要的定制工作量稍多一些而已。
你还等什么，赶快使用这些工具，去打造你的完美“持续交付”环境吧！
