我希望更好地控制我的部署环境，但我与 IT 部门共享系统管理责任，该部门拥有自己的（非完全自动化的）流程来引导 VM 实例、管理组织用户和执行安全更新。
我是否仍然可以从使用 Chef（可能是 Chef-Solo）中受益，即使系统的初始状态不受我控制，并且会由于 Chef 之外的安全更新（也可能是其他手动干预）而定期发生变化？我没有资格在 IT 部门引入不同的工作流程。
他们的职责：
- 提供硬件和虚拟机
- 安装具有“基本功能集”的操作系统（目前为 SLES 11）
- 应用来自同一 SLES 版本的安全更新
- 管理任何组织用户的访问权限
- 备份
我的职责：
- 安装和管理应用程序依赖项（采用优先使用 SLES 发行版中的软件包的策略）
- 对不属于 SLES 发行版的任何已安装软件应用安全更新
- 配置所需的服务
- 部署应用程序
据我所知，这违背了 Chef 等工具背后完全受控环境的理念，并且会为生产环境之间以及生产环境和我的暂存环境（IT 从未接触过的本地 VM）之间的差异留下空间。
使用 Chef 这样的工具是否仍然值得“费心”？我的工作流程与完全受控环境的工作流程有何不同？
答案1
我想说，与你掌控一切的情况相比，Chef 对你来说更有用。我认为你对 Chef 能为你做什么的理解是错误的。
Chef 并不是要控制整个环境。事实上，有些东西你可能不应该尝试用 Chef 来提供。配置（主要是你的 IT 部门提供的）是 Chef 和其他 CM 系统实际上没有解决的问题。在安装操作系统并设置基本网络连接后，Chef 会接管。实际上，你的 IT 部门提供的和你从 AWS 获得的并没有太大的区别。
Chef（和其他优秀的 cm）旨在确保配置既稳定又可重现。对于您来说，理想的情况是，如果某些东西影响了您的配置，您希望它尽快恢复。您可以使用 Chef 来控制您想要的配置。
如果您有一个需要配置的生产应用程序，则需要为该应用程序配备一个配置管理系统。Chef 可能适合您，也可能不适合您，但您需要一些东西。您的 CM 可以很简单，只需将配置文件保存在版本控制中并使用 makefile 来安装它们即可。（对于单台机器上的单个服务来说还不错，但其他就不行了。）
你需要问的问题是，你的工作规模有多大，需要管理多少服务？Chef 是一个能力倍增器，但它会放大好坏两方面的影响。如果你犯了一个错误，那么你会犯下大错。因此，这需要一些测试手段和大量的初始工作。但这种能力使你能够以更大的规模开展工作。
如果您需要管理的机器或服务多得数不清，那么我至少会尝试使用 Chef，看看它是否适合您。
答案2
除了它不是“最佳实践”之外，我想说使用 chef(-solo) 可能会有一些好处。
假设您真的“拥有”您想要管理的应用程序堆栈，那么您可以使用 chef 来管理它。据我所知，安全更新不应该干扰这一点，因为它们通常是应用程序（二进制）的更新，而不是您想要管理的配置。但如果另一个团队更改了您的应用程序堆栈的目录/文件权限，那么就会出现问题，因为他们可能不理解为什么每小时都会更改。
另一种可能性是，你使用 chef 对其接触的每个文件进行的备份，并将它们与预期状态进行比较 - 之后，你可以合并团队可能的配置更改，但在你需要合并时会存在一些不一致的状态
所以我的结论是：如果你只是想管理某个服务器上的 Apache，我想你可以使用任何配置管理来做到这一点 - 如果另一个团队没有试图更改相同的配置