Установка node.js на Linux, FreeBSD, Windows

[MikeGav]

Спасибо. Это руководство надо добавить на nodejs.ru

[ainu]

Хорошо, добавлю, с учетом замечаний, если они будут.

[Programmer]

Лучше было бы собрать как минимум при помощи checkinstall

checkinstall --fstrans=no --install=no --pkgname=node.js --pkgversion «0.1.97» --default

[NickMitin]

А расскажите почему эта жуть:

checkinstall --fstrans=no --install=no --pkgname=node.js --pkgversion «0.1.97» --default

лучше

make install

?

[Programmer]

Лучше она тем, что в итоге получится deb пакет который потом можно еще и удалить безболезненно.

[NickMitin]

Спасибо, буду знать.

[Programmer]

самый простой вариант — запускать screen, либо запускать с амперсандом в конце, выключая при помощи команды killall node.

Если запускать с ампресандом в конце — то при выходе из консоли он всеравно закроется. Есть такая команда nohup

А еще есть утилита start-stop-daemon

[isden]

под линуксом лучше таки собрать пакет и поставить его средствами пакетного менеджера. а не превращать систему в слаку. сборка пакета довольно проста. для deb-based дистрибутивов, например, можно использовать checkinstall. т.е.

make
sudo checkinstall -D make install

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

[Programmer]

Надо заметить у автора не самый удачный конфиг для Nginx.
Дело в том, что node.js часто используют для всяких долгоживущих соединений.
Поэтому, как минимум, стоит выключить вот эту опццию
Более удачные конфигурации для node.js можно найти здесь

[akzhan]

Один язык для клиента и сервера — это естественно ;)

[ainu]

Во-первых, для серверных COMET решений преимущества для тех, кто никогда не использовал Ruby или Python — node очень прост в изучении, это знакомый javascript.
Во-вторых, скорость, она великолепна.

[iliakan]

Основных преимуществ два — скорость + память.
Основной недостаток — количество вспомогательных библиотек, молодость решения.

Более конкретно о преимуществах и недостатках можно говорить, в зависимости от того, с каким другим решением осуществляется сравнение.

Не последнюю роль здесь играют личные предпочтения разработчиков и уже существующий серверный фреймворк, если он есть.

Скажем, у меня CRM на django — так почему бы не взять Tornado/Twisted?
Или система на Java — естественное решение cometD / Jetty / Grizzly.
Можно везде использовать одну и ту же модель, это очень удобно.

[kurokikaze]

А обработка файлов в мультизагрузке по мере их поступления? :)

[stfalcon]

очереди? Zend_Qeueu

[hilobok]

На FreeBSD чтобы не собирать libexecinfo из портов достаточно сделать:

pkg_add -r libexecinfo

[azproduction]

Для пользователей windows (если у вас node.exe и server.js лежат в разных местах) команда для запуска из-под Cygwin версии будет:
node.exe /cygdrive/буква_диска/путь/до/скрипта/server.js
относительные пути не понимает, windows пути с любыми слэшами тоже не понимает.

[akzhan]

Это специально для Вас: habrahabr.ru/blogs/webdev/95972/ :)

[akzhan]

Есть концепция сообщений (Web Workers API).

[akzhan]

Node.JS вообще-то очень далек от стабильной версии. ;)

Да, это master.

[ainu]

Оно работает на многих production серверах. Ему можно доверять.
В любом случае, сервер node надёжнее аналогичного, написанного на php и сокетах.

[akzhan]

Работать оно работает, но это не стабильная версия. Самое важное, — пока ещё возможны серьёзные изменения интерфейсов.

Недавно как раз вырезали Promises, к примеру.

Хотя, конечно, многие из нас привыкли работать на Edge-версиях, когда это оправдано.

Лично я уже подсел на Node :)

[Programmer]

А как насчет Nginx upstream backend?
Рано или поздно всеравно придется задуматься о масштабируемости

[Programmer]

Честно говоря, на ум ничего не приходит. Но всеравно непонятно зачем это нужно.

[ainu]

Простейший вариант — мастер-скрипт, запускающий отдельные процессы, может элементарно общаться с ними, событийно и асинхронно.
Вот пример общения с командой ls
Example of running ls -lh /usr, capturing stdout, stderr, and the exit code:
var sys = require('sys'),
spawn = require('child_process').spawn,
ls = spawn('ls', ['-lh', '/usr']);

ls.stdout.addListener('data', function (data) {
sys.print('stdout: ' + data);
});

ls.stderr.addListener('data', function (data) {
sys.print('stderr: ' + data);
});

ls.addListener('exit', function (code) {
sys.puts('child process exited with code ' + code);
});


[kurokikaze]

Есть, если процессы свои.

[iliakan]

Асинхронная архитектура отлично справляется с теми задачами, для которых предусмотрено асинхронное решение на всех этапах процесса обработки. Таким образом решается задача concurrency.

Например, операция отсылки содержимого файла на уровне OS асинхронна, сетевые операции асинхронны. Основной поток просто перепоручает задачу дальше и переходит к следующему запросу. В результате — multiuser concurrency.

Это работает не всегда. Точнее, не работает там, где асинхронность на некотором звене отсутствует.
Как должно быть? Вася поручил Маше, она поручила Паше, Паша получил Даше, Даша сказала ок — сделаю позвоню. И затем в обратную сторону.
Если на каком-то звене проблема, например, Даша решила сделать «пряма щас» (синхронно) — то Паша ждет ответа Даши, Маша ждет ответа Паши. Все курят.

