我正在为我的团队寻找自动部署解决scheme，并且在过去的几天里一直和厨师一起玩。 我已经能够使用chef-solo从基本的Red Hat VM上运行一个简单的Web应用程序。
我们的最终目标是在运行构build时使用Chef（或其他系统）自动将应用程序拓扑部署到云中。 我们的过程基本上是这样运行的：
获得Chef Server运行的好处和/或用例是什么？
有一个厨师服务器举行，从SCM获取食谱与使用厨师独奏，并有一个脚本，将从SCM拉菜谱有任何主要的好处？
我打算把这个答案定位，就好像这个问题是“厨师独奏的优点是什么”，因为这是我知道的覆盖方法之间差异的最好方法。
我的总结build议与其他人一致：如果您需要pipe理dynamic的虚拟化环境，那么您将经常添加和删除节点，请使用主厨服务器。 厨师服务器也是一个很好的CMDB ，如果你需要的话。 使用厨师独奏，如果你有一个不太dynamic的环境，节点不会变化太频繁，但angular色和食谱会。 你的环境的大小和复杂性或多或less是不相关的。 两种方法都非常好。
如果部署chef-solo，可以使用rsync，'git pull'或其他某种idempotent文件传输机制的cronjob来维护每个节点上的主厨存储库的完整副本。 cronjob应该很容易configuration为：（a）完全不运行;（b）运行，但不同步本地存储库。 在你的厨师仓库中添加一个节点/目录，并为每个节点添加一个json文件。 您的cronjob可以像您希望的那样精确地识别正确的节点文件（尽pipe我会推荐$（hostname -s）.json。您也可能想要创build一个opscode帐户并configuration一个托pipe主厨的客户端除了能够使用刀下载社区食谱和创build骷髅，没有其他的原因。
除了明显的“不必pipe理服务器”之外，这种方法还有几个优点。 您的源代码控制将是所有configuration更改的最终仲裁者，存储库将包含所有节点和运行列表，并且每个服务器完全独立，便于一些便利的testing场景。
厨师服务器引入了一个漏洞，你可以使用“刀上传”来更新一个食谱，而且你必须自己修补这个漏洞（比如使用post-commit钩子）或者风险网站的变化被“刀上传”是他笔记本电脑上过时的本地存储库的一个过时的配方。 这与厨师独奏不太可能发生，因为所有更改都将直接从主存储库同步到服务器。 这里的问题是纪律和合作者的数量。 如果你是一个独立开发者或一个非常小的团队，通过API上传食谱并不是很危险。 在一个更大的团队中，如果你没有把好的控制到位，就可能是这样。
此外，通过厨师独奏，您可以将所有节点的angular色，自定义属性和运行列表作为node.json文件存储在主厨师库中。 借助厨师服务器，可以使用API即时修改angular色和运行列表。 通过厨师独奏，您可以在版本控制中追踪这些信息。 这是静态和dynamic环境之间的冲突可以清楚地看到的地方。 如果你的节点列表（不pipe多长时间）不经常改变，那么在修改控制中使用这个数据是非常有用的。 另一方面，如果你经常产生新的节点并且销毁旧的节点（永远不会再看到它们的主机名或者fqdn），那么把它们全部保存在版本控制中是不必要的麻烦，而且有一个API来进行修改是非常方便的。 厨师服务器有一个全面的function，可以pipe理dynamic云环境，比如“knife bootstrap”的名字选项，它可以让你replacefqdn作为识别节点的默认方式。 但是在静态环境中，这些特性的价值是有限的，特别是与其他所有版本控制angular色和运行列表相比。
最后，配方testing环境可以随时设置，几乎不需要额外的工作。 您可以禁用在服务器上运行的cronjob，并直接对其本地存储库进行更改。 您可以通过运行chef-solo来testing更改，您将会看到服务器在生产中如何configuration自己。 一旦testing完成，您可以签入更改并重新启用本地cronjob。 但是在编写食谱时，你将无法使用“search”API，这意味着如果你想写dynamic食谱（例如负载均衡），你将不得不绕过这个限制，从json文件中收集数据您的节点/目录，这可能不太方便，并且缺less完整CMDB中可用的一些数据。 再一次，更多的dynamic环境将有利于数据库驱动的方法，在本地磁盘上使用json文件的dynamic环境会更好。 在主厨运行必须对中央数据库进行API调用的服务器环境中，您将依赖于pipe理该数据库中的所有testing环境。
最后还可以用于紧急情况。 如果您正在解决生产服务器上的一个关键问题，并通过configuration更改来解决问题，则可以立即在服务器存储库上进行更改，然后将其上推到主服务器。
这些是厨师独奏的主要优势。 还有一些其他的，比如不需要pipe理服务器或者为主办的厨师付钱，但是这些都是相对较小的问题。
总结一下：如果你是dynamic的，高度虚拟化的，厨师服务器提供了许多很棒的function（在其他地方），大部分的厨师独奏优势将不太明显。 然而，对于厨师独奏来说，尤其是在更传统的环境中，有一些确定的，往往没有提到的优点。 请注意，部署在云中并不一定意味着您拥有一个dynamic的环境。 例如，如果你不能在你的系统中添加更多的节点而不发布新版本的软件，那么你可能不是dynamic的。 最后，从高层次的angular度来看，CMDB可以用于任何与系统pipe理和configuration（例如团队之间的会计和信息共享）相关的许多事情。 使用厨师服务器可能是单单值得的。
披露：我为Opscode工作。
Chef Server over Solo的主要优点是可以在您的基础设施上使用searchfunction。 典型的例子是带有Web服务器的负载均衡器。 负载平衡器可以自动更新其configuration，因为只需通过searchnetworking服务器就可以添加和移除networking服务器。 Solo就是这样的，单机，而Chef Server则提供了查询“所有内存超过4G的机器”或者“数据库pipe理员”等function。
厨师服务器还使您能够pipe理您的基础设施而无需复制tarball，使用pipe理控制台可视化您的基础架构，并pipe理使用环境运行哪些版本的烹饪书的机器。 还有其他的好处，但那些是我头顶的那些。 如果您想尝试Chef Server而不安装，只需注册一个Opscode Hosted Chef帐户，前5个节点是免费的。
厨师服务器pipe理您的节点的食谱和configuration数据。
使用刀具工具将食谱添加到厨师服务器中，然后为每个节点提供一份食谱的运行列表，以便在节点使用厨师客户端设置自己时获取所需的食谱。 由于厨师客户端在后台运行，您的节点将定期检查厨师服务器中是否有更新的食谱。
厨师服务器也保存你的configuration数据和variables，所以你可以改变你的节点设置自动提取。 这对更dynamic的设置是不错的，这些设置不应该或者不能在你的食谱中硬编码。