完全是一个意见类型的问题,所以我会给出基于我的意见的答案。希望其他一些人能加入进来,因为他们中的许多人比我有更多的经验。
对于应用程序开发人员
我们将测试厨房和超市结合使用,效果很好。我们有一个包含 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 完美集成,让您可以完全控制环境中使用的食谱版本。