претензии к тому что ради одной системы инциализации нужно поддерживать какой-то протокол и ваще париться с его реализацией

Там протокол это просто строку послать на юникс сокет

Там протокол это просто строку послать на юникс сокет

да, вопрос в формате строки

Уууууу. Чем вам абстрактные сокеты не угодили?

это НЕ абстрактные сокеты

там нужно какие-то креденшиалы делать

это то как делает хелфчеки системд

авторизация приложения по сокету

и только он

наборы команд

и пр.

у докера свое, у монита свое

Мсье, я это с нуля на сях писал, реально два десятка строк кода и фиксированные сообщения

там при чем тут сколько строк

1. это НЕ портабельно

это то как делает хелфчеки системд

= как скоро будут делать везде и все.

2. это требует изменение приложения

= как скоро будут делать везде и все.

никто так нигде делать не будет

кроме системд

с которого все съедут еще раз через 5 лет

на что нибудь другое

и вообще с линукса надеюсь, но это оффтопик

Ой какой срач я тут развел 😂

вы вот серьезно, скажите, сколько потребуется усилий протолкнуть такой патч в постгрес?

а в проприетарную аппу?

Так никто не заставляет использовать там notify. С другой стороны гораздо проще использовать notify в своем приложении, чем городить велосипедную обвязку на случай если его, скажем, oom manager убъет нахрен.

То что это сложно сунуть в проприетарщину нихрена не означает того что это говенное решение. Для кучи мелких демонов это идеальный способ отслеживания.

это сложно всунуть КУДА УГОДНО, если авторам ЧЕГО УГОДНО срать на системд и его видение мира

в отличии от нормальых способов мониторинга

это прям вообще базовые понятия разделени слоев абстракций

Слушать stdout - не нормальный способ мониторинга

нижний слой не должен знать ничего о верхнем

а тут классическая дырявая абстракция

так на пхп даже не пишут

Слушать stdout - не нормальный способ мониторинга

слушать стдаут СПЕЦИАЛЬНОГО скриптика

который написан для системд

и является связующим звеном между системд и программой (у каждой из который свой набор для хелфчекинга)

более того, в каждой инсталяции будут тоже свои требования к хелфчекингу

у кого то что порт 5432 слушается

а кто-то проверять будет еще наличи промигрированной схемы и данных, скажем

и все это хелфчекинг с точки зрения сервиса

и все это элементарно и понятно делается, если апи нормальный

а с системд — хренушки

Я могу написать тут кучу всего на тему того что если порт не слушается, то это должно отрабатываться на уровне самого приложения и выливаться, скажем, в выход со статусом ошибки и всеми проистекающими. И вообще все проверки состояния приложения - головная боль самого приложения. Но мне лень. Помните только что на свете работает очень много софта на честном слове и без всякого рестарта снаружи если что. К слову о Постгресе.

Но вы всегда можете поставить сторонний супервизор или написать свой внутри приложения. Мы все немного любим делать троллейбус из буханки)

порт ВСЕГДА не слушается после старта приложения и начинает слушаться только через какое-то время после старта

Но вы всегда можете поставить сторонний супервизор или написать свой внутри приложения. Мы все немного любим делать троллейбус из буханки)

благо даже гоферы из докера в состоянии спроектировать нормальный хелфчеки

порт ВСЕГДА не слушается после старта приложения и начинает слушаться только через какое-то время после старта

Если что-то пошло не так, то приложение в этом конкретном случае должно сделать сеппуку. Или его автор, на выбор.

дело не в том, что что то пошло не так

дело в том, что супервизору нужно знать когда аппа готова к работе

вот и все

Мне позиция Джейка ближе ))

и вообще с линукса надеюсь, но это оффтопик

так некуда банально, остальное все вообще говно

дело в том, что супервизору нужно знать когда аппа готова к работе

хелсчеки на уровне супервизора -- кмк не самая лучшая идея

Да речь не столько о хелсчеках, как о способе оповестить супервизор что инициализация завершена, боевой режим включен, можно зависимости стартовать. Watchdog в systemd отдельно включается, просто пользует тот же сокет.

хелсчеки хорошо

меня радует как это в докере запилили

щас бы еще докеркомпоуз подтянулся

и было бы вообще шоколадно

Да речь не столько о хелсчеках, как о способе оповестить супервизор что инициализация завершена, боевой режим включен, можно зависимости стартовать. Watchdog в systemd отдельно включается, просто пользует тот же сокет.

но зачем это на уровне работы с системными службами?

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

А у кого докер используется для продакшена и для девелопмента/стеджа?

Димас, иди спать :D

сколько можно то ))))

Как вы работаете с параметрами, типа там подключение к базе, путь к исходникам?

Да у меня тут работы непочатый край ))

ENV не очень вариант?

устанавливать через окружение

У меня в ансибле порядка 50ти переменных

Для приложения

исходники в контейнере, конфигурация в окружении

Чем вы все это устанавливаете?

Т.е. если ансибл то тут все ясно, просто генерим конфиг. А вот с докером не совсем.

мы в рамках амазона какую-то тамошнюю дрянь ))

хотя речь уже не про амазон? :D

отпустило?

Во, щас глянул — в другом у меня 80 переменных

или 100

Хер знает, на глаз прикинул

И все они должны быть разные для каждого из окружений

Какой здесь best practice?