Существует ли способ обновить ОС с помощью Марионетки без должностного лица для выполнения конфетки?

TL; DR это не очень хорошая идея. Выполните обновление вручную или с помощью другой формы автоматизации.

Почему это плохая идея

Я не думаю, что вам вообще стоит идти по этому пути.

Как правило, идея использовать Puppet для убедиться, что обновление ОС было успешно завершено, это нормально, по крайней мере, с академической точки зрения. Цель Puppet - позволить вам определить состояние и позаботиться о деталях достижения этого состояния.

При этом Puppet потребует (вымышленный) тип дистрибутива , чтобы вы могли указать

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

Вы могли бы пойти дальше и реализовать такой тип, с возможностью попытаться выполнить действие синхронизации, чтобы получить от текущей версии до той, которую вы запросили.

Однако такой процесс может быть бесконечным. сложен и имеет практически неограниченные возможности для сбоев и повреждения системы (из-за неправильных действий или вообще). Таким образом, он не очень хорошо поддается какой-либо форме автоматизации.

Что касается конкретно Puppet, вам нужно добавить логику к своему типу / поставщику дистрибутива , чтобы восстанавливаться после всех видов странных состояния и добиться чистой.От одной мысли о таком стремлении у меня кружится голова.

Что было бы менее болезненно

Напишите сценарий оболочки. Если количество машин слишком велико, чтобы выполнять их партиями с использованием cssh (как я, вероятно, сделал бы для всего, что меньше нескольких сотен узлов), создайте простую оболочку, которая сделает все, что вам нужно. Разверните его с помощью Puppet, и да, используйте ресурс exec , если вы хотите, чтобы Puppet запускал обновление. Рассмотрим

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

, чтобы процесс марионеточного агента не был родительским для экземпляра yum , который будет выполнять всю работу. Это может оказаться катастрофическим.

Тем не менее, я бы запустил команды yum вручную, если это вообще возможно.

Я согласен с тем, что обновление ОС через марионетку выглядит слишком подверженным ошибкам и, наконец, непредсказуемым. Но это не совсем так, если вы следуете трем правилам:

1. Управляйте машинами с максимальным уровнем стандартизации в отношении конфигурации ОС. Чтобы получить это, вы должны управлять ими строго через марионетку.
   Никаких домашних животных, только крупный рогатый скот!
2. У вас есть по крайней мере один этап тестирования.
3. Ваш механизм развертывания гарантирует, что точный код марионетки, который вы протестировали, работает на следующем этапе.
4. Само обновление должно быть самым последним этапом. при запуске марионетки.
5. Как уже обсуждалось, команда для необходимой перезагрузки не должна быть родительской для марионеточного процесса. В противном случае запуск марионетки завершится как минимум ошибкой.

Я использую следующий код марионетки для обновления машин ubuntu с 12 до 14:

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',
  }