我们正在研究一种对我们的 RHEL/基于 RHEL 的服务器执行自动更新的方法。
最初的想法：使用 Puppet，我们禁用默认存储库并指向我们自己的存储库。然后，我们使用ensure => latest要自动更新的包。
问题：我们看到一些服务在更新后重新启动（呃）。
问题：有人能提供一些关于如何更好地自动化 Linux 更新以及缓解服务自动重启策略的建议吗？我们更喜欢包含 Puppet 的解决方案，但如果我们需要使用其他服务，那也没什么大不了的。
编辑
可能的解决方案：我提交了一个解决方案，它实现了@voretaq7和@ewwhite建议的许多内容。这似乎是我暂时要走的路线。如果您有其他建议，请评论或提交答案。
答案1
您的一般更新策略是合理的：您有一个本地存储库（我假设您在开发环境中对其进行测试），并且您根据该存储库（我假设已知良好的存储库）更新所有内容。
服务重启是不可避免的：如果底层代码发生了变化，您需要重启服务才能使更改生效。如果不这样做，可能会导致更糟糕的后果（运行与共享库不同步的代码，导致应用程序崩溃）。
在我的环境中，我认为季度补丁窗口也是季度“重启所有东西！”窗口。这种策略的优点是，您知道你的服务器将在重启后恢复运行，并且你知道它们会正常工作（因为您定期测试它们）。
我给您的最佳建议是安排软件发布（这可能意味着您必须使用 puppet“手动”触发它们），并告知您的用户计划的维护/停机时间。
或者（或作为其中的一部分），您可以在您的环境中配置冗余，以便您可以重新启动一些机器或服务，同时仍为最终用户提供服务。这可能无法完全消除任何中断，但可以帮助最大限度地减少中断。
增加的冗余度还可以在发生硬件故障时保护您，而硬件故障在足够长的时间范围内是不可避免的。
答案2
软件包更新后重新启动服务一定有问题吗？在部署之前先进行小规模测试，看看是否存在任何问题。我最近遇到了一个严重的问题，即 rpmforge 软件包拒绝主机。它实际上通过 yum 更新在修订版本之间更改了其配置和工作目录的位置。这是完全不受欢迎的行为。通常，在 RHEL 的同一修订版本中，不会出现太多问题，但如果不进行测试并密切观察效果，您永远无法确定。
另一种选择是选择性地更新服务。例如，您是否始终需要最新的软件包？这又回到了了解您运行更新的原因。真正的目标是什么？
运行自己的存储库的优点是，您可以分阶段发布或推出并管理时间表。如果您的硬件外围设备或软件供应商需要 RHEL 5.6，但在 5.7 下会崩溃，该怎么办？这是管理自己的软件包的好处之一。
答案3
@Beaming Mel-Bin
这种简化将消除使用 ssh 循环工具来启动/停止 puppet 的需要。
首先，您需要更改清单以包含一个名为“noop”的变量，其值来自 ENC。
因此，你会在课堂上看到类似这样的内容：
noop => $noop_status
在您的 ENC 中设置的位置。当您将的noop_status值设置为时，清单将仅在 noop 模式下运行。noop_statustrue
如果您有数百或数千台主机，您可以使用 ENC（如 Dashboard 或 Foreman），通过在“主机组”或“域”级别继承这些参数，您可以批量更改许多主机的参数。然后，您可以将少数测试主机的值设置为“false”，覆盖主机组值。
这样，任何更改都仅应用于选定的主机。
在中心位置更改一个参数可以影响任意数量的主机，而无需使用 ssh for loop 工具打开/关闭 puppet。您可以将主机分成多个组以确保安全/管理。
另请注意，您可以将软件包版本号放在 ENC 中，而不是硬编码在清单中。与上述情况一样，您可以有选择地应用更改并管理发布。
如果您想要更高的粒度（和复杂性），您甚至可以拥有每个类的参数，等等noop_status_apacheClass。
include如果你在其他班级上课，这可能会更难管理。
答案4
根据@voretaq7 的回答可能的解决方案：
在清单中对软件包的版本号进行硬编码
puppet，并在我们自己的存储库中维护软件包。当我们需要某个软件包的新版本来实现它所提供的某些功能（例如，安全增强、客户所需的功能等）时，我们会将该软件包下载到存储库。
在测试服务器上测试更新的包。
一旦测试了更新，请使用类似
func或pssh关闭puppet受影响节点上的代理。更新
puppet清单以确保受影响的节点上安装了新版本的包。最后，使用或运行
puppet agent --onetime && reboot在服务器上funcpssh
如果您发现此解决方案存在任何缺陷或任何可以简化的地方，请发表评论并告知我。