В случае с node.js (not only) это происходит, например, с MySQL, для которой нет открытого асинхронного API. В этом случае для concurrency используются потоки.

Это отлично работает до тех пор, пока 1 процессор справляется с нагрузкой основного процесса. В 95% приложений так оно и есть, все в порядке.

Multiple CPU concurrency в оставшихся 5% (цифра приблизительная), и решается запуском нескольких процессов. При этом архитектура принципиально меняется, т.к. разные процессы имеют раздельное адресное пространство.
Как правило, стараются все равно хранить всех подключенных юзеров в одном массиве одного процесса, а детали зависят от того, откуда вообще берется 100% загруз CPU.

Вот, вкратце, все детали concurrency для Node.JS и других решений подобного рода, включая EventMachine (Ruby), Tornado/Twisted (Python), POE (Perl) и т.п.

[zxmd]

Это хорошо. Статья полезная.
Но у меня сразу возник вопрос о перезапуске приложений. Тоесть допустим зарелизили версию приложения, она работает например как сервер для онлайн игры. Нужно в релизе поправить пару багофиксов или сменить игровой баланс настроить. Как тогда это делается? Есть ли какие-то средства он-аир изменений? Или стоп-старт в любом случае необходим.
Интересна именно потенциальная возможность. Понятно что в реальном проекте это делается балансировщиками и проксирующими серверами, но допустим их нету (архи-хреновая архитектура)

[ainu]

У вышеупомянутого kurokikaze есть статья: Горячая замена кода в node.js
А так — да, придется перезагружать (это быстро, доли секунды, но переменные сбрасываются).
Можно переписать под себя — есть замечательная конструкция script:
var sys = require('sys'),
localVar = 123,
usingscript, evaled,
script = process.binding('evals').script;

usingscript = script.runInThisContext('localVar = 1;',
'myfile.js');
sys.puts('localVar: ' + localVar + ', usingscript: ' +
usingscript);

В двух словах — объект script может брать откуда-нибудь код скрипта, eval-ить его в машинный код (прекомпилировать), и затем многократно запускать.

[ainu]

Или вот так
scriptObj = new script('globalVar += 1', 'myfile.js');

for (i = 0; i < 1000 ; i += 1) {
scriptObj.runInThisContext();
}

Один раз скомпилили, 1000 раз запустили.

[akzhan]

Есть несколько подходов для горячей замены.

К примеру, github.com/isaacs/node-supervisor

Можно просто перезапрашивать файлы и модули при необходимости, об этом много писали в рассылке nodejs.

Новые функции и классы заменят старые, для новых объектов.

[AterCattus]

При сборке под FreeBSD 8.0_RELEASE amd64 с первого раза не собралось:

...obj/release/cpu-profiler.o(.text._ZN2v88internal23ProfilerEventsProcessor19FunctionCreateEventEPhS2_i+0x81): In function `v8::internal::ProfilerEventsProcessor::FunctionCreateEvent(unsigned char*, unsigned char*, int)':
: undefined reference to `v8::internal::OS::ReleaseStore(long volatile*, long)'
obj/release/cpu-profiler.o(.text._ZN2v88internal23ProfilerEventsProcessor15CodeCreateEventENS0_6Logger16LogEventsAndTagsEiPhj+0xa3): more undefined references to `v8::internal::OS::ReleaseStore(long volatile*, long)' follow
scons: *** [obj/release/mksnapshot] Error 1
scons: building terminated because of errors.
Waf: Leaving directory `/home/atercattus/node.js/node-v0.1.97/build'
Build failed: -> task failed (err #2):
{task: libv8.a SConstruct -> libv8.a}
*** Error code 1

Помогла эта ссылка: http://code.google.com/p/v8/issues/detail?id=726.
Там все просто, в v8/src/platform-freebsd.cc добавляется между int OS::ActivationFrameAlignment() и const char* OS::LocalTimezone(double time) реализация недостающей функции:

void OS::ReleaseStore(volatile AtomicWord* ptr, AtomicWord value) {
__asm__ __volatile__(""::: «memory»);
*ptr = value;
}

Может кому поможет.

[ainu]

Золотой комментарий, золотая информация, большое спасибо.
Сам был вынужден использовать 0.1.90, потому что такая версия в портах последняя, следовательно некоторые либы не работают, например, mysq-node.

[liaren]

У меня так и не получилось запустить Node.js на Windows 7 по вашей инструкции. Вот тут нашёл более рабочий вариант www.lazycoder.com/weblog/2010/03/18/getting-started-with-node-js-on-windows/

[TedBeer]

Так это не под виндовс, а в виртуальной машине. С таким же успехом вы можете там запустить любой линух-юних-мак.

[liaren]

Да, но других рабочих решений установки Node.js под Windows я так и не нашёл.

[TedBeer]

я скачал по ссылке из статьи скомпилированный вариант и все работает под Вин7

[liaren]

Я извиняюсь. Перепроверил, оказывается node.exe просто не понимает вызова вида:
node.exe d:/server/home/localhost/www/server.js

Работает только если server.js находится в папке с node.exe и вызывается:
node.exe server.js

Кто-нибудь заминусуйте мой коммент
TedBeer, спасибо!

[ihoru]

Лично меня заинтересовал этот язык.
Попробую покопать в сторону сокетов, чтобы онлайн соединения между пользователями осуществлять.
Спасибо

[kurokikaze]

Вот так попробуйте.