我负责devise和实施configurationpipe理（Chef），将生产服务器完全分割并隔离在跳转框后面的基础架构中。
--------------------------------- | Production | Staging, Test, Dev | --------------------------------- 将文件投入生产的唯一方法是使用sftp连接。 只有两个人有能力直接投入生产。 一个例外可以使一个严格控制的自动化系统（如jenkins）将文件复制到生产环境中。
通常，我会build议在云中设置一个厨师服务器，但生产服务器不能有外部访问。 （没有一些非常不情愿的人的很多说服力）。
我看到的一个解决scheme是使用两个Chef服务器
--------------------------------------- | chef-production | chef-local | | Production | Staging, Test, Dev | ---------------------------------------
使用两个厨师服务器有一些问题，我不知道如何克服。
我接受其他build议。 我正考虑不使用厨师服务器，而是使用chef-zero或chef-solo 。 我的理解是，这不是使用多个环境时的最佳解决scheme。
我讨厌这种不可靠的环境，但我明白了; 你必须处理的商业要求…
你可以通过一个用于食谱的CI / CDpipe道来解决cook-in-sync问题，这样他们就可以自动部署到两个Chef服务器上。 你会想要广泛地利用食谱固定的东西，但是提供更新（即使它们没有被主动使用）也没有问题。 Sous-Chef是我公司开源的一个工具，可以帮助人们开始自动化食谱testing并上传到Chef Server。 它将不得不被修改，以满足多个厨师服务器的情况下，但大部分是在那里。
由于Chef12同时具有“组织”和“基于angular色的访问控制”（RBAC）function（以前只能在付费产品中使用），您可以build立权限，只有指定的人员才能修改生产环境，或者生产在同一个厨师服务器内是一个单独的组织。
向Prod Chef服务器添加新节点将需要某种引导。 根据您的环境，细节会有很大的差异，但是将安装程序放在本地环境中，您可以在从VM模板启动或部署时将其设置为运行一次的作业。 如果你有通过API启动虚拟机的工具，把它扩展到添加引导命令不应该太糟糕。 （厨师毕竟是一个API驱动的系统。）
这里关于数据包的问题太广泛了。
请记住，有多个厨师服务器将需要有独立的knifeconfiguration，所以你要么必须记住传递一个configuration标志为每一个，或包装命令knife联合configuration文件。 除非你有足够的自动化，永远不需要knife 。
Chef-Zero旨在用于使用Chef-Solo本地testing，但需要search。 pipe理你的产品盒子并没有什么意义。
一些公司使用Chef-Solo以“按需运行”的非testing环境。 就我个人而言，我不喜欢这个。 我喜欢Solo来进行本地testing（比如使用Vagrant），或者如果你正在设置系统，意图是不可变的。 如果你要有长期运行的服务器（大部分是无状态的，经常被拆除，标准的Chef-Server将帮助你保持configuration不随时间stream逝。