技术选择 – 我们为什么不选择Puppet？
我们是Puppet及相关系统如Chef系统的大粉丝，我们也推荐客户使用这些系统，因为这些系统对于现今的运维开发DevOps非常有用，这些则是大型系统所需的功能强大的自动化工具。然而，我们公司内部不使用Puppet开展客户支持工作，虽然该工具很有用，也很强大，而且之于很多我们经常性用到的东西来说很理想，如自动安装，升级等，我们之所以不使用该工具，是因为当有很多客户或很多用户一并使用该系统时，该工具显得不够安全。至今为止，还不能完全保证使用该工具是绝对安全的，而且，在使用后期还可能带来严重问题，若您想对此问题有更多的了解，您需要知道Puppet到底是什么？它是如何工作的？
Puppet是一款描述性的终端状态系统，而并非像很多人所想象的真的是一个安装工具。它会把系统改变成经描述的终端状态，做一些必须的事情，如解决依赖性等。所以，并不像人们所习惯的那种程式系统，它是描述状态的一个机器。这对终端服务器的影响会有很大区别。从本质上来说，就像一个守护进程，会进入中心系统进行检测，发现异常时，会更改配置状态，如删除MySQL、删除数据、更改防火墙等等。
Puppet是采用自己的语言进行配置的，通常存放在模板中，继承了一些属性，所以，功能强大，你可以把你的所有Apache服务器采用相同的配置。但是，即使所有的服务器采用相同配置，要破坏该系统还是轻而易举的。然而，如果使用许多系统，服务多种类型的客户的话，系统间就会有差异，很难采用相同的模板。即使对系统作很小的变更，都会在数年后在生产系统中反应出来，对系统造成破坏。这就是为什么使用Puppet远远达不到安全要求的原因。
虽然可以采用多种方案使系统变得安全，比如说，不在服务上运行Puppet守护进程，但这其实也是不安全的，因为，后来某个人使用系统时，可能会更改此设置，导致系统严重受损。 我们还可以采用100%完全分离式系统，但是，这样的系统仍然很容易遭受破坏，容易被覆盖，或者至少会把生产系统搞得一团糟。
我们正寻求如何能做到100%完全分离式系统安装，这样的话，系统构建就会很简单，容易理解，更安全也更有效，只有在这种情况下，我们才可能在我们的核心架构中使用Puppet。
（Authored by Steve Mushero / ChinaNetCloud CEO & CTO本博客英文原文请点此查看）
页:
[1]