我第一次学习像Chef / Puppet / etc这样的工具，并且想知道他们与部署在云上的应用程序集成得如何（或很差）：
提前致谢！
答案 0 :(得分：3)
披露：我是Puppet Labs聘用的开发人员之一。
为什么在有特定于供应商的API时使用Chef，以及像JCloud这样的框架甚至抽象那些API？
有两个原因。一个是Chef，Puppet和类似工具就像JCloud--它们提供了对特定云API的抽象。所以，你出于同样的原因使用它们。
另一个是大多数云API都是关于创建机器的，而Chef，Puppet和类似的工具实际上是关于创建机器之后的配置。对云API的抽象比核心焦点更方便。
使用这些配置工具是否会产生性能成本，或者节点/机器是否像云上的任何其他（非托管）计算机一样运行？
使用knife创建计算机是否会产生性能成本？不，它就像任何其他非托管节点一样。如果您创建没有安装Chef的计算机，它就像没有安装Chef的计算机。在Puppet方面也是如此。
（请记住，Chef，Puppet和类似工具没有公共云API中没有的任何API。没有甜心在那里为我们处理。;）
可以使用Chef来配置那里的任何技术，还是提供“支持的供应商/系统”列表？意思是，我只想说我有一堆Chef配置的PostgreSQL服务器。然后第二天，一些疯狂的新RDBMS出来了，我想切换到它。我是否需要等待厨师“支持”这个新系统，或者是厨师与供应商无关？
Chef和Puppet都有可扩展性。两者都有一套他们可以开箱即用的东西，以及一个为其他东西提供支持的社区。
因此，如果出现了一个花哨的新服务，那么您可能拥有一些但不是全部的功能。 （例如，管理软件包，文件，服务以及开箱即用的任意命令。即使没有更详细的管理模型，也可以完成随机新服务所需的大量工作。）
如果您想要更多 - 管理，例如，数据库内的访问控制是模型的第一类部分，您可能必须等待某人在您的产品中为其编写支持。 （显然，有人可以成为你。:)
因此，您可以获得开箱即用的基本支持，并且可以轻松地在它们之上构建更多支持。
这些产品在任何有意义的意义上都不是“特定于供应商”，尽管它们在Unix上比其他平台更有效，并且对Windows有更多有限但仍然有价值的支持。
此处几乎所有内容都适用于空间中的其他产品。