Комментарии 23
Здорово!
Вещь нужная. Давно хотел свести панели управления supervisord от нескольких проектов вместе.
простите мне возможно дилетантский вопрос...
а кроме симпатичной вебморды есть какие-то весомые доводы использовать supervisord вместо нативных systemd сервисов которые решают те же задачи да ещё и имеют шикарный notify?
Не дилетантский. Я зашёл в статью только чтобы оставить именно такой же комментарий, но вы меня опередили на 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)
больше подходит в тех случаях когда приложение обновляется средствами непрерывной интеграции
простите, но вот этого не понял, чем оно больше подходит то?
Supervisord может быть запущен не от рута
как и любой systemd сервис по желанию
а также работает на любых дистрибутивах, в том числе там где нет systemd
которые редко встречаются за пределами контейнеров и домашних извращений...
простите, но вот этого не понял, чем оно больше подходит то?
Проще конфиг написать, ну и systemd очень тяжел в текущей его форме для простых docker имаджей
Есть люди которые предпочитают использовать замену для systemd(и носят шапочки с фольгой, но всё же они есть) в своих дистрибутивах
Я к примеру использую Gentoo с OpenRC под капотом, без всяких systemd
Gentoo в продакшене? У вас там точно больше одного человека работает? Или это для пет-проектов?
systemd очень тяжел в текущей его форме для простых docker имаджей
я каким-то образом умудрился упустить выше по треду что разговор каким-то чудом переехал с нативной системы в контейнеры.. наверное на этом тред можно закрывать.
P.S.: я из тех отрицателей шапочек из фольги что даже генту используют с systemd, удобство и предсказуемость системы для меня важнее.
Ни разу не ставил Supervisord вне докер контейнера, поэтому аргументы против systemd у меня слабые
ни разу не использовал supervisord внутри докер контейнера так как считал(ю) что внутри контейнера в идеальный условиях должен быть один процесс, и сам докер "супервизит" его. а вот в легковесных lxc и chroot окружениях применять supervisord доводилось, но было это давно, теперь chroot в проде не применяется, а в lxc уже не приходится экономить пару мегобайт ОЗУ запуская его без init процесса.
А как у 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 который уже есть в системе это оверхед, а использовать две строчки конфига для отдельной приблуды которую надо ставить в систему и которая будет запускаться уже присутствующим в системе systemd это не оверхед?
нуууу... я даже не знаю что сказать.
А systemd умеет перенаправлять stdout/stderr в соответствующие логи? Напомню - условный скрипт не умеет ничего списать в логи сам, ему и не надо.
Понятно, что в systemd в данный момент много перекрывающего с supervisord, но он и вышел когда никакого systemd не было
Так а штош и не перенаправить?
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=<your program identifier> # without any quote
StandardOutput=append:/some/path
Хоть в файл, хоть в syslog...
https://github.com/systemd/systemd/pull/6599
Мониторинг Supervisord: Упрощение контроля над процессами