Ведь тебе никто не сказал, что мифический «full stack» должен знать не только front и back, но и уметь настроить сервер, установить нужные пакеты, задеплоить и собрать проект.
То чувство, когда тебя предали… Вытесняя тяжелые мысли ты стал искать статьи в интернете и наткнулся на этот текст.
Статья рассчитана на новичков. Просьба убрать от экрана слабонервных беременных админов.
А теперь серьезно — где захостить небольшой «домашний» NodeJS-проект? Собственного сервера (и тем более админа) — у вас нет. Heroku, Nodejitsu и другие варианты — слишком дорого. Решение:
1. Арендуем любой VDS-хостинг, желательно с шаблоном CentOS 6.
2. Подключаемся к нему по SSH. Если ваш хостинг-провайдер установил ISPmanager, то можно воспользоваться веб Shell-клиентом (в разделе «Инструменты»).
3. Вводим команду yum repolist и убеждаемся, что пакет NodeJS доступен в репозитории EPEL. Если его нет, то добавляем:
rpm -ivh http://epel.mirror.net.in/epel/6/i386/epel-release-6-8.noarch.rpm
yum install npm --enablerepo=epel
4. Чтобы проверить установку, введи команду node и какой-нибудь hello_world-код
[root@habr ~]# node
> console.log("Hello world")
Hello world
undefined
Хорошо, установка прошла успешно. Дважды нажмем «Ctrl + C».
5. Теперь давай попробуем запустить не просто скрипт, а веб-приложение. Создай папку (например /sample) и загрузи в нее test.js любым удобным способом (vim, git, ISP, FTP) со следующим кодом:
http = require('http');
http.createServer(function (req, res) {
res.writeHead(200, {'Content-Type': 'text/plain'});
res.end('Hello World!');
}).listen(3000);
console.log('Server running at port 3000');
6. Теперь запустим код используя Node-команду:
[root@habr sample]# node test.js
Server running at port 3000
7. Программа работает на порту 3000. Открой браузер и убедитесь, что по адресу http://IPaddress:3000 ты получаешь нужную страницу. Если страница недоступна, то отключи firewall (Iptables) на сервере:
[root@habr sample]# service iptables stop
[root@habr sample]# chkconfig iptables off
Теперь все должно работать отлично. Однако при каких-либо сбоях, сайт не сможет восстановить работу самостоятельно. Чтобы приложение «пробуждалось» после падения, используй демонизатор forever.
8. Установи пакетный менеджер npm:
wget https://npmjs.org/install.sh
sh install.sh
и сразу же пакет forever:
[root@habr sample]# npm install forever -g
9. Запустим тестовое приложение с помощью forever
[root@habr sample]# forever start test.js
Список запущенных через forever приложений можно получить командой forever list. Можно перезапускать и останавливать приложения по их ID:
[root@habr sample]# forever restart 1
[root@habr sample]# forever stop 1
[root@habr sample]# forever stopall
[root@habr sample]# forever restartall
Используй опцию -w для автоматического рестарта после изменения файлов (чтобы было как в твоем любимом supervisor'е):
[root@habr sample]# forever start test.js -w
10. Чтобы приложение работало по адресу site.ru, а не по site.ru:3000 нужно слушать порт 80 в своем js-файле:
listen(80)
Если у тебя есть ISPmanager, то скорее всего ты получили VDS с установленным Apache. Отключи его в разделе Система-Службы, чтобы Node могла спокойно слушать 80 порт.
На этом пожалуй все. Тебе еще многое предстоит узнать — о том, насколько безумно отключать iptables, почему плохо запускать приложения из под рута, зачем нужен nginx если Node и сама умеет отдавать статику, чем плохи глобальные npm-плагины и почему тебе не нужен forever. Но это всё потом. А сейчас быстрей беги менять свой статус в Фейсбуке — вместо
Комментарии (77)
Nexen2
15.04.2016 13:58Я это увидел так — найми за $## на день админа и пусть он все сделает.
Кстати нет пункта про включить файервол…
Если что — я backend разраб, и да, для меня статья тоже выглядит как минимум на 50% состоящей из сарказма.
Sirion
15.04.2016 14:47+2Ох, выйди эта статья на полгода пораньше, сэкономила бы мне два-три дня времени. Но всё равно спасибо.
wert_lex
15.04.2016 15:03+3Ну все же nginx стоило бы поставить перед приложением в качестве фронтенд-сервера.
Причин — множество. Начиная с хостинга статики, который очень вероятно случится, заканчивая тем, что даже pet-project лучше под рутом на 80 порту не хостить и доверится nginx.
Leopotam
15.04.2016 15:09+2forever же вроде как давно умер, давно вместо него гоняют pm2, например.
ChALkeRx
15.04.2016 15:34+1Кхм. Вот честно, есть же systemd. Он, в отличии от всего вышеперечисленного, гарантирует то, что сервис будет перезапущен при сбое.
Не понимаю, зачем городить ещё один демон инициализации от пользователя?Leopotam
15.04.2016 15:39+1А давайте тогда все затолкаем туда, во славу Поттеринга! :)
Leopotam
15.04.2016 15:47Если по делу, то попробуйте задействовать systemd для этой цели на дистрибах где используется что-то иное, либо на osx / win. pm2 такое умеет, причем единообразно.
ChALkeRx
15.04.2016 15:57Знаете, вообще-то люди обычно выбирают систему под задачу. Случай osx / win на боевых серверах — скорее редкость.
Leopotam
15.04.2016 16:07+3Знаете, это не так, система может быть выбрана любая, а не одна единственная расово верная. Ну и вообще-то люди советуют способ демонизации ориентируясь на целевую систему, а не предлагая единственный платформозависимый вариант, ориентируясь только на свой опыт применения.
У меня вот есть домашний хостинг на osx (macmini), предлагаете снести и поставить нечто на systemd? Я вот не согласен с этим. Аналогично, люди иногда вынуждены гонять ноду под винду, они теперь должны рыдать от отсутствия возможности работы в виде сервиса без детища Поттеринга? Не так ведь, верно? Всегда выбирается тулза под задачу, а не задача под тулзу, причем ОС может быть любой.ChALkeRx
15.04.2016 18:07-3> У меня вот есть домашний хостинг на osx (macmini), предлагаете снести и поставить нечто на systemd? Я вот не согласен с этим.
Вы только что показали, что вы умеете пользоваться соломенным чучелом. Но при чём тут это? Нет, не предлагаю я вам снести ваш сервер, успокойтесь.
Я говорю, что в большинстве случаев гораздо логичнее использовать системные средства управления процессами, чем городить поверх них ещё один инструмент.
Люди, которые деплоят свой сервер — обычно делают это под задачу и на специально поднятой системе. Поэтому в рекомендациях «по умолчанию» следует рассчитывать на это, а не на домашний хостинг на мак мини.
И да, вы так поминаете Поттеринга, как будто он лично пришёл к вам и испортил вам звук и инит =).Leopotam
15.04.2016 18:18Вы только что показали, что вы умеете пользоваться соломенным чучелом.
Ну а вы показали, что не умеете читать посты полностью. Даже в мире линукса не systemd единым жизнь теплится.
Я говорю, что в большинстве случаев гораздо логичнее использовать системные средства управления процессами, чем городить поверх них ещё один инструмент.
Это вы говорите с точки зрения красноглазого админа, оставшегося без работы по постоянному подпиливаю слетевших скриптов автостарта сервисов после апдейта.
Люди, которые деплоят свой сервер — обычно делают это под задачу и на специально поднятой системе.
Люди делают на том, на чем хотят, хоть на малине/банане — уже говорил об этом, но судя по всему, впустую. Каждый сходит с ума по-своему.
вы так поминаете Поттеринга
Не поверите, но мне глубоко все-равно, если говорить про драму systemd for everything, ибо все линуксоподобное не является моей основной системой, но я как девелопер ратую за прозрачное и кроссплатформенное решение, позволяющее разворачивать приложение независимо от initd/upstart/systemd/launchd/whatever на любой платформе без перерывания тонны манов по правильной готовке нужной системы под мое приложение. И я буду уверен, что все будет развернуто правильно.ChALkeRx
15.04.2016 18:31-3> Ну а вы показали, что не умеете читать посты полностью.
Хм?
> Даже в мире линукса не systemd единым жизнь теплится.
Ещё раз — это нерелевантно. Важно только то, что он присутствует в подавляющем большинстве дистрибутивов, на которых деплоят сервера.
> Это вы говорите с точки зрения красноглазого админа, оставшегося без работы по постоянному подпиливаю слетевших скриптов автостарта сервисов после апдейта.
Хм? Я вас тут не совсем понял, если честно. Можете привести примеры слетевших скриптов, или этот пассаж исключительно продукт фантазии?
> Не поверите, но мне глубоко все-равно, если говорить про драму systemd for everything
> А давайте тогда все затолкаем туда, во славу Поттеринга! :)
Ну-ну.
> И я буду уверен, что все будет развернуто правильно.
Вы можете дать гарантию того, что ваш сервис перезапустится при программном сбое, допустим, вашего сервиса? При сбое Node.js? При сбое вашего pm2? При сбое системы?Leopotam
15.04.2016 18:44-1Хм?
И следующую цитату меня прочитать — это как раз ответ
Ещё раз — это нерелевантно.
Еще раз — это исключительно ваше мнение, «продукт фантазии» (с). Еще есть требования заказчика, нарушение которых означает неполучение контракта, так понятнее?
Можете привести примеры слетевших скриптов
Конкретные косяки не могу (не входило в мои задачи), для этого был нанят отдельный админ по настройке продакшн-впс-ок. После первоначальной настройки деплоеры были вынуждены постоянно привлекать его к дополнительным фиксам своей работы по настройке работы сервисов (nodejs) на 8-ом дебиане. Продактоунеру надоело, админ был уволен, после чего все прекрасно стабилизировалось на pm2, причем как на дев/тест-окружении, так и в продакшне. Единая система развертывания, никакой мороки даже при миграции между хост-ОС.
что ваш сервис перезапустится при программном сбое, допустим, вашего сервиса?
Верно, есть отлов необработанного исключения + реакция. А вот все остальное — это специфично для конкретной ОС и конфигурации железа.ChALkeRx
15.04.2016 19:05+1> Верно, есть отлов необработанного исключения + реакция. А вот все остальное — это специфично для конкретной ОС и конфигурации железа.
Смотрите. Речь вот о чём — systemd даёт вам непрерывную цепочку процессов с гарантией перезапуска при сбое.
Если упадёт/повиснет сам systemd или ядро — система перезапустится аппаратным таймером. Если упадёт или повиснет ваше приложение — его перезапустит systemd. Это более глубоко раскрыто по ссылке, которую я вам уже привёл, но повторю ещё раз: http://0pointer.de/blog/projects/watchdog.html
В случае с forever/pm2, если оно падает — всё пропало. См. https://github.com/Unitech/pm2/issues/1540, например.Leopotam
15.04.2016 19:09+1Так поймите, нельзя привязываться к одной системе запуска, хостить в итоге можно хоть на винде в asure, хоть на arduino, причем без привлечения специалистов на настройку / проверку в будущем правильности настройки. Я понимаю, что вы очень любите исключительно systemd и исключительно линукс, но упорно не хотите услышать меня.
ChALkeRx
15.04.2016 19:18> Я понимаю, что вы очень любите исключительно systemd и исключительно линукс, но упорно не хотите услышать меня.
Я вас отлично понимаю, и вижу ваши сообщения. Честно, нигде не хотел вас обидеть или сказать, что вы должны немеденно выкинуть ваш pm2.
А теперь и вы меня выслушайте: ещё раз, в данном топике я говорю про то, что следует рекомендовать людям, которые выбирают способ (пере)запуска процесса своего сервера. И в большинстве случаев — у них в системе уже есть инструменты, которые разработаны ровно для этого.
Это не значит, что все остальные сетапы — плохие и негодные (вы почему-то опровергаете это, хотя я такого не говорил, и исходя из этого делаете вывод, что я неправ — отсюда и упоминание https://ru.wikipedia.org/wiki/Чучело_(логическая_уловка) с моей стороны ).
Это значит, что в хорошем мануале должно быть сказано — по возможности, используйте системные средства для запуска приложений на сервере, а не тащите в систему ещё одну потенциальную точку отказа.Leopotam
15.04.2016 19:46у них в системе уже есть инструменты, которые разработаны ровно для этого.
Так и не поняли, что я написал. Хорошо, перефразирую — вы готовы за бесплатно настраивать проект для запуска на windows/osx/linux/freebsd/raspbian? Даже не за бесплатно, а за одну цену — настройку одной ОС? Каждое тулза, запиленная под свою ОС — это отдельный оплачиваемый специалист, съевший не одну собаку на конкретной тулзе. Так понятнее? forever/pm2 помогают уменьшить стоимость саппорта продукта в силу своей простоты — внутренняя специфическая кухня каждой ОС не будет касаться деплоера — ему достаточно накатить универсальные скрипты и проверить базовый функционал системы. Если что-то не работает, то это нечто, не попадающее в его компетенцию.ChALkeRx
15.04.2016 20:24-1А. Вам нужна переносимость боевых настроек вашей серверной части между различными операционными системами? Тогда понятно.
Но, опять же — это весьма нестандартный вариант, а речь про то, что должен рекомендовать мануал для более распространённого случая.Leopotam
15.04.2016 20:28Вообще-то это самый распространенный вариант, для чего и была придумана нода как очередной слой абстракции от конкретной ОС и окружения для быстрой разработки. Туда же все языки общего назначения с высоким уровнем абстракции, как java / c#. Write once, run everywhere. Мне в итоге все-равно, на чем работает сервер, я просто делаю установку локальных пакетов через npm + установку глобального pm2 + регистрацию приложения в pm2 + сейв конфига и запуск — все, оно шевелится. win/lin/osx/фря — без разницы.
ChALkeRx
15.04.2016 21:05Заметьте — не «серверной части», а «боевых настроек серверной части». То есть не самого приложения (которое переносимо), а настроек его разворачивания на сервере.
> Вообще-то это самый распространенный вариант
Я правильно понимаю, что вы утверждаете, что большая часть серверных приложений на Node.js (а при разговоре о systemd/forever/pm2 речь обычно про сервера идёт) деплоится на значительно различающийся набор операционных систем _одновременно_? Под значительно различающимся я имею ввиду комбинацию linux+windows или linux+osx, например, а не redhat+debian.
Если я вас правильно понял — то не соглашусь, пока не увижу статистики, доказывающей это.
Если я вас понял неправильно — проясните, пожалуйста.Leopotam
15.04.2016 21:25Господи, жесть-то какая.
я: нам нужно разворачивать на несколько ОС, те привязываться нельзя к одной из них.
вы: большинство систем с systemd, значит systemd.
я: но нам надо…
вы: херня, нерепрезентативно, нужно юзать системные тулзы.
я: но мы не можем держать в штате на постоянной основе админа под каждую ОС.
вы: херня, конфиги в systemd простые.
я: но не везде есть systemd, вот, винда у нас есть…
вы: херня, большинство систем на systemd. и админу надо заплатить копеечку, чем юзать сторонние тулзы, потому что у меня такой опыт.
я: а вот у меня опыт другой…
вы: херня, нерепрезентативно.
я: но вот у нас все работает не падает…
вы: херня, ноду можно уронить так что никто не узнает, а вот systemd узнает!
я: ну если что-то упадет, у нас есть обработка этого, а всякое нестабильное мы не юзаем.
вы: херня, можно уронить, у меня такой опыт, а опыт других нерепрезентативен.
я: нас устроило.
вы: херня, дока должна быть универсальна для начинающих, поэтому systemd.
я: но может использовать тулзы, которые работают везде, а не только где есть systemd…
вы: ааа, так вам надо несколько платформ? это нерепрезентативно, у меня такой опыт.
я: (бл##ь, об этом было сказано с самого начала...). Нам не важно что юзать, главное, чтобы работало прозрачно и без проблем и без привязки к платформе.
вы: херня, вы не можете такое сделать, нужен systemd, только он может поймать падение всей системы.
я: (чо? а причем тут это?!) ну так мы логируем это и делаем рестарт ноды.
вы: херня, вы не правильно делаете.
я: ??? Нууу, ок, завершаем ноду с фиксацией ошибки в логе и еще пары минорных действий + выходим — pm2 / forever рестартует.
вы: а вот вы не говорили что так делаете!
я: (бл##ь, а где я говорил, что я делаю иначе?)
вы: а вот вы еще утверждаете, что большинство приложений nodejs деплоится на разные сервера…
я: (полный п… Технические требования одного проекта резко стали интерполированы на весь мир...)
и тд.
И в каждой новой фразе градус неадекватности, интерполяции чужих косяков, ошибок на нашу реализацию абсолютно неизвестного для оппонента проекта повышается.
Нет, я не любитель pm2, нет, я не считаю его идеалом. Будет другая кроссплатформенная тулза, будем юзать ее. А любители systemd реально покусаны тем, кого нельзя называть — везде им кажется, что их ущемляют.ChALkeRx
15.04.2016 21:28Вы в который раз используете логические уловки, чтобы приписать мне то, чего я не говорил.
Leopotam
15.04.2016 21:39-1Это не логические уловки, это краткое содержание комментов к статье. Желающие могут найти любой кусок «диалога».
ChALkeRx
15.04.2016 21:50-1Ну хорошо, ткну пальцем в пару мест почти наугад.
> вы: ааа, так вам надо несколько платформ? это нерепрезентативно, у меня такой опыт.
Тут я, например, вообще не вижу связанного утверждения. Что значит — «несколько платформ нерепрезентативно»? Где конкретно я такое сказал?
> вы: херня, можно уронить, у меня такой опыт, а опыт других нерепрезентативен.
Я такой фразы не писал нигде. Покажите, а? Я писал, что отсутствие у вас проблем в прошлом не гарантирует отсутствия проблем в будущем, особенно, когда у других проблемы возникали и багрепортов с падением всего намертво — гора. А вот наличие проблем в прошлом — повод задуматься и сделать надёжнее.
> вы: а вот вы еще утверждаете, что большинство приложений nodejs деплоится на разные сервера…
> я: (полный п… Технические требования одного проекта резко стали интерполированы на весь мир...)
А вот тут было не так, а ровно наоборот.
В https://habrahabr.ru/post/281705/#comment_8855831 я сказал, что случай одновременного деплоя в рамках одной компании серверной части на разные операционные системы (не путать с разными дистрибутивами) — достаточно редкий, чтобы учитывать его в статье для новичков.
В https://habrahabr.ru/post/281705/#comment_8855849 вы сказали, что это самый распространённый вариант.
В https://habrahabr.ru/post/281705/#comment_8855881 я с этим не согласился.
ChALkeRx
15.04.2016 19:11+1> отлов необработанного исключения + реакция
Учтите, что отлов необработанного исключения — не решение. Это не даёт вам никаких гарантий.
Кроме этого, есть достаточно способов выстрелить себе в ногу и уронить сам Node.js, в обход этого обработчика.
И да, необработанное исключение всегда должно завершать работу текущего процесса (однако можно запустить другой). Ни в коем случае не продолжайте работу в том же самом процессе. Это подробно описано в документации.Leopotam
15.04.2016 19:17отлов необработанного исключения — не решение.
Это опять имха. В нашем случае — вполне себе решение. С сообщением куда надо и рестартом процесса.
>> Ни в коем случае не продолжайте работу в том же самом процессе.
А кто сказал, что я продолжаю? Отработка определенных действий и шатдаун, разумеется. И да, документацию я читал.ChALkeRx
15.04.2016 19:23Это не имха. В куче случаев Node.js валится в обход отлова необработанного исключения.
ChALkeRx
15.04.2016 19:28> Это опять имха. В нашем случае — вполне себе решение. С сообщением куда надо и рестартом процесса.
Кстати, спасибо за замечание, оно дельное. Я думаю, стоит вписать в документацию, что то, что делаете вы — ненадёжно. Чтобы не было вопросов.
> А кто сказал, что я продолжаю? Отработка определенных действий и шатдаун, разумеется. И да, документацию я читал.
На всякий случай же пояснил. Честно, я всякое видел.
ChALkeRx
15.04.2016 19:44На всякий случай, уточняющий вопрос — кто у вас выполняет рестарт? Если приложение упадёт, но uncaughtException не вызовется — что произойдёт? Возможно, я вас неправильно понял?
Leopotam
15.04.2016 19:48Рестарт выполняет pm2 потому что на выходе приложение все-равно возвращает ошибку. До завершения работы просто делается еще кое-какой набор оповещений по другим сервисам, не критично в данном случае.
ChALkeRx
15.04.2016 19:51+1Это уже хорошо. Вот тут вы про это не написали:
> В нашем случае — вполне себе решение. С сообщением куда надо и рестартом процесса.
Необязательные обработчики на него вполне можно повесить, но сильно рассчитывать на то, что они будут выполнены при каждом падении — нельзя.
ChALkeRx
15.04.2016 20:03> для этого был нанят отдельный админ по настройке продакшн-впс-ок. После первоначальной настройки деплоеры были вынуждены постоянно привлекать его к дополнительным фиксам своей работы по настройке работы сервисов (nodejs) на 8-ом дебиане. Продактоунеру надоело, админ был уволен, после чего все прекрасно стабилизировалось на pm2, причем как на дев/тест-окружении, так и в продакшне. Единая система развертывания, никакой мороки даже при миграции между хост-ОС.
У меня был опыт и с системд, и с софтом для надзора над процессами, работающим от пользователя.
По моему опыту, последний — ненадёжен. Я вам даже пример багрепорта в pm2 привёл.
Если речь идёт действительно про продакшн, то дешевле отдать админу почасовую зарплату за настройку нескольких файлов конфигурации (они, кстати, весьма тривиальны и очень хорошо задокументированы), чем потом рвать волосы над упавшим внезапно всем.
ChALkeRx
15.04.2016 15:55+1А без переходов на личность Поттеринга, в чём заключается ваше замечание? (Upd: заметил замечание выше про системы, ответил).
systemd представляет из себя демон инициализации и управления службами. То есть ровно то, что авторы pm2 и forever пытаются реализовать заново, когда в системе соответствующая задача уже решена грамотно.
Например:
systemd гарантирует перезапуск при сбоях — см. http://0pointer.de/blog/projects/watchdog.html
systemd позволяет управлять выделением ресурсов процессам — см. http://0pointer.de/blog/projects/resources.html
Ну и т.д.VolCh
15.04.2016 19:50Авторы пытаются реализовать более простой в использовании инструмент.
ChALkeRx
15.04.2016 20:29Но которому, к сожалению, нельзя доверить поставленную задачу.
ChALkeRx
15.04.2016 21:11Так, выше я ссылочку уже приводил, дополню тут: https://github.com/Unitech/pm2/issues?q=is%3Aissue+is%3Aopen+crash
VolCh
15.04.2016 23:49+2Какую задачу? Стоит ли эта задача дополнительного времени на освоение, а то и введения новой технологии на общесистемном уровне? При том, что по большому счёту не разработчика это дело вообще.
ChALkeRx
16.04.2016 00:20Задачу контроля за запускаемыми процессами же, и перезапуска их в случае падения/зависания.
VolCh
17.04.2016 11:49И что, более простые инструменты эту задачу вообще не решают? Или не решают её в подавляющем большинстве реальных случаев? А может, всё же, решают? Пускай хуже, чем монстры типа upstart или systemd, но компенсируют это простотой решения.
Тем более вы говорите о конкретно systemd, а не об абстрактном init в целевой системе. Вы предлагаете всем переводить боевые сервера с того же upstart на systemd? Мне вот как-то не хочется наши сервера на одном из самых популярных дистрибутивов (Ubuntu 14.04 LTS) вручную переводить на systemd. Да и на 16.04 переводить будем далеко не на следующей неделе.
Ну и учтите, что ЦА поста далеко не профессиональные администраторы, а начинающие разработчики.ChALkeRx
17.04.2016 12:38+1> И что, более простые инструменты эту задачу вообще не решают?
Да, я не могу назвать это решением задачи.
Я приводил ссылки на багрепорты выше.
Вкратце — если вы используете forever/pm2 в качестве инструмента для перезапуска вашего сервера, то когда падает forever/pm2 (а они вполне себе падают, см. багрепорты) — всё валится.
Это можно _частично_ решить, настроив перезапуск самого forever/pm2 из системы, но зачем тогда в этой цепочке forever/pm2 как лишняя точка отказа? «Частично» — потому что это даст перезапуск только при падениях, но не при тех сбоях, которые не роняют процесс.
> Тем более вы говорите о конкретно systemd, а не об абстрактном init в целевой системе.
Я говорю о наиболее распространённом случае. Ничего не мешает решить эту задачу другой реализацией системного инита, который гарантирует перезапуск сервисов.
> Мне вот как-то не хочется наши сервера на одном из самых популярных дистрибутивов (Ubuntu 14.04 LTS) вручную переводить на systemd.
> Ну и учтите, что ЦА поста далеко не профессиональные администраторы, а начинающие разработчики.
Если у вас задача перезапуска решена корректно через upstart — то у вас всё хорошо, конечно.
Но как раз начинающим разработчикам явно не стоит сейчас начинать с мёртвого upstart.
ChALkeRx
17.04.2016 12:51+1> более простые инструменты
С этим я тоже не соглашусь, кстати.
По объёму кода — systemd (как и любой другой инит) в разы меньше и гораздо проще чем набор v8+node.js+pm2+все его зависимости.
По простоте использования — у systemd это текстовый файл из нескольких строчек (ссылка — http://0pointer.de/blog/projects/watchdog.html, см. example unit file). Там нету никакой квантовой физики, реально конфиги systemd гораздо проще тех же bash-скриптов.
Добавление сюда перезапуска в случае зависания (или другого сбоя, не роняющего процесс) — вопрос включения пакета вроде https://www.npmjs.com/package/sd-daemon и вызова sd.startWatchdogPing().
foxmuldercp
16.04.2016 21:48+1Вы только что предложили мне портировать systemd на FreeBSD/Solaris/OpenBSD, чтоли?
Ах, да, ещё есть daemontools, например, я их регулярно на проектах вижу.ChALkeRx
16.04.2016 21:53Нет, это касается наиболее частого случая — деплоя на линуксе. Который и описан в этом туториале, кстати.
solshark
15.04.2016 15:15+1Автор, возможно есть смысл добавить, что инструкции из этой статьи не рекомендуется выносить далее виртуальной машины? Возможно, следует обозначить какие-то шаги для приложений из реального мира:
— деплоить файлы на сервер в разы удобнее flightplan и подобными инструментами
— как справедливо заметили, нужен фронтент (nginx)
— node.js практичнее ставить через nvm
— управлять процессами удобнее через pm2
Хотя, если это все действительно сарказм…
zapolnoch
15.04.2016 15:30Ну почему сразу сарказм. Для «чик-чик и в продакшн» сойдет. А для серьезных проектов все равно нужен нормальный админ, а не «full-stack».
Sirion
15.04.2016 16:08Не желаете написать свой ответ Чемберлену? С огромным удовольствием прочёл бы.
DarkHells
15.04.2016 16:42+1В качестве демонизатора лучше использовать pm2. Ибо forever пишет логи в файл и если завалите свой проект, то он всё место займет.
Mithgol
15.04.2016 17:21+3Никто не любит forever, а заменяет его каждый
по-своему.
Я перевёл статью «Автозапуск приложения Node.js на CentOS 6.2» в своё время; рекомендую указанный там способ,upstart использующий.
azat-io
15.04.2016 22:36Можно ли на одном VPS держать несколько Node.js сайтов?
Leopotam
15.04.2016 22:49Почему нет? node.js — это по сути отдельное приложение, в котором реализуется в том числе и http/s сервер. Можно поднять несколько приложений на разных портах и роутить трафик nginx-ом с анализом запрашиваемого домена (это если нужно делать несколько сайтов на 80/443 порту — несколько доменов, а ip один), либо просто открыть эти порты снаружи, если не критичны красивые урлы без кастомных портов.
Mithgol
15.04.2016 23:12Зачем такие ужасы? Нет необходимости в nginx и нет необходимости в разных портах. (Если неймётся, то можно, конечно; но реальной необходимости нет.)
Достаточно поставить пакет vhost для обеспечения поддержки виртуальных хостов.
В его документации приводятся примеры настройки сервера Connect, но и на сервере Express работает ничуть не хуже, благо API для работы middleware у них очень сходно (а подчас и вовсе одинаково) функционирует.Leopotam
15.04.2016 23:50Ужасы не ужасы, но смотрите — nginx как фронтенд нужен, так? А приложения-сайты на ноде можно вешать как угодно и по всем портам локалхоста — они даже знать не будут, что работают не напрямую, им даже не нужно будет уметь ssl до фронтенда. Управление роутингом, ssl — все в одном месте (nginx), красота.
Mithgol
16.04.2016 16:39Как фронтэнд nginx нужен, но не слишком. JavaScript так резво ворочается, что сайт на Express.js может обходиться без фронтэнда. Для SSL достаточно десятка строк:
var fs = require('fs'); require('https').createServer( { key: fs.readFileSync('somepath/server.key'), cert: fs.readFileSync('somepath/server.crt'), honorCipherOrder: true }, require('./some_Express-based_application.js')(options_for_application) ).listen(443);Leopotam
16.04.2016 17:58+1Я знаю как коннектить ключики и знаю, как оно работает. Тут фишка в более простом обслуживании и еще большем ускорении — https коннекты требуют большей нагрузки на cpu — можно сделать одну точку обслуживания ssl и одну точку роутинга. В результате внутренние сайты работают максимально быстро по http до nginx-а (а он уже наружу смотрит как ssl), так же удобнее держать ssl сертификаты в одном месте, а не копировать по нескольким серверам + добавлять инициализацию. Т.е. можно с ходу накидать сотню поддоменов одного сайта, поднять их на localhost:port, а все остальное сконфигурировать в одном файлике — роутинг (даже с заворотом http на https) + ssl с правильной настройкой разрешенных алгоритмов и тп. Т.е. обслуживание / разворот нового сайта сильно упрощается. Это все имхо, конечно, но мне показалось сильно проще.
ChALkeRx
15.04.2016 23:14Как несколько приложений? Можно, но (особенно если у вас там мало памяти) имеет смысл ограничить использование памяти каждому из приложений.
Иначе может возникнуть такая ситуация, что одно из них отожрёт всё (случается разное), а другое ничего не сможет сделать, упадёт, и не поднимется из-за нехватки памяти.
ChALkeRx
15.04.2016 23:25+1Так. Я сходил по ссылке на epel. Я правильно понимаю, что это инструкция по установке Node.js 0.10? Там в репозитории именно такой лежит.
{надел шляпу}
Народ, у 0.10 срок поддержки заканчивается через несколько месяцев.
После этого не будут выходить даже исправления безопасности.
В том числе исправления безопасности вшитого openssl, которые весьма часто случаются.
Слезайте.
{снял шляпу}ChALkeRx
16.04.2016 01:38{надел шляпу ещё раз}
И на всякий случай напомню, что поддержка 0.12 тоже закончится в этом году (а именно — в декабре), всего на пару месяцев позже 0.10.
Основная причина сдвига — поддержка OpenSSL из Node.js 0.12 заканчивается тогда же.
{снял шляпу}
ChALkeRx
15.04.2016 23:56Перечитал статью не по диагонали.
CentOS 6, Node.js 0.10 (я же не ошибся?), ручная установка npm скриптом (спасибо хоть по https), запуск приложения от рута, глобальные модули, forever, «iptables мешает — отключите его».
Я вижу последний абзац, и автор понимает (по крайней мере на счёт большей части), что всё это — совсем не то, как надо делать.
И всё же, зачем людей учить на плохих примерах?
4ertovo4ka
16.04.2016 02:15Места в комментариях перестало хватать, раз сарказм начал уже требовать написания отдельной статьи, да еще и с пометкой tutorial?
Capatillo
16.04.2016 05:28Статья явно писалась очень давно, потому что приведенный в пример хостинг уже не работает.
Haphost will be shut down on the 1st of August, 2015
Fen1kz
Я все равно рекомендую Heroku или OpenShift, потому что там отлично можно захостить node.js прототип, с базой из mlab. Если вся статья не жалкий сарказм насчет fullstack, конечно.