对于那些已经在运行configurationpipe理工具的人来说，这可能是一个简单的问题。 像Puppet或Chef这样的configurationpipe理工具是保持已安装软件包最新的正确方法吗？
假设我运行了大量基于Debian和Ubuntu的服务器。 安全更新或错误修复出现时，configurationpipe理工具是否可以更容易地更新从存储库安装的软件包？
我目前运行“无人参与升级” ，让系统自动安装安全更新，但我仍然需要连接到服务器，并经常运行aptitude update && aptitude safe-upgrade 。 自然，这会变得无聊，乏味和容易出错的服务器越多。
像Puppet或Chef这样的工具是保持安装的软件包是否正确的正确方法？ 是否有人使用这些工具来避免在15台服务器上手动运行aptitude或同等function？ 我相当肯定这些问题的答案是“是的，当然！”
但是我在哪里可以find关于这个特定用例的更多信息？ 我还没有时间深入研究木偶或厨师，菜谱或类只是显示安装一个特定软件包（比如ssh）的简单例子。 除了官方文档外，你是否有任何资源可以推荐（当然，只要知道这些工具是否适合我，那么我将研究这些文档）。
木偶（我非常确定厨师也是）与你的apt-get / yum软件库联系在一起。 由于他们搞清楚哪些软件包可用，这意味着ensure => latest适用于Ubuntu / CentOS / Debian等。 只要你正确设置了相应的文件（ /etc/apt/sources.list等）。
你可以用木偶做，你要么做：
ensure => latest,
要么
ensure=> "1.0.2",
指定最新的/必需的版本。 即
package { apache2: ensure => "2.0.12-2" } package { apache2: ensure => latest }
这至less意味着您可以在所有系统中指定相同的版本，以及防止服务器（潜在危险地）自动升级。 我在很多网站上使用这种方法进行生产，效果很好。
运行无人值守的升级让我感到害怕，特别是如果他们正在升级任务关键型软件包，内核，mysql库，apache等。特别是如果安装脚本可能要重新启动服务！
我认为这可能是错误的问题。 当然，使用像Puppet和Chef这样的configurationpipe理工具来维护你的基础架构是一个尝试手动完成的巨大飞跃。 保持你的软件包版本保持最新和同步的问题不是任何这些工具直接解决的问题。 要正确地自动执行此操作，您需要将包存储库本身置于您的控制之下。
我这样做的方式是维护一个专门的Yum repo（对于Redhat / Fedora / CentOS; Debian / Ubuntu的APT存储库），其中包含我关心的特定站点的软件包。 这些通常是应用程序本身（Ruby，PHP，Apache，Nginx，库等）和安全关键软件包的依赖关系。
一旦你有了这个设置（通常你可以从上游回购中镜像所需的软件包开始），你可以使用Puppet的“确保=>最新”的语法，以确保所有的机器将与回购最新。
使用“分段”回购是明智的做法，使您能够在将它们快速转换为生产之前testing更新版本的软件包。 通过使用存储库模板，使用Puppet可以轻松完成此任务，而不需要重复代码。
自动化软件包版本控制强烈鼓励您将所有生产系统同步，因为为不同的操作系统发行版，版本和机器体系结构维护多个回购和软件包非常耗时，并可能导致各种模糊问题和不兼容。
所有这些build议同样适用于您可以使用的Rubygem，Python蛋和其他包系统。
我写了一个小木偶教程 ，可以帮助你快速启动并运行木偶。 您可以使用Puppet将自定义回购定义部署到您的机器中，作为控制包版本的第一步。
这个问题很古老，但我想我会以最新的方式回答，因为当时现有的答案是不可用的。
如果你正在使用木偶或厨师，看看mcollective。 这是puppetlabs家伙的一个非常好的工具，它允许你发送命令给服务器组。 http://docs.puppetlabs.com/mcollective/
它也有一个apt插件，可以用来在任意数量的服务器上进行apt更新： http : //projects.puppetlabs.com/projects/mcollective-plugins/wiki/AgentApt
虽然Puppet / Chef是这个function的可能的竞争者，为了使它们保持系统中的所有内容都是最新的，需要定制types或者列出每个包（包括像libc6这样的底层系统库）作为ensure => latest资源。 对于自动化软件包更新的特定情况，您可能需要查看cron-apt软件包，该软件包也是您想要的。
我意识到这个问题对于你原来的问题来说已经有点晚了，但是这里的意思是“比从未更好”。
我使用Cfengine 3在几台服务器上执行此操作。 我为自动更新指定了一个明确的软件包列表，从而避免更新所有的软件包而不需要小心。 它工作得很好，而cfengine 3非常轻便。
以下是我的cfengineconfiguration中的承诺片段：
packages: "apache2" package_method => "apt", package_policy => "update";
希望这可以帮助。
我同意乔纳森。 Cfengine 3的方法很好，因为您可以控制软件包pipe理的各个方面，而无需在低级别重新编码。
我们使用puppet + apt-dater。
您也可以使用软件包pipe理工具，如Canonicals Landscape，用于pipe理和监控Ubuntu / Debian系统。 它pipe理多个系统，允许您同时更新它们并提供一些基本的监视function。
一般而言，我认为使用Ansible或类似的方式来设置Ubuntu / Debian（或RHEL / CentOS的yum-cron ）的强大的无人值守升级包是最简单的。 您可以使用Puppet，Chef或其他工具，但我会在这里讨论Ansible。
如果您愿意，可以使用unattended-upgrades同时进行非安全更新，这比通过Ansible每天运行命令要容易得多。
unattended-upgrades每天都会自动更新，并且通常仅限于安全更新（以增加稳定性）。 如果更新后服务器需要重新启动，此工具可以在某个时间自动重新启动。
如果您的重新启动更为复杂，则unattended upgrades可以通过电子邮件发送给您，并且还会创build/var/run/reboot-required ，以便Ansible（或类似的）可以在适当的时间pipe理重新启动（例如，或DB服务器以避免停机，等待每个服务器在某个TCP端口上可用之后再继续）。
您可以使用Ansibleangular色，例如针对Ubuntu / Debian系统的jnv.unattended-upgrades ，或简单而有效的geerlingguy.security ，其中也涵盖了RHEL / CentOS（并增强了 SSHconfiguration）。
如果快速安全更新不那么重要，那么可以先在不太重要的服务器上通过testing过程，然后在testing显示没有问题时运行unattended-upgrade命令 – 但是面向服务器的安全修复程序很less会导致问题， 在我的经验中。
安全以外的更新应该经过正常的持续集成和testing过程，以确保事情不会中断。
我以前见过aptitude safe-upgrade会在服务器上造成严重的问题，所以最好不要自动运行，而安全更新通常是相当安全的。