Могу ли я отправлять сценарии проверки от мастера к клиентам и поддерживать бит выполнения с помощью Icinga2?
Я считаю, что я успешно настроил Icinga 2 в Debian 9 (Stretch), используя стандартные пакеты Debian с режимом "Top Down Config Sync", как описано в документации Icinga.
Я установил на клиенты icinga2 и monitor-plugins-basic и могу добавлять удаленные проверки, используя check_apt и т.д. Мне даже удалось добавить свой собственный CheckCommands через механизм "глобальных шаблонов", которые автоматически отправляются клиентам и заканчиваются в /var/lib/icinga2/api/zones/global-templates/_etc/
У меня есть несколько моих собственных скриптов проверки (написанных на shell и Python), которые я также хотел бы запустить. Я положил их в /etc/icinga2/zones.d/global-templates тоже, и они также отправляются клиентам. Тем не менее, они теряют свой бит выполнения по пути, поэтому я вынужден явно предоставлять интерпретатор при запуске. Это работает, но немного уродливо.
Есть ли лучший способ отправить мои сценарии проверки от мастера к клиентам? Если нет, есть ли способ сохранить бит выполнения с помощью этого метода?
1 ответ
Не делай этого. Синхронизация конфигурации кластера только для простых файлов конфигурации.
В то время как скрипту может понадобиться только исполняемый бит, двоичные файлы с другой архитектурой и библиотечными зависимостями представляют собой большую проблему.
Путь к синхронизированной конфигурации также может измениться, надежного способа зависеть от него нет.
Развертывание таких сценариев может помочь с инструментами управления (жизненным циклом), такими как Puppet, Ansible и т. Д. Устранить зависимости сценариев можно, полностью создав пакет из ваших сценариев, доступных в репозитории программного обеспечения.
В моей предыдущей работе у меня был центральный репозиторий плагинов, который регулярно проверялся клиентами.