离开 Chef 一段时间后，我目前正在回到它来满足我所有的服务器需求。几年前我已经使用了一段时间并且很喜欢它，但最近让其他人做了操作部分。
但是我仍然在努力寻找一个非常好的开始设置（本地 Vagrant+Chef）来进行开发。单独使用 Vagrant 是一件轻而易举的事，超级容易使用，并且在其上开发服务器设置相当快。但是一旦我不得不离开 Vagrant 进行实际部署，它就会再次变得烦人。我不能总是使用 Vagrant 盒子，但有时在某个地方使用 Rackspace 甚至是实际的硬件盒子。
现在我这样做如下：
针对 Vagrant 进行开发，尽量减少 Vagrantfile 中的实际配置
- 主要使用角色，并为我的常用环境预定义默认属性
- 仅在 Vagrantfile 中指定节点特定属性
- 在步骤之间直接从 VirtualBox 手动快照运行 vagrant 配置，以避免一直从头开始重新构建
暂存并实际部署服务器：
将 Rackspace Cloud（至少暂存）与 Knife Solo 一起使用
- 从 Web 界面创建 Rackspace 服务器以通过（roo@ip 和密码）为所有服务器提供一致的第一个配置步骤
- 将公钥身份验证添加到服务器，因此不再需要密码
- 为新服务器添加本地节点配置，复制 Vagrantfile 中定义的内容
- 使用刀单独准备+引导服务器
这已经不是那么糟糕了，但仍然有一些有时很烦人的小故障：
- 来自 VirtualBox 的 Vagrant 手动快照（我还没有找到任何可用的插件）
- 节点配置和 Vagrantfile 之间的冗余（可能让 Vagrantfile 解析节点配置并以这种方式使用值）
- Vagrant 和 Knife Solo 之间的引导不一致（如果我弄清楚如何将它添加到 Vagrant (*1)，可能会为两者使用一个通用脚本）
除此之外，我不得不遗憾地发现，厨师的食谱已经广泛地成长为一个由不相容和固执己见的人工制品组成的丛林。有时甚至很难使用默认配方进行基本设置。我有点惊讶，很多基础知识都几乎没有涵盖：
让 sshd+iptables 的组合工作我花了一天的时间研究，然后仍然修改默认模板以使其工作 - 虽然我希望它成为几乎所有服务器的起点。此外，似乎没有任何默认的厨师用户工作流程。到目前为止，我发现的所有内容要么以 root 身份运行，要么需要进行相当多的修改。最后但并非最不重要的一点是，厨师（在 ubuntu 12.04 上）仍然使用 ruby 1.8.7，它在短短几个月内就即将结束。
可能是我只是没有找到合适的资源来涵盖我目前仍在努力或满意的所有要点，但似乎仍有很多方法可以改进它。
那么 vagrant + chef 如何在真实环境中（不仅仅是本地虚拟盒子）为您工作，还有哪些需要注意的陷阱？
似乎在本地通过 vagrant 进行所有自动引导变得非常棒，但是一旦超出范围，事情就会变得非常混乱。如果人们也使用类似这样的设置可以给我一些关于如何解决上述问题的指示，我会很高兴。我不介意付出一些努力来让它像我期望的那样运行，但也许我已经走错了部分，只是让自己更加困难，实际上需要这样做；）
现在简短的总结是：Vagrand+ChefSolo (KnifeSolo) 非常棒，但要正常工作，整个引导部分需要我们在应用食谱之前切换为自定义部分以获得适当的系统基础 - 这些需要小心从丛林中挑选出来。
进展/更新说明
(*1): 刚刚想通了，纯粹靠运气，很明显可以在一个 Vagrantfile 中添加多个供应机制：
config.vm.provision :shell, path: 'bootstrap.ubuntu-12.04.2-server-amd64.sh'
config.vm.provision :chef_solo do |chef|
...
end
由于首先执行 shell，我可以将它用作 Vagrant 服务器的自定义准备，同时仍然使用 Chef-Solo 进行实际设置。耶。最后仍然必须看看这会有多有用，但现在有一个缺失的步骤可以使流程保持一致。