Ну так то любой супервизор может упасть

Здесь докер и берёт на себя сложность по части безопасности в контексте системы. Отчасти для этого он и создан.

РЕчь о докере или о pm2?

Ну баги есть везде

Что ж теперь

То бишь, хотите сказать, что самый надёжный способ — демонизация средствами гостевой системы?

Ммм, ну вот кто перезапустить штатный супервизор?

upstart какой нибудь

ну да

само собой

но в норммальной распределенной системе это не так страшно

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

да вот буквально сегодня. упало все 8 инстансов приложения. крутились через pm2

pm2 вел себя вооьще не адекватно

постоянно делал spawn себя

думаю перейти на systemd или че там модно после upstart

Может проблема была в приложении?)

/stat@comstatbot

.

А кто-нибудь использует в наше время json-rpc?

Да

@abc а почему не используете кластеризацию nodejs ?

да нет, сколько ядер, столько и растет

@Klon https://nodejs.org/dist/latest-v6.x/docs/api/cluster.html

я про эту реализацию собственно - в чем пикус кластеризации средствами pm2 ?

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

Это становится болью, когда надо хендлить сокеты

Вернее, когда надо хендлить либы типа socket.io

А в чем конкретно боль?

Если при авторизации socket.io хотя бы один из http-запросов уйдет не в тот же тред, в котором он был до этого - то пользователь никогда не сможет проапгрейдится до ws коннекшна

Для этого был придуман sticky-session

Который тоже костыль, на самом деле

Хм, ну это к кластеру не имеет отношения

если нужны sticky sessions, то они нужны при любом раскладе

если нужны sticky sessions, то они нужны при любом раскладе

Не совсем понял сути сказанного

Эта проблема не связана с кластером никак

Короче суть в том, что для нормальной реализации стики сейшнс нужно, что бы каждый инстанс слушал свой сетевой интерфейс

В примере из документации они все юзают один и тот же порт - 8000

Лучше иметь сторонний балансировщик нагрузок

это ничего не меняет

Так как физических машин может быть например больше, чем одна

И тогда стики сейшн вкрученный силами ноды внутрь кластера станет абсолютно бесполезным

Потому что путь до машины будет все равно определять балансировщик

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

Это естественно

зачем?)

Неа. И даже про брекзит не было

Да, кстати

вы название чата видели?

Вобще да, спамить не надо

*флудить

для такого есть @flood

Сорян за опечатку)

там уже обсудили

Да запросто. Крутить его на компе без шифрований не подлюченному к инету

это верно

смотря для чего

А так же для всего того, у чего нет проксей

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

Вобще интерсено - особо альтернатив пока что для soocket.io я не знаю, есть куча всяких других либ, но они немногим лучше, а зачастую намного хуже

даже в engine.io многого нет

ну нет

не, веб сокеты только проблемы создают

над вебсокетами придется написать много своего. и в итоге получится сокет.айо

ничего лучше у нас нет

я знаю что он говно

лонг поллинг

просто и надежно

)

почему же?

ну да

ну естественно, но задержки мнимальны

для большинства задач достаточно

плюсую

балансировка, например

Вечер в домен, всем фарту девелоперского :) Тут есть специалисты по настройке instance в Amazon EC2? Хочется настроить ограничения чтоб за t2.mirco - не выодил по процесорному времени.

пропуск сообщений при отключении

не особо

решается, но из этих решений еще куча проблема

в целом это stateless vs stateful