☰

管理大量 CentOS 服务器软件包更新的良好做法

tag-icon • tag-icon centos update automatic-updates
管理大量 CentOS 服务器软件包更新的良好做法

作为我工作的一部分，我管理着几十台 CentOS 5 服务器，主要设置使用 puppet。大约一半的服务器都采用标准化设置，用于托管各种 django 网站，而其余的则是各种应用程序的混合体。

我正在逐步整理我们的托管实践，现在我已经到了研究如何在操作系统级别管理安全更新的阶段。我对只使用 cron 作业进行更新持谨慎态度，yum -y update但也不想及时检查每台服务器并检查每个有可用更新的软件包，因为那会花一些时间。

所以我想知道是否有任何好的捷径或工作方法可以最大限度地降低所涉及的风险和尽量减少我需要花费的时间。或者换句话说，是否有任何工具或做法可以自动完成大量工作，同时仍保留控制权。

我目前决定采取的步骤：

  • 禁用所有第三方存储库并设置我们自己的存储库，以便我可以控制在那里进行的更新。
  • 我们有（大多数）生产服务器的暂存服务器，我可以在其中进行测试（但多少测试才算足够的测试？）

另请注意，我已经调查过yum 安全插件但它在 CentOS 上不起作用。

那么，如何管理运行异构应用程序的大量 CentOS 服务器的更新？

答案1

在我的大多数环境中，通常使用启动和安装后脚本来使主系统在当时启动并更新。我通常会有一个本地存储库，每天或每周与 CentOS 镜像同步。我倾向于将内核包冻结在安装时的最新版本，然后单独或根据需要更新包。很多时候，我的服务器的外围设备驱动程序与内核版本紧密相关，所以这是一个考虑因素。

CentOS 5 已经成熟到不需要不断更新的程度。但也请记住，CentOS 5 正在逐渐衰落。更新速度有所放缓，更新的性质更多地与错误修复有关，而不是重大功能更改。

因此，在这种特定情况下，您可以做的第一件事就是构建本地镜像/存储库。使用现有的配置管理来控制对第三方存储库的访问。也许可以安排策略来 yum 更新关键或面向公众的服务（ssh、http、ftp、dovecot 等）。其他一切都需要测试，但我感觉大多数环境都没有完全更新/修补的系统。

答案2

有很多工具可以帮助解决这个问题！一般来说，软件包系统和哪些软件包放到哪里由配置管理来处理。这些工具通常不仅仅涵盖 yum 和 rpm，而且可以节省您的时间并避免很多麻烦！

我最熟悉的工具是 puppet，我用它来管理我环境中的几乎所有配置。以下是一些专门用于管理 yum 的 puppet 示例：

http://people.redhat.com/dlutter/puppet-app.html

目前有许多配置管理工具可用，这些工​​具拥有相当大的用户群：

在环境中实施这些工具将延长您的寿命。它减少了因配置不当的系统而导致的麻烦，并允许轻松升级/更新。大多数这些工具还可以提供一些审计级别的功能，这可以大大减少配置错误的修复时间。

关于您关于测试的问题，我一直在使用一个临时环境，我们将一些客户负载引导到该环境（通常是测试版客户或一小部分生产流量）。我们通常让这个集群运行新代码至少几天，最多一周（取决于更改的严重程度），然后再将其部署到生产中。通常我发现，如果您尝试弄清楚大多数错误需要多长时间才能发现，这种设置效果最好。在使用频繁的系统中，这可能只需几个小时，在我见过的大多数环境中，一周的时间足以发现临时/QA 中不常见的错误。

测试的一个非常重要的部分是数据/使用情况的复制。您提到您拥有大多数生产硬件的暂存版本。他们是否也拥有生产数据的相同副本？您可以根据它重放任何生产负载吗？您甚至可以使用流量镜像将其作为生产集群的一部分吗？这通常会成为企业愿意在测试/QA 上花费的资源量之间的直接权衡。测试越多越好，尽量不要自我限制（在合理范围内），看看企业将支持什么（然后找到一种方法来多做 10%）。

相关内容