Я реализую программу, которая работает 24/7. Он непрерывно выполняет задачи каждые 15 секунд или около того, однако для выполнения некоторых задач может потребоваться произвольное время (более 15 секунд), и не рекомендуется выполнять другие операции на том же работнике, когда он выполняет задачу (некоторые задачи включают развертывание и устранение экземпляров виртуальных машин). Выполнение этого с помощью cronjob без сохранения состояния потребует сложной логики блокировок, которая вряд ли будет масштабируема, поэтому это не вариант.
Программа имеет сложное и тяжелое состояние, в основном это ядро или большой кластер, который выполняет планирование заданий, проверку состояния, перезапуск неработающих заданий и обновление конечных результатов, поэтому идея состоит в том, чтобы она всегда работала как ядро система.
В настоящее время все программное обеспечение реализовано в виде подкласса многопоточности. При этом все аспекты параллелизма уже решены.
Конечной точкой системы является ОЧЕНЬ ПРОСТОЙ скрипт, который считывает конфиги из аргументов и файлов и инициализирует поточный класс с помощью ʻem. После этого он запускает метод start () и ждет бесконечно, перезапуская основной класс, если он каким-либо образом падает.
Что я хочу сделать, это реализовать этот простой класс как хорошо управляемый демон-процесс (сейчас я использую nohup и &, чтобы добиться цели) с помощью start / stop И простого состояния метод, который печатает информацию о запущенных заданиях, размере текущего кластера и т. д., весь простой текст. Сейчас у меня есть прослушиватель сигналов, который эмулирует stop () и status (), изящно останавливая потоки (при необходимости) и печатая вывод в файл.
Удаленный кластер и его логика связи / расписания - это пользовательская реализация, использующая Pyro4 , поэтому одним из вариантов будет регистрация самого основного процесса в Pyro Daemon, поэтому одной из альтернатив будет регистрация демонизируемого Класс сам и использовать некоторый пользовательский код Python для подключения к нему и получить статус, однако, я думаю, что это излишне и полагается на Pyro Daemon, который добавляет в систему ненужные точки отказа.
Я столкнулся с несколькими библиотеками, которые утверждают, что создают правильных демонов:
Эти классы выглядят достаточно надежными и простыми, чтобы соответствовать моим текущим потребностям (я пока не выяснил, как сделать составной частью status (), однако это должно быть легко). Есть ли другая библиотека, которая делает это более надежным способом? сейчас у меня нет времени тратить проверки стабильности библиотеки демонов, поэтому, даже если она основана на мнениях, я бы хотел узнать ваши мысли и практический опыт по этому вопросу.
Все это касается демонов linux, однако, есть ли какой-нибудь ПРОСТОЙ класс, который обрабатывает службы Windows, а также демоны linux? Моя текущая программа предназначена только для Linux из-за других внешних ограничений, но в будущем было бы неплохо избежать программирования двух разных веток.
Для моего текущего проекта мне не нужно ничего, кроме вышеприведенного, однако, думая о будущем, я хотел бы иметь возможность ОТПРАВИТЬ некоторую информацию С терминала на демонов. Ничего сложного, только команды с простой строковой / числовой информацией в качестве аргументов.
Например, было бы неплохо иметь функцию "reload_config", которая позволяет мне передавать новое местоположение файла конфигурации из консоли. Прямо сейчас, чтобы перезагрузить конфигурацию, я изменяю конфигурационный файл CURRENT и приказываю процессу прочитать его снова, используя сигнал. Это сокращает возможные функции, которые могут быть реализованы с использованием этого (вы можете использовать временный файл в известном месте, чтобы сохранить команду и заставить ее прочитать ее, но это тоже не чистое решение)
Насколько я знаю, единственными правильными способами достижения этого (помимо использования файла связи) являются:
- TCP-сокет прослушивания в потоке, который слушает команды, отправленные с помощью специального клиента. Это вводит проблемы безопасности и вынуждает вас создавать некоторую нехватку грамматики, которая позволяет вам представлять ваши команды наиболее эффективным способом, и добавляет проблемы связи.
- Простой веб-сервер на Python, действующий как посредник с заказами: клиент публикует на веб-сервере, и поток получает оттуда. Теперь кажется, что с безопасностью легче справиться, чем в предыдущем случае (https избавляет от необходимости заботиться о шифровальных атаках и атаках типа «человек посередине»), но это все еще проблема.
- Использование Pyro4 для удаленной загрузки класса при необходимости от управляющих клиентов, что мне кажется слишком грязным.
- Использование «коммуникационного файла» для получения / отправки сложных данных процессу. Это выглядит грязно и совершенно не соответствует современному уровню техники.
** ПРИМЕЧАНИЕ. В настоящее время я использую logging.Logger для прямого входа в файл. Может ли это быть проблемой? Насколько я знаю (и думаю) это не так, но вы никогда не знаете ...
Кроме того, согласно первому ответу post , "systemd делает многие демоны устаревшими" , я не очень привык к systemd (не хотел переходить на современные ОС, пока я не смог больше его задерживать), однако, с помощью этого метода я могу просто делать то, что делаю сейчас: ловить и правильно обрабатывать сигналы закрытия и автоматически запускать / убивать скрипт из systemd, что, похоже, не хватит.
Хотя, похоже, что если я не реализую более сложные клиент / серверы, я не смогу отправлять команды с аргументами своим службам, я ошибаюсь? Идеальная ситуация - запускать такие команды:
systemctl custom_command python_service custom_argument
хотя я не думаю, что systemd поддерживает что-то подобное, я не прав?
В любом случае, для решения основных вопросов этих возможностей будет достаточно:
systemctl start python_service
systemctl stop python_service
systemctl restart python_service
systemctl reload python_service
systemctl status python_service