我开始对 Berkshelf 感到满意（顺便说一句，这是学习厨师的好方法），现在我想知道我应该如何为我想要提供本地/VM 环境的 PHP 开发人员管理/推出开发环境从厨师食谱中提供的。
我想弄清楚对于 Chef 开发人员和应用程序开发人员（在我的例子中是 PHP 开发人员）来说，理想的环境是什么。我需要为使用我的食谱的 PHP 开发人员提供可重复的本地（或 VM）环境。
我正在考虑使用 Vagrantfile，以便开发人员可以使用他或她的证书配置厨师服务器，配置它，然后开始使用环境。我不确定的是：每个开发人员是否应该在 Chef Server 中为每个应用程序列出他或她自己的 Vagrant 节点？或者有没有办法在不注册 vagrant 节点的情况下使用 Chef 客户端配置程序？
基本上，我并不真正关心本地机器上的节点，但如果开发人员可以从 Chef 服务器提供 Vagrant 以匹配其他环境，那就太棒了。
其次，我所有的 Berkshelf 生成的存储库都使用 Chef Client 进行配置。这是一种好的做法，还是我应该仅将 chef-solo 用于开发/测试食谱作为开发操作？
完全是一个意见类型的问题，所以我会给出基于我的意见的答案。希望其他一些人能加入进来，因为他们中的许多人比我有更多的经验。
我们将测试厨房和超市结合使用，效果很好。我们有一个包含 Gemfile、.kitchen.yml 和 Berksfile 的存储库。理想情况下，它还会有一个命令设置脚本，用于设置超市用户、knife.rb、安装 Vagrant 等。这个 repo 还包含本地厨师使用的所有原语（角色、环境等）。
最终，它将有一个 Rakefile 可以很好地包装所有这些。
rake setup # installs any non-gem stuff, sets up users, berks install, etc.
rake standup # stands up our primary app and dependencies (involves multiple VMs playing together)
rake standup:standalone # stands up the primary app and dependencies all on one box
rake standup:otherApp # you get the idea
然后，每个 rake 任务可以kitchen converge根据需要调用任意数量的操作。
首先，随着Chef-zero（又名本地模式）变得越来越流行，chef-solo 正在失宠。Solo 永远不会消失，但我在您的用例中看不到它的原因。
其次，我见过的大多数 Chef 似乎都从 Vagrantfile 转向了 test-kitchen。Kitchen 默认使用 Vagrant，并且像 Vagrant 一样也能够使用各种其他系统（Docker、AWS、Rackspace、VMware 等）。它只是以厨师为中心。并且对于您所描述的内容非常有效，因为您的“开发环境”无论如何都需要一个测试框架。那么，当您可以使用 test-kitchen 并用一块石头得到两只鸟时，为什么还要在上面使用带有测试框架的 Vagrant。
第三，Chef-zero 是您的朋友。不要让每个开发人员都使用 chef-server 启动 VM。只需拥有一个包含您的环境、角色和 data_bags 的 git 存储库。然后让他们使用 chef-zero 供应商运行 Test-Kitchen，或者 chef-local（运行 chef-zero）指向 git 存储库。这种方式的重量要轻得多，并且允许所有开发人员共享公共对象。
第四，结帐 ChefDK。它几乎包含了上述所有内容，并且很可能成为“正常”的做事方式。
第五，如果你还是从头开始盯着看，我建议在你的生产厨师服务器旁边安装超市和厨师警卫。Chef-guard 将使管理对角色、环境和数据包的更改 1000% 更容易处理。Supermarket 与 Berkshelf 完美集成，让您可以完全控制环境中使用的食谱版本。