Назад | Перейти на главную страницу

Как вернуть конфигурацию с марионеткой

Я написал модуль, который записывает конфигурацию для rsyslog в /etc/rsyslog.d/60-custconfig.conf, используя марионетку.

Когда я добавляю модуль в узел, он работает, но если я удалю комментарий или удалю вызов модуля в узле, должен ли он удалить файл? если нет, есть ли способ откатить конфигурацию или установку?

Вы не отмените действия, выполненные Puppet, удалив ресурс. Удаляя ресурс из своих манифестов, вы только говорите Puppet, чтобы он не управлял им (больше).

Кроме того, Puppet просто не помнит / не знает о предыдущих состояниях, поэтому он не может вернуться к этому. Он просто пытается изменить систему до состояния, которое вы определяете в манифестах.

Один из способов, который я вижу здесь, - это включить file ресурс снова, но теперь с ensure => absent:

file {
    '/etc/rsyslog.d/60-custconfig.conf':
    ensure => absent,
}

Также вы можете изменить дизайн модулей Puppet следующим образом:

  • Управляйте всеми файлами конфигурации rsyslog в модуле rsyslog.
  • Создайте виртуальный настраиваемые типы из других модулей, требующие изменения в rsyslog.
  • В модуле rsyslog соберите разделы виртуальной конфигурации и дайте ему указание удалить все неопределенные ресурсы этого настраиваемого типа.

Или еще проще использовать puppetlabs-concat module, определите virtual concat :: fragments в модулях и соберите их в модуле rsyslog для создания файла конфигурации '60 -custconfig.conf'. Если затем виртуальные ресурсы будут удалены из других модулей, собранные фрагменты приведут к созданию файла без фрагментов, которые теперь не управляются. Фактически они будут удалены из файла.

Вы должны явно написать код, который «отменяет» любые конкретные действия, которые вы хотите отменить.

Например, если у вас есть my_apache модуль, который устанавливает несколько пакетов, настраивает несколько файлов и обеспечивает определенное состояние, вам нужно будет написать другой класс внутри этого модуля, позвольте ему вызвать my_apache::uninstall, что отменяет каждый из того, что сделал ваш другой модуль. Класс отмены не обязательно должен находиться внутри исходного модуля или быть его частью. Это может быть совершенно отдельный класс. Хороший способ изменить классы, применяемые к хосту, - использовать ENC.

Нет простого ответа для возврата или удаления изменений конфигурации в Puppet, но один простой метод - использовать каталог конфигурации, которым управляет Puppet.

class rsyslog::config {

  file { '/etc/rsyslog.d':
    ensure  => directory,
    force   => true,
    purge   => true,
    recurse => true,
  }

  file { '/etc/rsyslog.conf':
    ensure  => present,
    content => template('rsyslog/rsyslog.conf.erb'),
  }

  file { '/etc/rsyslog.d/50-default.conf':
    ensure  => present,
    content => template('rsyslog/50-default.conf.erb'),
    require => File['/etc/rsyslog.d'],
  }

}

Вышеупомянутое означает, что Puppet полностью владеет чем-либо в /etc/rsyslog.d/ и удаляет все, что Puppet в нем не управляет. Если на сервере ранее был запущен haproxy, и у вас есть конфигурация для этого в вашем системном журнале, когда вы удалите модуль Happroxy, ссылка на /etc/rsyslog.d/40-haproxy.conf исчезнет, ​​и Puppet удалит его из каталога конфигурации . Он также генерирует событие уведомления, которое вы также можете использовать для системного журнала перезапуска Puppet, хотя для этого вам потребуется уведомить или ~> цепочка для службы.

Думаю, можно было бы использовать паттерн с антимодулями. Например...

zookeeper_present

Этот модуль полностью настроит хост для zookeeper

 zookeeper_not_present

Этот модуль отменит все, что было сделано предыдущим модулем.

lvs_present

Этот модуль полностью настроит хост для lvs.

lvs_not_present

Этот модуль отменяет все, что было сделано предыдущим модулем.

...и так далее

Однако будьте осторожны, чтобы не получить конкурирующие модули, в которых один present_module пытается что-то установить, а другой not_present_module пытается отменить эту настройку. Это может произойти, если у вас есть два модуля, требующих одного и того же.

Один из способов решить эту проблему, возможно, заключался бы в том, чтобы выделить эту общую настройку в отдельный модуль и сделать два других модуля зависимыми от этого. Однако, когда этот общий модуль больше никому не нужен, вам придется заменить его на not_present_version этого модуля вручную в файле site.pp.

Чтобы уточнить уже опубликованные ответы: Puppet управляет ресурсами. Управление означает, что он знает о состоянии ресурсов и гарантирует, что ресурс находится в желаемом состоянии. Вы говорите Puppet, чем и как управлять. И когда Puppet больше не знает о ресурсе, очевидно, что он больше не может им управлять. Так работает Puppet.

Представьте себе хаос, который он нанесет системе, если Puppet просто удалит ресурсы, о которых он больше не знает. Это само по себе уже звучит парадоксально; как удалить то, о чем вы не знаете? Но даже если бы у Puppet был способ сделать это, он, вероятно, разрушил бы вашу систему.