Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 23
Здорово!
Вещь нужная. Давно хотел свести панели управления supervisord от нескольких проектов вместе.
Не дилетантский. Я зашёл в статью только чтобы оставить именно такой же комментарий, но вы меня опередили на 3 минуты.
Supervisord написан на Python и, чаще всего, запускается всё равно через systemd. До середины 2019 года не было поддержки Python3. последний релиз был в конце 2022 года.
Supervisord может быть запущен не от рута, а также работает на любых дистрибутивах, в том числе там где нет systemd
Разрешите ввязаться с вами в дискуссию. Я, честно признаюсь, сам предпочитаю systemd и немного недолюбливаю supervisor с давних времен. Не знаю как сейчас, но раньше глючен был.
Вот нашёл в википедии страницу с дистрибутивами, на которых systemd не ставится по умолчанию. Возможно, она не полная, конечно.. Но что из этого сейчас реально используется в каком-нибудь продакшене?
Ок, на каком-нибудь роутере, наверное, systemd нет. Но и Python туда ставить тоже смысла немного.
Ну не подходит скрипт на Python для контроля приложений на уровне OS. (я Python-разработчик, если что).
Дистрибутивы без systemd: Void, Gentoo(есть вариант без systemd), Artix, Alpine(на нем чаще всего докер image делают)
Соглашусь с вашим высказыванием с силу его глючности, она есть но незначительна - глюки зачастую сейчас есть с просмотром логов и их очисткой у выключенных процессов.
Есть альтернатива Python версии супервизора - его ремейк на Go( https://pkg.go.dev/github.com/couchbase/eventing/supervisor ) но мною он не был изучен пока ещё
Ну и ничто не мешает добавить его поддержку и (возможно) поддержку управления systemd процессами
Systemd чаще используется для упровления системными службами(более низкоуровневый), а Supervisord докеризированными частями одного приложения - больше подходит в тех случаях когда приложение обновляется средствами непрерывной интеграции(CI)
простите, но вот этого не понял, чем оно больше подходит то?
Проще конфиг написать, ну и systemd очень тяжел в текущей его форме для простых docker имаджей
Есть люди которые предпочитают использовать замену для systemd(и носят шапочки с фольгой, но всё же они есть) в своих дистрибутивах
Я к примеру использую Gentoo с OpenRC под капотом, без всяких systemd
Ни разу не ставил Supervisord вне докер контейнера, поэтому аргументы против systemd у меня слабые
А как у systemd с запуском N кол-ва процессов? Нагуглил какие-то костыли. Нет такого, что файлик скопировал в контейнер и кайфуешь. Без ручного старта systemd никак, если речь о нескольких экземплярах процесса. Это самое красивое решение из того, что я нашел:
[Service]
ExecStart=/bin/sleep 600 %I
[Install]
WantedBy=multi-user.target
# systemctl start test@{1..30}.serviceСам мечтаю избавиться от supervisor, заодно образ похудеет без питона.
есть какие-то весомые доводы использовать supervisord вместо нативных systemd сервисов которые решают те же задачи
Ну городить systemd обвязку для какого нить условного скрипта на nodejs/python/php с контролем его работы это лютый оверхед как по мне.
А systemd умеет перенаправлять stdout/stderr в соответствующие логи? Напомню - условный скрипт не умеет ничего списать в логи сам, ему и не надо.
Понятно, что в systemd в данный момент много перекрывающего с supervisord, но он и вышел когда никакого systemd не было
Так а штош и не перенаправить?
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=<your program identifier> # without any quote
StandardOutput=append:/some/path
Хоть в файл, хоть в syslog...
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мониторинг Supervisord: Упрощение контроля над процессами