我第一次了解Chef/Puppet/etc等工具，想知道它们与部署在云上的应用程序集成得有多好（或有多差）：
- 当有特定于供应商的API，以及像JCloud这样的抽象API的框架时，为什么要使用Chef
- 使用这些配置工具是否会带来性能成本，或者（一旦配置）节点/机器是否像云上的任何其他（非托管）机器一样运行
- Chef可以用来配置现有的任何技术吗？或者它是否提供了"支持的供应商/系统"列表？也就是说，我有一堆Chef配置的PostgreSQL服务器。第二天，一些疯狂的新RDBMS出现了，我想切换到它。我需要等待Chef"支持"这个新系统吗？还是Chef供应商不可知
提前感谢！
披露：我是Puppet实验室雇佣的开发人员之一。
当有特定于供应商的API，以及像JCloud这样的抽象API的框架时，为什么要使用Chef？
原因有两个。一个是Chef、Puppet和类似的工具类似于JCloud——它们提供了对特定云API的抽象。所以，你使用它们也是出于同样的原因。
另一个是，大多数云API实际上是关于创建机器的，Chef、Puppet和类似的工具实际上是关于在机器创建后的配置。云API上的抽象比核心关注更方便。
使用这些配置工具是否会带来性能成本，或者节点/机器是否像云上的任何其他（非托管）机器一样运行？
使用knife创建机器是否会产生性能成本？不，它和其他任何非托管节点一样。如果你创建了一台没有安装Chef的机器，它就像没有安装Chev的机器一样。木偶方面也是如此。
（请记住，Chef、Puppet和类似的工具没有任何公共云API中不存在的API。我们在那里没有情人交易。；）
Chef可以用来配置现有的任何技术吗？或者它是否提供了"支持的供应商/系统"列表？也就是说，我有一堆Chef配置的PostgreSQL服务器。第二天，一些疯狂的新RDBMS出现了，我想切换到它。我需要等待Chef"支持"这个新系统吗？还是Chef供应商不可知？
Chef和Puppet都具有可扩展性。两者都有一套可以开箱即用的东西，还有一个为一大堆其他东西提供支持的社区。
因此，如果有一项新奇的新服务出现，你可能会拥有一些但不是全部的功能。（例如，两者都可以管理包、文件、服务，并开箱即用地运行任意命令。这将满足随机新服务的许多需求，即使没有更详细的管理模型。）
如果你想要更多的管理，例如，数据库内部的访问控制是模型的第一类部分，你可能需要等待某人在你的产品中为它编写支持。（很明显，有人可以是你。）
因此，你可以开箱即用地获得基本的支持，而且在它们的基础上构建更多的支持是非常容易的。
尽管这些产品在Unix上比其他平台更有效，而且对Windows的支持更有限，但仍然很有价值，但它们都不是任何意义上的"特定于供应商"的产品。
这里几乎所有的东西都适用于该领域的其他产品。