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

Puppet: запуск команды оболочки при обновлении файла (или пакета)

Я хочу бежать mysql_tzinfo_to_sql всякий раз, когда tzinfo пакет (на сервере Ubuntu) изменяется. Я подумал, что Puppet справится с этим.

Я думал, что либо Puppet отреагирует на изменение версии пакета, либо, если нет, то на изменение временных меток файла, содержащегося в пакете.

Единственный способ, которым я могу это добиться, - это иметь ресурс без прямого действия и иметь зависящий от него exec.

У меня есть следующие вопросы:

  1. Можно ли определить файл, который используется только для Поставить в известность другой ресурс (например, exec)?
  2. Можно ли определить ресурс пакета, чтобы другой ресурс (например, exec) активируется при изменении или обновлении пакета?
  3. Можно ли определить exec ресурс, который запускает командную строку оболочки (например, с каналами и перенаправлением) вместо команды из файловой системы?

Все вместе это кажется потрясающим.

СЛЕДОВАТЬ ЗА: Фантастические ответы! В интересах полноты (и для записи) я должен отметить следующее:

  1. Полная представляющая интерес команда оболочки: mysql_tzinfo_to_sql | mysql -u root -p password (он загружает tzinfo в базу данных MySQL для использования MySQL).
  2. Аудит /etc/tzinfo было бы бесполезно, поскольку это просто конфигурация местного часового пояса; цель состоит в том, чтобы отслеживать изменения в самих данных tzinfo (таким образом, наблюдение /usr/share/zoneinfo).
  3. Точно так же было бы неправильно смотреть содержимое, поскольку оно, скорее всего, не изменится; лучше всего было бы посмотреть время или все поскольку время файлов должно меняться после каждого обновления tzinfo.

Также Джеймс Тернбулл написал все об аудите, когда он был введен. В Справка по метапараметрам содержит краткое описание работы audit параметр.

Используйте атрибут аудита, чтобы отслеживать содержимое файла или номер версии пакета и инициировать изменение, подписавшись на ресурс пакета. Есть несколько проблем с этим, это не работает с --noop, потому что файл state.yaml обновит контрольную сумму файла md5 / версию пакета в режиме --noop. Я не уверен, что это ожидающая ошибка, так как в настоящий момент я не могу ее отследить. 

file { '/etc/tzinfo':
  audit => content,
}

exec { '/usr/bin/mysql_tzinfo_to_sql':
  subscribe => File['/etc/tzinfo'],
}

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

file { '/etc/puppet/stage/tzinfo':
  source => '/etc/tzinfo',
}

exec { '/usr/bin/mysql_tzinfo_to_sql':
  subscribe => File['/etc/tzinfo'],
}

Второй метод, конечно, не работает с пакетами, но вы избежите проблем --noop и state.yaml.

Что касается третьего вопроса, да, вы можете использовать конвейер и перенаправления (используйте заголовок и поместите команду в атрибут команды):

exec { 
  '/bin/echo foo | grep foo > /tmp/foo':
}

Да, вы сможете это сделать.

* теоретический пример кода

package{'tzinfo':
  audit  => all,
  notify => Exec['mysql_tzinfo_to_sql'],
}

exec{'mysql_tzinfo_to_sql':
  refreshonly  => true,
  command      => "bash -c '/usr/local/bin/mysql_tzinfo_to_sql >> /var/log/stuff.log'",
}

  1. Да, через мета-параметр notify. Однако я не на 100% уверен, что новая функция аудита в марионетке 2.6 вызовет уведомление, если версия пакета изменится вне контроля марионетки.

  2. Да, с refreshonly => true

  3. Да, посмотрите мой пример. Puppet запускает команды exec вне интерактивной оболочки для простоты и безопасности. Вы можете заставить марионетку использовать bash в режиме подоболочки с ключом -c, но обратите внимание на кавычки.

Я считаю, что смог заставить это работать. вот соответствующие фрагменты моего марионеточного манифеста:

file { '/usr/share/zoneinfo':
  audit => mtime,
  recurse => true,
  notify => Exec['mysql_tzinfo']
}

exec { 'mysql_tzinfo':
  refreshonly => true,
  command => 'mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql',
}

после первого запуска выполнение mysql_tzinfo пропускается. протестировано касанием / usr / share / zoneinfo / Etc / UTC, что побудило mysql_tzinfo exec запустить при следующем запуске.

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

Он не использует марионетку: поскольку мы хотим запускать установку / обновление RPM, почему бы не использовать триггер RPM? Он использует ту самую систему, которая использовалась для установки, правильно расширяя ее таким образом, для которого она была разработана.

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

Пока мы здесь для Puppet, и проблема решаема с помощью puppet, я беспокоюсь, что он использует слабую часть инструмента, чтобы плохо реагировать на условие, которое намного проще запустить с помощью инструмента, который уже находится на хосте, и инструмента в которую большинство админов на коробке должны были бы погрузиться. Извините, что предлагаю решение, выходящее за рамки обычного, но если вы будете блуждать по этому сообщению в будущем, как я, и триггер RPM является вариантом для вас, пожалуйста, рассмотрите его.