Кукольный: Восстановление после неудачного запуска - PullRequest
Новая
       8

Кукольный: Восстановление после неудачного запуска

0 голосов
/ 20 ноября 2018

Рассмотрим следующий код: 

file { '/etc/systemd/system/docker.service.d/http-proxy.conf':
  ensure  => 'present',
  owner   => 'root',
  group   => 'root',
  mode    => '644',
  content => '[Service]
Environment="HTTP_PROXY=http://10.0.2.2:3128"
Environment="HTTPS_PROXY=http://10.0.2.2:3128"
',
  notify  => Exec['daemon-reload'],
  require => Package['docker-ce'],
}

exec { 'daemon-reload':
  command     => 'systemctl daemon-reload',
  path        => '/sbin',
  refreshonly => true,
}

service { 'docker':
  ensure    => 'running',
  subscribe => File['/etc/systemd/system/docker.service.d/http-proxy.conf'],
  require   => Exec['daemon-reload'],
}

Я хотел бы отредактировать какой-нибудь сервис systemd.В этом случае это среда для докера, но может потребоваться любая другая необходимость.

Поскольку файл системного модуля был изменен, systemctl daemon-reload должен быть запущен для новой конфигурацииПодниматься.

Запуск puppet apply завершается неудачно: 

Notice: Compiled catalog for puppet-docker-test.<redacted> in environment production in 0.18 seconds
Notice: /Stage[main]/Main/File[/etc/systemd/system/docker.service.d/http-proxy.conf]/ensure: defined content as '{md5}dace796a9904d2c5e2c438e6faba2332'
Error: /Stage[main]/Main/Exec[daemon-reload]: Failed to call refresh: Could not find command 'systemctl'
Error: /Stage[main]/Main/Exec[daemon-reload]: Could not find command 'systemctl'
Notice: /Stage[main]/Main/Service[docker]: Dependency Exec[daemon-reload] has failures: false
Warning: /Stage[main]/Main/Service[docker]: Skipping because of failed dependencies
Notice: Applied catalog in 0.15 seconds

Причина очевидна: systemctl живет в /bin, а не /sbin, как настроено.Однако, исправив это, затем снова запустив puppet apply, не приведет ни к перезапуску службы, ни к запуску systemctl daemon-reload: 

Notice: Compiled catalog for puppet-docker-test.<redacted> in environment production in 0.19 seconds
Notice: Applied catalog in 0.16 seconds

Очевидно, это происходит из-за того, что в файловом ресурсе не было никаких изменений (поскольку он был применен при неудачном запуске), который обновил бы daemon-reload и затем запустил службу для перезапуска.

Чтобы заставить puppet перезагрузить службу и перезапустить ее, я мог изменить содержимоефайла на диске, я мог бы изменить содержимое кода марионетки, но ощущается как Мне не хватает лучшего способа сделать это.

Как лучше восстановиться после такого сценария?Или, как написать кукольный код, который не имеет этой проблемы?

Ответы [ 2 ]

0 голосов
/ 03 декабря 2018

Так как ваш http-haproxy.conf уже был обновлен при первом выполнении puppet, поэтому в следующий раз он не будет обновляться снова и уведомление об отправке systemctl daemon-reload не будет выполнено

В случае, если вам нужночтобы запускать systemctl daemon-reload все время, если есть уведомление или нет, вам нужно более refreshonly => true из exec 'daemon-reload'

0 голосов
/ 20 ноября 2018

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

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

Например, вы знаете, что любой сбой может вызвало пропуск демона-перезагрузки, и его выполнение безвредно, когда в этом нет необходимости, поэтому просто включите это в свой скрипт.Вы также можете перезапустить каждую службу под управлением.По сути, вы ищете что-нибудь, что имеет нетривиальное поведение обновления (Exec s и Service s - основные, которые приходят мне в голову).

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

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

...