我们是Puppet及相关系统如Chef系统的大粉丝,我们也推荐客户使用这些系统,因为这些系统对于现今的运维开发DevOps非常有用,这些则是大型系统所需的功能强大的自动化工具。

然 而,我们公司内部不使用Puppet开展客户支持工作,虽然该工具很有用,也很强大,而且之于很多我们经常性用到的东西来说很理想,如自动安装,升级等, 我们之所以不使用该工具,是因为当有很多客户或很多用户一并使用该系统时,该工具显得不够安全。至今为止,还不能完全保证使用该工具是绝对安全的,而且, 在使用后期还可能带来严重问题,若您想对此问题有更多的了解,您需要知道Puppet到底是什么?它是如何工作的?

Puppet 是一款描述性的终端状态系统,而并非像很多人所想象的真的是一个安装工具。它会把系统改变成经描述的终端状态,做一些必须的事情,如解决依赖性等。所以, 并不像人们所习惯的那种程式化的系统,它是描述状态的一个机器。这对终端服务器的影响会有很大区别。从本质上来说,服务器上始终会运行一个守护进程,会定 时行进入中心系统进行检测,发现异常时,会更改配置状态,如删除MySQL、删除数据、更改防火墙等等。

Puppet是采用自己的语言进行 配置的,通常存放在模板中,继承了一些属性,所以,功能强大,你可以把你的所有Apache服务器采用相同的配置。但是,即使所有的服务器采用相同配置, 要破坏该系统还是轻而易举的。然而,如果使用许多系统,服务多种类型的客户的话,系统间就会有差异,很难采用相同的模板。即使对系统作很小的变更,都会在 数年后在生产系统中反应出来,对系统造成破坏。这就是为什么使用Puppet远远达不到安全要求的原因。

虽然可以采用多种方案使系统变得安 全,比如说,不在服务上运行Puppet守护进程,但这其实也是不安全的,因为,后来某个人使用系统时,可能会更改此设置,导致系统严重受损。 我们还可以采用100%完全分离式系统,但是,这样的系统仍然很容易遭受破坏,容易被覆盖,或者至少会把生产系统搞得一团糟。

我们正寻求如何能做到100%完全分离式系统安装,这样的话,系统构建就会很简单,容易理解,更安全也更有效,只有在这种情况下,我们才可能在我们的核心架构中使用Puppet。