我们正在为我们的基于RHEL / RHEL的服务器执行自动更新。
最初的想法：使用Puppet，我们禁用默认存储库并指向我们自己的。 然后，我们使用ensure => latest作为我们想要自动更新的包。
问题：我们看到有些服务在更新后重新启动（duh）。
问：有没有人对如何更好地自动化Linux更新和减轻服务自动重启的策略有任何build议？ 我们更喜欢包含Puppet的解决scheme，但是，如果我们需要使用其他服务，那不是一个破坏交易的方法。
可能的解决scheme：我提交了一个解决scheme，实现了许多@ voretaq7和@ewwhitebuild议的内容。 看来这就是我现在要走的路线。 如果您有其他build议，请发表评论或提交答案。
您的一般更新策略是正确的：您有一个本地回购（我假设您在开发环境中testing），并且基于此（我认为已知）回购更新所有内容。
重新启动服务是不可避免的：如果底层代码发生了变化，您需要重新启动服务才能使更改生效。 否则可能导致更糟糕的后果（运行代码与共享库不同步导致应用程序崩溃）。
在我的环境中，我认为季度补丁窗口是季度性的“重新启动所有的东西！” 窗户也是。 这样的政策的好处是，你知道你的服务器将在重新启动后恢复，并且你知道他们会正常工作（因为你经常testing）。
我最好的build议是安排软件版本（也许这意味着你必须用“手动”方式触发它们），并告知用户计划中的维护/停机时间。
或者（或作为其一部分），您可以在您的环境中configuration冗余，以便您可以重新启动一些机器或服务，并为最终用户提供服务。 这可能不会完全消除任何干扰，但它可以帮助将其最小化。
在发生硬件故障时，所增加的冗余function还可以保护您，这在不可避免的时间范围内是不可避免的。
软件包更新后重新启动服务是否存在问题？ 在部署之前进行小规模testing，看看是否有任何问题。 我最近在DenyHosts的rpmforge包中遇到了一个难题。 它实际上改变了其configuration和工作目录在yum更新版本之间的位置。 这是完全不受欢迎的行为。 通常，在RHEL的相同修订版本中，没有太多的问题，但是如果不仔细检查和观察效果，就无法确定。
另一种select是有select地更新服务。 你是否总是需要最新的软件包？ 这回过头来理解您的更新运行的原因。 什么是真正的目标？
运行自己的回购的优点是，您可以分阶段发布或pipe理日程安排。 如果您的硬件外设或软件供应商需要RHEL 5.6，并且在5.7以下，那该怎么办？ 这是pipe理自己的软件包的好处之一。
@美丽的梅尔宾
简化将消除使用ssh作为循环工具来启动/停止puppet的需要。
首先，您需要更改您的清单，以包含一个名为“noop”的variables，其值来自ENC。
所以你会在课堂上有这样的东西：
noop => $noop_status
ENC中设置了noop_status 。 当您将noop_status的值设置为true ，清单将仅以noop模式运行。
如果您有100或1000台主机，则可以使用ENC（如Dashboard或Foreman），通过在“Hostgroup”或“Domain”级别inheritance许多主机，可以批量更改参数。 然后，您可以将less量testing主机的值设置为“false”，覆盖Hostgroup值。
有了这个，任何更改只会应用于选定的主机。
在中心位置更改一个参数可以影响任意数量的主机，而不需要使用ssh for loop工具打开/closures木偶。 您可以将您的主机分成多个组进行安全/pipe理。
还要注意，不是在清单中硬编码包版本号，而是可以把它们放在ENC中。 就像上面一样，您可以select性地应用更改并pipe理发布。
如果你想要更多的粒度（和复杂性），你甚至可以有每个类的参数，如noop_status_apacheClass等等。
如果你在其他类中include类，这可能会更难以pipe理。
基于@ voretaq7的答案可能的解决scheme：
puppet中软件包的硬编码版本号在我们自己的仓库中显示并维护包。
当我们需要一个新版本的软件包来实现它提供的function（例如，安全增强function，客户所需的function等）时，我们将软件包下载到版本库中。
在testing服务器上testing更新的软件包。
一旦更新testing，使用像func或psshclosurespuppet代理在受影响的节点。
更新puppet清单以确保新版本的软件包安装在受影响的节点上。
最后，使用func或pssh在服务器上运行puppet agent --onetime && reboot
请发表评论，让我知道，如果你发现这个解决scheme的任何缺陷或任何可以简化。