一般来说（据我所知）主要的基础设施/配置管理系统（Puppet、Chef、Ansible 和 SaltStack）都基于这样的理念：您的服务器是“牛”而不是“宠物”，而且它们似乎对您直接对服务器进行配置更改的想法持反对态度。
虽然我曾经使用过 Chef、Puppet 和 Salt，但一直以来都是从开发人员的角度，使用 Vagrant 设置单独的盒子进行开发，所以我的经验无助于回答这个问题。
问题是：这些系统中是否有任何一个支持这样的用例：您直接对服务器进行更改，并将其保留一段时间，而不必担心本地守护进程会用官方配置覆盖它？您应该能够进行更改（并且最好设置保护其不被覆盖的时间窗口），而无需对（例如）Chef 配方或 Salt 状态进行任何重大更改。此用例的全部目的是避免让五分钟的配置更改因公司摩擦和寻找正确（例如）盐状态的复杂性而陷入困境，并确保没有副作用，并经历发布/部署周期和测试，以确保您在此过程中没有破坏任何东西。
如果您想要一个更具体的例子，假设您想要调整 logrotate 设置以用于多个日志，以平衡节省驱动器空间和访问历史数据。您知道在任何给定设置下您将保存多少数据，以及您认为需要保留多少数据，但您不是 100% 确定。最好一开始就进行更改，然后看到 (1) 有人抱怨他们需要更多历史数据来进行某些调试任务，或者 (2) 您没有节省您预期和需要节省的那么多驱动器空间。
五分钟的改变实际上可以是五分钟的改变，如果你的配置管理系统允许的话，然后一旦你确定你想要在履行特定角色的所有盒子上进行这些更改，你就可以让 Chef/Puppet/Salt/Ansible 为你管理。
注意：我问的不是配置管理系统的用例还没有管理某种类型的配置文件，但这种情况已经管理某种类型的配置文件，但您想进行本地更改并让它们在给定的机器上优先，而不是被覆盖。
这些系统是否支持我的用例？（无需我与系统斗争或做后空翻即可使其工作。）
答案1
配置管理系统通过在更改期间禁用目标主机上的配置来支持此用例。以 chef 为例，您将禁用节点上的 chef-client。这会导致节点在 Chef 服务器中显示为“过时”，但这是一个有用的提醒，表明该节点不合规，应向前滚动或回滚更改。
对于单个文件，您可以执行 chattr +i，我见过的任何工具都不知道如何绕过它。
对于 chef 还有一个额外的想法——对于文件模板，如果文件在最初运行 chef 之前不存在，您可以告诉 chef :create_if_missing，这样它只会接触该文件一次。
答案2
您没有提到 PowerShell DSC，但我会提出几种方法 - 特别是因为 PowerShell 即将出现在 Windows 以外的其他系统上。其中一些方法可能在其他选项中有等效方法。
我能想到用 DSC 处理你的案例的四种方法：
- 如果您更改了未经任何资源测试的内容，它根本就不会被发现。我预计这也适用于其他基于配方的选择。
- 将 LCM 设置为应用和监控，然后以任何您想要的方式进行更改。您可以测试您的系统是否仍然符合要求，但它不会尝试修复它。
以下选择的优点是可以让您的更改成为“配方的一部分”并可重新创建。
- 使用部分配置的明确设置来部署您的系统，其中您的“额外”设置最初不会发布，但可以稍后添加。这假设您计划“临时”设置的任何设置都不会与其他配置中的设置冲突。这实际上使您有机会将您的更改作为“配方的一部分”，而无需完全重新生成配置。
- 发布一个包含您的更改的全新配置，然后启动该配置。与上一个选项一样，该配置将幂等地应用（仅进行新的更改，而不会影响之前设置的任何内容。）
无论您使用 DSC 推送还是拉取模型，您都可以对单台或多台机器进行这些更改。
答案3
暂时不考虑从 CM 系统管理系统配置和不是与评论者已经注意到的时间相同……
值得一提的是，对于这种用例，通常可以利用现代服务器软件的惯例 -.d配置目录，允许在正确的位置插入额外的配置片段。
这样，您就可以让您的 CM 通过例如为您管理配置/etc/logrotate.d/local-whatever，同时您仍然可以通过添加/etc/logrotate.d/local-aaa-whatever或类似方式摆弄特定的机器，然后导致软件处理您覆盖的设置。
显然，如果 CM 有旨在控制整体的方案，那么/etc/logrotate.d/除了在 CM 内部做事之外，您仍然没有其他选择。