Развертывание сервера Node.js

Я написал приложение Node.js, я ищу, чтобы запустить его на одной из наших производственных машин. Это похоже на довольно распространенный запрос, но я не могу найти адекватное решение. Не установлены ли решения для развертывания приложений Node.js?

Приложение прост (< 100 LOC), но оно должно быть очень эффективным, надежным и может работать непрерывно в течение многих лет без перезапуска. Он будет запущен на большом сайте с десятками соединений в секунду. (приложение не используется как веб-сервер, оно имеет только JSON API)

Вот те подходы, которые я рассмотрел, но я до сих пор не уверен:

Использование фреймворка (например, Express)

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

Запуск сервера с помощью nohup

Основная проблема здесь заключается в обработке исключений, мы (очевидно) не хотим, чтобы весь сервер разбился из-за исключения. Насколько я понимаю, обертка всего приложения в цикле try {} catch {} не поможет, потому что интерпретатор Javascript остается в непредсказуемом состоянии после исключения. Это правильно?

Использование чего-то вроде Forever

Я установил Forever на машине FreeBSD, и это было очень плохо. Это привело к появлению бесконечных процессов, которые нельзя было убить с Forever. Мне пришлось запустить kill -9, чтобы вернуть мою машину, и я не слишком уверен в запуске производственного приложения Forever. Также кажется, что Upstart (аналогичный инструмент, но более общий) не будет работать на FreeBSD.

Хостинг решений (например, Heroku, Rackspace, Amazon EC2 и т.д.)

Это, наверное, самое простое решение, но у нас уже есть серьезное оборудование для остальных наших веб-серверов. Для финансовых соображений это не имеет смысла.

Неужели должно быть какое-то определенное решение? Я что-то пропустил?

Ответ 1

Вы действительно должны использовать фреймворк (я рекомендую что-то вроде Express, так как оно было проверено на бой), если вы не хотите заниматься сеансами, куки, промежуточным программным обеспечением и т.д. самостоятельно. Экспресс действительно легкий.
Запуск сервера с nohup: вы не должны этого делать, просто запустите его с помощью обычной команды "node". Кроме того, Express переносит маршруты в try-catch, поэтому ваш сервер не будет разбиваться по маршруту. Однако, если у вашего сервера есть серьезная проблема, вы не должны бояться перезапускать его (кроме того, если у вас есть хотя бы 2-3 процесса, по крайней мере, только один умрет, поэтому будет по крайней мере 1-2 оставшихся, и пользователь выиграет ' я чувствую что-то).
Для мониторинга я лично предпочитаю что-то большее на OS-уровне, например Upstart и Monit.
Решение для хостинга: поскольку у вас уже есть собственные серьезные аппаратные средства, не нужно вкладывать деньги в что-то другое. Просто используйте балансировку нагрузки (возможно, nginx или node -http-proxy) для прокси-сервера.

Ответ 2

См. Хостинг Node Приложения.

В этом учебном руководстве вы можете настроить сервер, на котором могут размещаться приложения node.js для приложений на стороне сервера. Прямо сейчас, параметры хостинга node.js сводятся к запуску процессов демона Node, которые общаются с веб-сервером. Большинство веб-серверов могут прокси-соединения с другим портом, поэтому вы можете использовать Apache или nginx для этого.

Ответ 3

Здесь, наверное, три вопроса.

Вопрос 0: "Должен ли я использовать фреймворк для моего приложения node?"

Вопрос 1: "Как запустить серверы node на производственных машинах?"

Вопрос 2: "Как развернуть приложения node для производства".

Для Вопрос 1 мне очень нравится Cluster (хотя последняя версия node имеет что-то вроде который встроен, чтобы вы могли проверить это). У меня был хороший успех с чем-то вроде Monit/Upstart, чтобы следить за событиями на уровне ОС и следить за тем, чтобы ваши серверы находились в хорошем состоянии. (Это контролировало N кластеров серверов Ruby Thin, но то же самое).

В зависимости от трафика вы можете захотеть запустить кластер на нескольких машинах, а затем поставить перед ним балансировку нагрузки. Это зависит от вашего трафика, от того, сколько времени потребуется на выполнение/сколько времени вы блокируете цикл событий, и сколько экземпляров процессоров / node вы запускаете на машину.

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

Для Вопрос 2, я не думаю, что сообщество node имеет хороший стандарт развертывания. Вы можете попробовать использовать инструмент Ruby Capistrano (и здесь запись в блоге о развертывании кластера с Capinstrano).

Плохая вещь о Capistrano заключается в том, что он делает некоторые предположения, которые могут быть неверными (т.е. что вы развертываете проект Rails), поэтому вы можете в конечном итоге сражаться с каркасом.

Мое решение для развертывания в целом - это инструмент Python Fabric, который дает вам инструменты развертывания и позволяет делать то, что вам нужно делать.

Другой вариант развертывания - это "облако" с такими вещами, как Nodester: пусть они позаботятся об этом.

Ответ 4

Попробуйте использовать pm2, это простой и интуитивно понятный CLI, устанавливаемый через NPM. Просто запустите приложение с PM2, и ваше приложение будет готово обрабатывать тонну трафика.

Официальная ссылка PM2

Как настроить приложение node js для создания с использованием pm2

Ответ 5

Вы можете получить более качественные ответы на ServerFault, но здесь описано один пользовательский опыт здесь, используя supervisord. Вам нужно будет использовать какой-то наблюдатель процессов, чтобы поддерживать процесс node, и другая общая рекомендация, похоже, как-то обращается к прокси-соединениям с процессом node. Вероятно, я проголосовал бы за nginx (таким образом, вы можете иметь nginx обрабатывать протоколирование, аутентификацию или любые другие функции HTTP более высокого уровня, которые вам нужны, а не как-то выпекать их в node), но вышеупомянутая статья упоминает haproxy в комментариях здесь и там, которые могут быть более легкими. Ваш выбор обратного прокси-сервера, вероятно, будет во многом зависеть от того, нужна ли вам поддержка WebSocket.

Я не уверен, что для node еще не существует "стандартного" рабочего процесса; он не совсем зрелый, как что-то вроде Rails, у которого есть множество способов сохранить работу webapp.

Ответ 6

Ребята из Cloudkick написали отличное решение для этого. Он назывался Cast, http://cast-project.org/.

Установите листинг на свой сервер и на свою рабочую станцию. Вы запускаете агент-агент на сервере и подписываете свою рабочую станцию с экземпляром экземпляра серверов. Затем вы можете создавать "пакеты", загружать их на сервер, создавать/обновлять/уничтожать их, а также запускать/останавливать свои экземпляры. Cast автоматически перезапустит ваши службы при их сбое. Вы также можете удаленно удалять stdout/strerr, а также получать список запущенных экземпляров и PID # s и управлять своими экземплярами/серверами с вашей рабочей станции (не требуется SSHing). Документы немного устарели, но результаты стоят немного дополнительной работы. Все взаимодействия/команды превышают HTTPS и RESTful API.

До этого я делал все обновления вручную с помощью SCP/SSH. У нас есть supervise. Мы не оглядывались назад.