有没有一种方法来升级操作系统使用Puppet没有EXEC运行百胜？

TL; DR这不是一个好主意。 手动进行更新，或使用不同forms的自动化。

为什么这是一个糟糕的主意

我不认为你应该走这条道路。

一般来说，至less从学术的angular度来看，使用Puppet来确保操作系统更新已经成功完成的想法是合理的。 木偶的目标是让你定义一个状态，并照顾到达这个状态的细节。

这就是说，木偶将需要一个（虚构） distrotypes，所以你可以指定

 # pseudo code! Do not try at home or at all! distro { 'CentOS', version => '6.6'; } 

你可以想象，继续并实现这样一种types，能够尝试和执行一个同步操作，从你当前的版本得到你所请求的版本。

然而，这样的过程可能是无限复杂的，对于失败和系统腐败（完成错误或根本就没有）几乎是无限可能的。 因此，它不能很好地适应任何forms的自动化。

至于Puppet，具体来说，你会想添加逻辑到你的distro /提供者从各种奇怪的状态中恢复，并实现一个干净的。 仅仅想到这样的努力让我头晕目眩。

什么会less一些痛苦

编写一个shell脚本。 如果机器数量太大，无法批量使用cssh （正如我可能会做的任何低于几百个节点），创build一个简单的包装，将尽你所需。 使用Puppet进行部署，如果您希望Puppet触发更新，请使用exec资源。 考虑

 exec { 'echo /my/update/script | at now+10min': } 

所以puppet agent过程不是将做所有工作的yum实例的父亲。 这可能是灾难性的。

不过，如果可行的话，我会手动启动yum命令。

我同意通过木偶升级操作系统看起来像是太容易出错，最后是不可预测的。 但是，如果遵循三条规则，则这不是真的：

1. pipe理有关操作系统configuration的最高标准化水平的机器。 为了得到这个，你必须严格通过傀儡pipe理他们。
   没有宠物，只有牛！
2. 你至less有一个testing阶段。
3. 您的部署机制可以确保您testing的确切木偶代码在下一个阶段运行。
4. 升级本身必须是木偶运行的最后一步。
5. 正如已经讨论过的，必要的重启命令不能是木偶进程的父项。 否则，木偶运行至less会以错误结束。

我使用下面的puppet代码来升级从12到14的ubuntu机器：

 class os_upgrade { # Script for automatic reboot after the puppet run file {'/tmp/reboot_after_puppetrun.sh' : content => "watch -g ls -l ${::puppet_vardir}/state;nohup /sbin/reboot\n", mode => '0755', } # Unattended upgrade exec { 'do-release-upgrade' : command => '/usr/bin/do-release-upgrade -f DistUpgradeViewNonInteractive -m server', logoutput => true, onlyif => "test $::operatingsystemrelease != '14.04'", notify => Exec['reboot_after_upgrade'], timeout => 1800, } # Trigger the reboot as a background job to avoid puppet parentship exec { 'reboot_after_upgrade' : command => "/usr/bin/nohup /tmp/reboot_after_puppetrun.sh&", refreshonly => true, } } 

要达到第4点，你必须定义一个阶段，并确保上面提到的类正确归因。

在site.pp ：

 stage {'post': subscribe => Stage['main']} node 'your_machine' { class { 'os_upgrade' : stage => 'post', }