task queue? task executor?

«Несколько раз в день» или «в ответ на действия пользователя»? Непонятно немного, это интерактивное-то что-то или по расписанию? Или надо запускать что-то интерактивное для пользователя по расписанию?

Псевдо-интерактивное т.к. пользователь не ждет окончания задачи, а делает другие пользовательские дела. Расписания нет. «Несколько раз в день» - написал для понимания масштабов нагрузки. Ну т.е. нагрузки почти нет. Параллельное выполнение задач тоже не особенно нужно.

Т.е. штука, грубо говоря веб-морда, в которой пользователь натыкивает задачи, задачи встают в очередь и там их бекенд как-то молотит, а результат куда-то отправляет почтой. Т.е. по-компонетно это 1. морда, 2. сервер очередей (rabbitmq?), 3. какой-то или какие-то приложения, которые выполняют задания из очереди

Выглядит так, как будто придется строить велосипед.

Скорее это сервер очередей куда задания прилетают через вебовский API и какое-то приложение которое выполняет эти задания и обновляет состояние соответствующих задач.

https://vicerveza.homeunix.net/~viric/soft/ts/

Создай каталог, натрави на него inotify чтобы выполнял то что туда закинуто. По желанию айнотифай можно заменить на крон раз в пять минут.

Если максимально просто, то достаточно будет взять Jenkins, если же нужен серьёзный заточенный под такой класс задач инструмент, то следует взять Apache Airflow.

/thread

Slurm, pbs pro, sge (son of grid engine). Частично xcat2.

Первые три, это кластерные планировщики (менеджеры очередей). Последняя, это то, что было до ансибл и Солт стэк-а.

Спасибо, выглядит обещающе.

Разве статус задач не будет теряться где-то в недрах системы? В принципе работать будет, но преимуществ по сравнению с наколенной поделкой на питоне я не вижу.

Спасибо за названия. Думаю Apache Airflow это таки оверкилл для моего случая, а Jenkins можно попробовать пощупать.

Ну не, этих всех товарищей я знаю не понаслышке. Это немного атомной бомбой по инфузориям в моем случае.