0

我第一次学习像 Chef/Puppet/etc 这样的工具，想知道它们与部署在云上的应用程序集成的好坏（或差）：

  • 当有特定于供应商的 API 以及像 JCloud 这样抽象出这些 API 的框架时，为什么还要使用 Chef？
  • 使用这些配置工具是否有性能成本，或者（一旦配置）节点/机器是否像云上的任何其他（非托管）机器一样运行？
  • Chef 可以用来配置任何现有的技术，还是提供“支持的供应商/系统”列表？意思是，假设我有一堆由 Chef 配置的 PostgreSQL 服务器。然后第二天，一些疯狂的新 RDBMS 出现了，我想切换到它。我需要等待 Chef “支持”这个新系统，还是 Chef 供应商不可知？

提前致谢！

4

1 回答 1

3

披露：我是 Puppet Labs 雇用的开发人员之一。

当有特定于供应商的 API 以及像 JCloud 这样抽象出这些 API 的框架时，为什么还要使用 Chef？

有两个原因。其中之一是 Chef、Puppet 和类似工具类似于 JCloud——它们提供了对特定云 API 的抽象。因此，您出于同样的原因使用它们。

另一个是大多数云API实际上是关于创建机器的，而Chef、Puppet和类似的工具实际上是关于创建机器后的配置。云 API 的抽象比核心焦点更方便。

使用这些配置工具是否有性能成本，或者节点/机器是否像云上的任何其他（非托管）机器一样运行？

knife用于创建机器是否有性能成本？不，它就像任何其他非托管节点一样。如果您创建一台未安装 Chef 的机器，它就像一台未安装 Chef 的机器。在 Puppet 方面也是如此，等等。

（请记住，Chef、Puppet 和类似工具没有公共云 API 中不存在的任何 API。那里没有对我们有利的交易。;）

Chef 可以用来配置任何现有的技术，还是提供“支持的供应商/系统”列表？意思是，假设我有一堆由 Chef 配置的 PostgreSQL 服务器。然后第二天，一些疯狂的新 RDBMS 出现了，我想切换到它。我需要等待 Chef “支持”这个新系统，还是 Chef 供应商不可知？

Chef 和 Puppet 都以可扩展性为核心。两者都有一套他们可以开箱即用的东西，以及一个为一大堆其他东西提供支持的社区。

因此，如果出现了一项精美的新服务，您可能会拥有一些（但不是全部）您可以管理的功能。（例如，两者都可以管理包、文件、服务，并开箱即用地运行任意命令。即使没有更详细的管理模型，这也能满足随机新服务的需求。）

如果您想要更多 - 例如管理数据库内部的访问控制是模型的第一类部分，您可能必须等待有人在您的产品中编写对它的支持。（很明显，有人可以是你。:)

因此，您可以获得开箱即用的基本支持，并且很容易在它们之上构建更多支持。

在任何有意义的意义上，这些产品都不是“特定于供应商的”，尽管它们在 Unix 上都比其他平台更有效，并且对 Windows 的支持更有限但仍然很有价值。

这里的几乎所有内容也适用于该领域的其他产品。

于 2012-02-04T22:09:52.510 回答