我想更好地控制我的部署环境，但是我与IT部门共享系统pipe理责任，IT部门拥有自己的（不完全自动的）进程，用于引导VM实例，pipe理组织用户和执行安全更新。
即使系统的初始状态超出了我的控制范围，并且由于厨师外部的安全更新（也可能还有其他手动干预）而定期更换，我仍然可以从使用厨师（可能是Chef-Solo）中受益吗？ 我不能在IT部门引入不同的工作stream程。
他们的职责：
我的职责：
据我所知，这与主厨背后的一个完全控制的环境背道而驰，并且会为生产环境之间以及他们与我的分段环境（IT从不触及的本地VM）之间的分歧留出空间。
使用像厨师这样的工具还是值得的“麻烦”？ 我的工作stream程如何与完全控制的环境有所不同？
我想说你比厨师更擅长控制一切。 我想你对厨师有什么要做的错误想法。
厨师并不是要控制整个环境。 事实上，你可能不应该尝试与厨师提供的东西。 供应（主要是你的IT部门提供什么）是Chef和其他CM系统没有真正解决的问题。 安装操作系统后，厨师接pipe，基本的networking连接已经build立。 真的，在你的IT部门提供什么和从AWS获得什么之间没有太大的区别。
厨师（和其他好的厘米）是关于确保configuration是稳定和可重复的。 在你的情况下，它似乎是理想的，如果你的configuration步骤，你希望它尽快恢复。 你可以使用Chef来控制你想要的configuration。
如果您的生产应用程序需要configuration，则需要该应用程序的configurationpipe理系统。 厨师可能会也可能不是你的正确工具，但是你需要一些东西。 您的CM可以像保存configuration文件在版本控制中一样简单，并使用makefile来安装它们。 （单个机器上的单个服务很好，但没有其他的东西。）
你需要问的问题是你工作的规模和你需要pipe理多less服务？ 厨师是一个功率倍增器，但它放大了好与坏。 如果你犯了一个错误，你无所不在。 所以这需要一些testing手段和相当数量的初始工作。 但是，这种能力使您能够以更大的规模工作。
如果你有更多的机器或更多的服务来pipe理，那么你至less要尝试使用厨师，看看它是否适合你。
除了不是“最佳做法”，我会说使用厨师（-solo）会有一些好处。
考虑到你真的拥有你想要pipe理的应用程序栈，你可以和主厨一起pipe理它。 安全更新应该 – AFAIK – 不会干扰，因为它们通常是应用程序的更新（二进制），而不是您想要pipe理的configuration。 但是，如果其他团队将更改应用程序堆栈的目录/文件权限，则会出现问题，因为他们可能不明白为什么每小时会更改一次。
另一种可能性是，你使用每个文件的主厨做的备份，并将它们区分到预期状态 – 之后你可以合并团队的可能的configuration更改，但是当你需要的时候会有一些不一致的状态合并
所以我的结论是：如果你只是想pipe理 – 说 – 在某些服务器上的Apache，我想你可以做任何configurationpipe理 – 如果其他团队没有试图改变相同的configuration