我正在为我的团队寻找自动部署解决方案，并且过去几天一直在与Chef合作。我已经能够使用Chef-solo从基本的Red Hat VM上运行一个简单的Web应用程序。
我们的最终目标是在运行构建时使用Chef（或其他系统）将应用程序拓扑自动部署到云中。我们的过程基本上是这样运行的：
运行Chef Server有哪些好处和/或用例？
与使用chef-solo和拥有可从SCM提取菜谱的脚本相比，拥有Chef Server并从SCM获取菜谱有什么主要好处？
Answers:
我将把答案定位为问题是“ chef-solo的优点是什么”，因为这是我了解覆盖这两种方法之间差异的最好方法。
我的总结建议与其他建议保持一致：如果需要管理动态的虚拟化环境（经常在其中添加和删除节点），请使用主服务器。如果需要，chef服务器也是一个很好的CMDB。如果您在动态性较差的环境中节点不会经常更改，而角色和配方会经常更改，请使用chef-solo。环境的大小和复杂程度或多或少无关紧要。两种方法都可以很好地扩展。
如果部署chef-solo，请使用带有rsync，'git pull'或其他幂等文件传输机制的cronjob来在每个节点上维护chef存储库的完整副本。cronjob应该易于配置为（a）完全不运行，（b）运行，但不同步本地存储库。在厨师存储库中添加一个节点/目录，并为每个节点添加一个json文件。在确定正确的nodefile方面，您的cronjob可以像您希望的那样复杂（尽管我仅建议$（hostname -s）.json。您也可能想创建一个opscode帐户并为托管厨师配置客户端，如果要除了能够使用小刀下载社区食谱和创建骨架外，没有其他原因。
除了显而易见的“不必管理服务器”之外，此方法还有许多优点。您的源代码控制将是所有配置更改的最终仲裁者，存储库将包括所有节点和运行列表，并且每个服务器都是完全独立的，这有助于进行一些方便的测试方案。
Chef-server引入了一个漏洞，您可以在其中使用“刀上传”来更新菜谱，并且您必须自己修补此漏洞（例如，使用提交后的钩子），否则可能会被“刀上传”的人默默覆盖站点更改s从他的笔记本电脑上过时的本地存储库中删除了一个过时的食谱。Chef-solo不太可能发生这种情况，因为所有更改都将直接从主存储库同步到服务器。这里的问题是纪律和合作者的数量。如果您是一个单独的开发人员或非常小的团队，则通过API上传食谱不会带来很大的风险。在较大的团队中，可能是如果您没有良好的控制措施。
此外，通过chef-solo，您可以将所有节点的角色，自定义属性和运行列表存储为主chef存储库中的node.json文件。使用Chef-server，可以使用API即时修改角色和运行列表。使用chef-solo，您可以在修订控制中跟踪此信息。在这里可以清楚地看到静态和动态环境之间的冲突。如果您的节点列表（无论长度有多长）不会经常更改，那么在修订控制中包含此数据将非常有用。另一方面，如果您经常产生新节点并销毁旧节点（再也看不到它们的主机名或fqdn），则将它们全部保留在版本控制中只是不必要的麻烦，拥有API进行更改非常方便。Chef-server还具有适用于管理动态云环境的全部功能，例如“ knife bootstrap”上的name选项，该选项使您可以替换fqdn作为识别节点的默认方式。但是在静态环境中，这些功能的价值是有限的，特别是与在版本控制中将角色和运行列表与其他所有功能相比而言。
最后，几乎不需要额外的工作即可快速设置配方测试环境。您可以禁用服务器上运行的cronjobs并直接对其本地存储库进行更改。您可以通过运行chef-solo来测试更改，然后您将确切了解服务器在生产中如何进行自我配置。测试完所有内容后，您可以签入更改并重新启用本地cronjob。但是，在编写配方时，您将无法使用“搜索” API，这意味着，如果您要编写动态配方（例如负载平衡器），则必须克服这一限制，从json文件中收集数据。您的节点/目录，这可能不太方便，并且将缺少完整CMDB中的某些可用数据。再者，更多的动态环境将支持数据库驱动的方法，本地磁盘上的json文件适合动态性较低的环境。在厨师运行必须对中央数据库进行API调用的服务器环境中，您将依赖于管理该数据库中的所有测试环境。
最后一个也可用于紧急情况。如果要解决生产服务器上的关键问题并通过配置更改解决它，则可以立即在服务器的存储库上进行更改，然后将其向上游推送到主服务器。
这些是chef-solo的主要优势。还有一些其他问题，例如不必管理服务器或为托管厨师付费，但这只是相对较小的问题。
总结：如果您是动态且高度虚拟化的，chef-server提供了许多很棒的功能（在其他地方介绍过），并且chef-solo的大多数优势将不那么明显。但是，chef-solo有一些明确的，通常是未被提及的优势，尤其是在更传统的环境中。请注意，部署在云上并不一定意味着您拥有动态环境。例如，如果不能在不发布软件新版本的情况下向系统中添加更多节点，则可能不是动态的。最后，从高层的角度来看，CMDB可以用于仅与系统管理和配置相关的许多事情，例如团队之间的会计和信息共享。仅使用该功能就值得使用Chef-server。
披露：我为Opscode工作。
与Solo相比，Chef Server的主要优点是可以在基础架构中使用搜索功能。经典示例是带有Web服务器的负载均衡器。只要将Web服务器添加到基础架构中或从中删除，负载均衡器就可以自动更新其配置。Solo仅是一台机器，而Chef Server则具有查询“具有超过4 GB RAM的所有机器”或“数据库主服务器”之类的功能。
Chef Server还使您能够管理基础架构而无需复制tar包，使用管理控制台可视化基础架构以及使用环境管理哪些计算机在运行哪些版本的菜谱。还有其他好处，但这些都是我无法承受的。如果您想在不安装Chef Server的情况下对其进行试用，只需注册一个Opscode Hosted Chef帐户，则前五个节点是免费的。