自动化 Linux 更新的最佳实践

Question

我们正在研究一种为基于 RHEL/RHEL 的服务器执行自动更新的方法。

最初的想法：使用 Puppet，我们禁用默认存储库并指向我们自己的存储库。然后，我们使用ensure => latest我们想要自动更新的包。

问题：我们看到某些服务在更新后重新启动（废话）。

问题：有人对如何更好地自动化 Linux 更新和减轻服务自动重启的策略有任何建议吗？我们更喜欢包含 Puppet 的解决方案，但是，如果我们需要使用其他服务，那不是交易破坏者。

编辑

可能的解决方案：我提交了一个解决方案，该解决方案实现了@voretaq7 和@ewwhite 建议的许多内容。好像这就是我暂时要走的路线。如果您有其他建议，请发表评论或提交答案。

Answer 1

您的一般更新策略是合理的：您有一个本地存储库（我假设您在开发环境中进行测试），并根据该（我假设已知良好的）存储库更新所有内容。

The service restart thing is inevitable: If the underlying code has changed you need to restart the service for that change to take effect. Failing to do so can lead to worse consequences (running code out of sync with a shared library leading to a crash of the application).
In my environment I consider the quarterly patch windows to be quarterly "REBOOT ALL THE THINGS!" windows too. The advantage of such a policy is that you know that your servers will come back up after a restart, and you know they'll work properly (because you test them regularly).

My best advice to you is to schedule the software releases (maybe this means you'll have to trigger them "manually" with puppet), and advise your users of the planned maintenance/downtime.
Alternatively (or as part of this) you can configure redundancy in your environment such that you can have a few machines or services restarting and still provide service to the end users. This may not completely eliminate any disruptions, but it can help minimize them.

The added redundancy also protects you in the event of hardware failures, which are inevitable on a long-enough time scale.

Answer 2

Is there necessarily a problem with restarting a service after a package update? Test on a small scale before you deploy to see if there are any issues. I recently had an ugly issue with the rpmforge package of DenyHosts. It actually changed the location of its configuration and work directories between revisions from a yum update. That's totally undesired behavior. Typically, within the same revision of RHEL, there aren't too many issues, but you can never be sure without testing and watching the effects closely.

Another option is to selectively update services. Do you always need the latest packages, for example? This goes back to understanding your reasons for running updates. What is the real goal?

运行您自己的存储库的优势在于您可以分阶段发布或推出并管理计划。如果您的硬件外围设备或软件供应商需要 RHEL 5.6 并且会在 5.7 下崩溃怎么办？这是管理自己的包的好处之一。