我们正在努力为基于RHEL / RHEL的服务器执行自动更新。
最初的想法：使用Puppet，我们禁用默认存储库并指向我们自己的存储库。然后，我们使用ensure => latest要自动更新的软件包。
问题：我们看到某些服务在更新（duh）后重新启动。
问题：对于如何更好地自动化Linux更新以及缓解服务自动重启的策略，是否有人有任何建议？我们希望包含Puppet的解决方案，但是，如果我们需要使用其他服务，那么这不是破坏交易的方法。
可能的解决方案：我提交了一个实现@ voretaq7和@ewwhite建议的解决方案的解决方案。似乎这是我暂时要走的路线。如果您还有其他建议，请发表评论或提出答案。
Answers:
您的一般更新策略是合理的：您有一个本地存储库（我假设您在开发环境中对其进行了测试），并且您基于该存储库（我认为是已知的）来更新所有内容。
服务重启是不可避免的：如果基础代码已更改，则需要重启服务以使更改生效。否则可能会导致更严重的后果（使代码与共享库不同步运行会导致应用程序崩溃）。
在我的环境中，我认为每季度修补程序窗口每季度“重新启动所有内容！”。窗户也一样。这种策略的优势在于，您知道服务器将在重启后重新启动，并且知道它们可以正常工作（因为需要定期对其进行测试）。
给您最好的建议是安排软件发布的时间（也许这意味着您必须用p来“手动”触发它们），并就计划的维护/停机时间向用户提供建议。
另外（或作为此过程的一部分），您可以在环境中配置冗余，以便可以重新启动一些计算机或服务，并仍然为最终用户提供服务。这可能无法完全消除任何干扰，但可以帮助将其最小化。
所增加的冗余还可以在硬件故障时为您提供保护，这在足够长的时间内是不可避免的。
软件包更新后重新启动服务是否必然存在问题？在部署之前进行小规模测试，以查看是否存在任何问题。最近，我对DenyHosts的rpmforge包遇到了一个丑陋的问题。实际上，它在yum更新的修订版之间更改了其配置和工作目录的位置。那完全是不希望的行为。通常，在同一版本的RHEL中，不会有太多问题，但是如果不能进行测试并仔细观察效果，您将永远无法确定。
另一种选择是有选择地更新服务。例如，您是否总是需要最新的软件包？这可以追溯到了解您运行更新的原因。真正的目标是什么？
运行自己的存储库的好处是，您可以分阶段发布或推出产品并管理计划。如果您的硬件外围设备或软件供应商需要RHEL 5.6，并且会在5.7以下崩溃，该怎么办？这是管理自己的软件包的好处之一。
@Beinging梅尔宾
这种简化将消除对循环工具使用ssh来启动/停止人偶的需求。
首先，您需要更改清单以包含一个名为“ noop”的变量，其值源自ENC。
因此，您将在课堂上遇到类似这样的事情：
noop => $noop_status
凡noop_status在您的ENC设置。当您设置的值noop_status来true，清单将只空操作模式下运行。
如果您拥有100或1000台主机，则可以使用Dashboard或Foreman等ENC，通过在“主机组”或“域”级别继承它们来批量更改许多主机的参数。然后，您可以将少数测试主机的值设置为“ false”，从而覆盖主机组的值。
这样，所有更改将仅应用于选定的主机。
在中央位置更改一个参数可以影响任意数量的主机，而无需使用ssh for loop工具打开/关闭off。您可以将主机分为多个组，以进行安全/管理。
还请注意，您可以将它们放在ENC中，而不是在清单中对软件包版本号进行硬编码。就像上面一样，您可以有选择地应用更改并管理部署。
如果您想要更多的粒度（和复杂性），甚至可以使用每个类的参数，诸如此类noop_status_apacheClass。
如果您include在其他课程中上课，这可能很难管理。
基于@ voretaq7的可能解决方案：
puppet清单中软件包的硬代码版本号，并在我们自己的存储库中维护软件包。
当我们需要对软件包提供新版本进行某些处理（例如，增强安全性，客户需要的功能等）时，我们会将软件包下载到存储库中。
在测试服务器上测试更新的软件包。
测试更新后，请使用func或之类的pssh方法关闭puppet受影响节点上的代理。
更新puppet清单以确保在受影响的节点上安装了新版本的软件包。
最后，puppet agent --onetime && reboot使用func或在服务器上运行pssh
如果您发现此解决方案有任何不足之处或可以简化的地方，请发表评论并告诉我。