配置管理工具（Puppet，Chef）是否能够使安装的软件包保持最新？

对于已经在运行配置管理工具的人来说，这可能是一个简单的问题。配置管理工具（例如Puppet或Chef）是否是使安装的软件包保持最新状态的正确方法？

假设我运行许多服务器，大多数基于Debian和Ubuntu。当出现安全更新或错误修复时，配置管理工具是否使从存储库中安装的软件包的更新更容易？

我目前正在运行“无人值守升级”，以使系统自动安装安全更新，但我仍然必须连接到服务器并aptitude update && aptitude safe-upgrade经常运行。自然，随着服务器数量的增加，这变得无聊，乏味且容易出错。

Puppet或Chef之类的工具是否是使安装的软件包保持最新状态的正确方法？你们中有人使用这些工具来避免手动运行aptitude或在15台服务器上等效运行吗？我很确定这些问题的答案是“是的，当然！”

但是在哪里可以找到有关此特定用例的更多信息？我还没有时间深入研究Puppet或Chef，而示例菜谱或类仅显示或多或少的安装一个特定软件包（例如ssh）的小例子。除了官方文档之外，您是否有任何其他资源可以推荐（我当然会在知道哪种工具最适合我之后，就去研究这些文档）。

Puppet（我很确定厨师也会这么做）与您的apt-get / yum软件存储库相关联。由于它们费力找出可用的软件包，因此这意味着它们ensure => latest仅适用于Ubuntu / CentOS / Debian等。只要您正确设置了适当的文件（/etc/apt/sources.list，等等）。

您可以用p来做，您可以：

ensure => latest,

要么

ensure=> "1.0.2",

指定最新/所需的版本。即

package { apache2: ensure => "2.0.12-2" }
package { apache2: ensure => latest }

这至少意味着您可以在所有系统上指定相同的版本，以及防止服务器（可能有危险）自动升级自身。我已经在许多站点的生产中使用了这种方法，并且效果很好。

运行无人值守的升级会让我有些恐惧，尤其是当他们正在升级关键任务软件包，内核，mysql库，apache等时。尤其是如果安装脚本可能想重新启动服务时！

我认为这可能是错误的问题。当然，使用Puppet和Chef之类的配置管理工具来维护您的基础结构是从尝试手动完成所有工作的巨大飞跃。保持软件包版本最新和同步的问题并不是任何这些工具都能直接解决的问题。要正确地自动执行此操作，您需要将软件包存储库本身置于您的控制之下。

我这样做的方法是维护一个专用的Yum存储库（用于Redhat / Fedora / CentOS；用于Debian / Ubuntu的APT存储库），其中包含我关心的特定站点的软件包。这些通常是应用程序本身（Ruby，PHP，Apache，Nginx，库等）和安全性至关重要的包的依赖项。

设置好之后（通常您可以从上游存储库中镜像所需的软件包开始），就可以使用Puppet的“确保=>最新”语法来确保所有计算机都与该存储库保持最新。

明智的做法是使用“分段”存储库，使您可以在将程序包更新版本正式投入生产之前测试其更新版本。使用Puppet可以轻松完成此操作，而无需使用存储库模板重复任何代码。

自动执行软件包版本控制会强烈建议您使所有生产系统保持同步，因为为不同的OS发行版，版本和机器体系结构维护多个存储库和软件包非常耗时，并且可能导致各种晦涩的问题和不兼容性。

所有这些建议都同样适用于您可能使用的Ruby gem，Python egg和其他包系统。

我写了一些Puppet教程，可以帮助您快速入门和使用Puppet。您可以使用Puppet将自定义存储库定义部署到计算机上，这是使程序包版本受到控制的第一步。

尽管Puppet / Chef可能是此功能的竞争者，但要使它们使系统上的所有内容保持最新，则需要自定义类型或将每个包（包括诸如libc6之类的底层系统库）作为资源列出ensure => latest。对于软件包自动更新的特定情况，您可能需要研究cron-apt软件包，它也可以完成您想要的操作。

这个问题很旧，但是我认为我会以最新的方式回答，因为当时无法使用当前的答案。

如果您使用木偶或厨师，请查看mcollective。这是puppetlabs伙计们非常好的工具，它允许您将命令发送到服务器组。http://docs.puppetlabs.com/mcollective/

它还具有一个apt插件，可用于在任意数量的服务器上进行apt更新：http : //projects.puppetlabs.com/projects/mcollective-plugins/wiki/AgentApt

我意识到这对于您最初的问题有点晚了，但是这里的精神是“迟到总比不到好”。

我使用Cfengine 3在多台服务器上执行此操作。我为自动更新指定了一个明确的软件包列表，从而避免在不加注意的情况下更新所有软件包。它工作得很好，并且cfengine 3非常轻巧。

这是我的cfengine配置中的一个承诺代码段：

    packages:
            "apache2"
                    package_method => "apt",
                    package_policy => "update";

希望这可以帮助。

我同意乔纳森。Cfengine 3方法很好，因为您可以控制包管理的各个方面，而不必在底层进行重新编码。

我们使用p + apt-dater。

您还可以使用诸如Canonicals Landscape之类的软件包管理工具，该工具旨在管理和监视Ubuntu / Debian系统。它管理多个系统，允许您同时更新它们，并提供一些基本的监视功能。

安全更新

通常，我认为使用Ansible或类似方法为Ubuntu / Debian（或RHEL / CentOS）设置健壮的无人值守升级软件包最简单yum-cron。您可以使用Puppet，Chef或其他工具，但是我将在这里讨论Ansible。

• unattended-upgrades 如果愿意，可用于同时进行非安全更新，这比每天通过Ansible运行命令要容易得多。

• unattended-upgrades每天都会进行自动更新，并且通常只限于安全更新（以提高稳定性）。如果服务器在更新后需要重新启动，则此工具可以在特定时间自动重新启动。

如果重新启动较为复杂，则unattended upgrades可以通过电子邮件发送给您，并且还会创建/var/run/reboot-required，以便Ansible（或类似机构）可以在适当的时间管理重新启动（例如，滚动Web或DB服务器集群的重新启动以避免停机），等待每次服务器在某个TCP端口上变得可用，然后继续）。

您可以使用Ansible角色，例如用于Ubuntu / Debian系统的jnv.unattended-upgrades，或简单但有效的geerlingguy.security，该角色还涵盖RHEL / CentOS（并加强 SSH配置）。

如果快速安全更新不太重要，则可以先在不太重要的服务器上对它们进行测试，然后在unattended-upgrade测试显示没有问题时运行命令-但是，面向服务器的安全修复程序很少会引起问题，经验。

一般更新

除安全性以外的其他更新应经过正常的连续集成和测试过程，以确保事情不会中断。

我aptitude safe-upgrade过去曾在服务器上遇到过严重问题，因此最好不要自动运行它，而安全更新通常是相当安全的。