node js перезапуск скрипта
О завершении работы Node.js-процессов
Существует несколько способов намеренного завершения работы процесса. Среди них — следующие:
Операция | Пример |
Ручной выход из процесса | |
Неперехваченная ошибка | |
Необработанное отклонение промиса | |
Проигнорированное событие error | |
Необработанный сигнал |
Ручной выход из процесса
Этот Node.js-однострочник ничего в консоль не выведет. Правда, воспользовавшись возможностями командной оболочки, можно узнать статус завершения процесса. Пользователь программы, столкнувшись с тем, что она завершила работу подобным образом, не поймёт того, что произошло.
Теперь пользователю будут понятны причины остановки приложения. Пользователь запускает приложение, оно выдаёт ошибку в консоль, после чего пользователь принимает меры для исправления ситуации.
Стоит отметить, что метод process.exit() — это весьма мощный механизм. Хотя у него есть своё место в коде приложений, его категорически не рекомендуется использовать в библиотеках, рассчитанных на многократное использование. Если ошибка произошла в библиотеке, библиотека должна её выбросить. Это позволит приложению, использующему библиотеку, самостоятельно принять решение о том, как обрабатывать эту ошибку.
Исключения, отклонения промисов, выдача событий error
Экземпляры класса Error содержат метаданные, которые полезны в деле определения причины ошибки. Например — данные трассировки стека и строки с сообщениями об ошибке. Распространённой является практика построения на основе класса Error классов ошибок, рассчитанных на конкретное приложение. При этом одно лишь создание экземпляра класса Error не приводит к каким-то заметным последствиям. Экземпляр ошибки нужно не только создать, но и выбросить.
А вот пример того, что при выполнении подобного кода выводится в консоли:
Отклонённые промисы, в отличие от неперехваченных исключений, не приводят, в Node.js v14, к остановке процесса. В будущих версиях Node.js отклонённые промисы будут завершать работу процессов. Подобные события, как и в случае с событиями ошибок, можно перехватывать с помощью объекта process :
Сигналы
В разных операционных системах могут быть определены различные сигналы. Ниже приведён список сигналов, которые, по большей части, универсальны.
Имя | Код | Подлежит ли сигнал обработке | Стандартная реакция Node.js | Цель сигнала |
1 | Да | Завершение работы | Закрытие терминала | |
2 | Да | Завершение работы | Сигнал прерывания (Ctrl+C) с терминала | |
3 | Да | Завершение работы | Сигнал Quit с терминала (Ctrl+D) | |
9 | Нет | Завершение работы | Безусловное завершение процесса | |
10 | Да | Запуск отладчика | Пользовательский сигнал №1 | |
12 | Да | Завершение работы | Пользовательский сигнал №2 | |
15 | Да | Завершение работы | Запрос на завершение работы процесса | |
19 | Нет | Завершение работы | Остановка выполнения процесса |
Если в программе может быть реализован механизм обработки соответствующего сигнала — в столбце таблицы «Подлежит ли сигнал обработке» стоит «Да». Два сигнала из таблицы с «Нет» в этой колонке обработке не подлежат. В столбце «Стандартная реакция Node.js» описана стандартная реакция Node.js-программы на получение соответствующего сигнала. В столбце «Цель сигнала» приведено описание стандартного общепринятого подхода к использованию сигналов.
Для обработки этих сигналов в Node.js-приложении можно воспользоваться уже знакомым нам механизмом объекта process по прослушиванию событий:
Возможно, вы уже догадались о том, что Node.js-программы могут отправлять сообщения другим программам. Выполните следующую команду, которая демонстрирует отправку сообщения от короткоживущего процесса работающему процессу:
В ответ на эту команду наш процесс покажет то же SIGHUP-сообщение, что показывал ранее. А если же работу этого процесса нужно завершить, ему надо отправить необрабатываемый сигнал SIGKILL :
После этого работа программы должна завершиться.
Как автоматически перезагрузить файлы в Node.js?
Любые идеи о том, как я могу реализовать автоматическую перезагрузку файлов в Node.js? Я устал от перезапуска сервера каждый раз, когда я меняю файл. Очевидно, что функция require() Node.js не перезагружает файлы, если они уже были необходимы, поэтому мне нужно сделать что-то вроде этого:
И в файле app.js у меня есть:
25 ответов
Хорошей современной альтернативой supervisor является nodemon :
Чтобы использовать nodemon :
Для перезагрузки app.js в текущем каталоге используйте
Вы можете сделать это с помощью обновления браузера. Приложение вашего узла перезапускается автоматически, ваша страница результатов в браузере также обновляется автоматически. Недостатком является то, что вы должны поместить фрагмент js на созданную страницу. Вот репозиторий для рабочего примера.
Структура моего приложения:
Сначала установите перезагрузить с помощью этой команды:
Затем измените package.json :
Теперь вы должны использовать перезагрузку в своем файле сервера :
И для последнего изменения в конце вашего ответа отправьте этот скрипт :
Теперь запустите ваше приложение с этим кодом:
Обратите внимание, что вы должны самостоятельно позаботиться об использованных ссылках.
Это означает, что если вы это сделали: var x = require (‘foo’); у = х ; г = x.bar ; и горячо перезагрузил его.
Это означает, что вы должны заменить ссылки, хранящиеся в x, y и z. в горячей функции обратного вызова reaload.
Также мне нравится мой модуль притока узлов.
Нет необходимости использовать nodemon или другие подобные инструменты. Просто используйте возможности вашей IDE.
nodemon отличный. Я просто добавляю больше параметров для отладки и просмотра параметров.
—inspect Включить удаленную отладку.
./server/server.js Точка входа.
Затем добавьте следующую конфигурацию в launch.json (VS Code) и начните отладку в любое время.
Обратите внимание, что лучше установить nodemon в зависимости от проекта. Поэтому членам вашей команды не нужно устанавливать его или запоминать аргументы команды, они просто npm run dev и начинают взламывать.
nodemon появился первым в поиске в гугле, и, похоже, он добился цели:
Использование для перезагрузки при сохранении:
Node-dev прекрасно работает. npm install node-dev
Он даже выдает уведомление на рабочем столе, когда сервер перезагружается, и выдает сообщение об ошибке или об ошибке.
Запустите ваше приложение из командной строки с помощью:
Вы можете использовать автоматическую перезагрузку для перезагрузки модуля без выключения сервера.
Установить
Пример
И каждое изменение в ваших файлах будет автоматически вызывать перекомпиляцию
Он обрабатывает ситуации, когда файлы достаточно велики, чтобы watch вызывался до того, как они закончили писать.
Я использовал его в проектах в течение года или около того, и только недавно добавил к нему обещания.
Помоги мне проверить это!
Я нашел простой способ:
Все, что вам нужно сделать сейчас, это:
И конфиг будет автоматически перезагружен 🙂
Существует Node-Supervisor, который вы можете установить
Если кто-то все еще приходит к этому вопросу и хочет решить его, используя только стандартные модули, я сделал простой пример:
Этот пример предназначен только для одного файла (server.js), но его можно адаптировать к нескольким файлам, используя массив файлов, цикл for для получения всех имен файлов или просматривая каталог:
Этот код был создан для Node.js 0.8 API, он не адаптирован для некоторых конкретных нужд, но будет работать в некоторых простых приложениях.
ОБНОВИТЬ: Этот функционал реализован в моем модуле simpleR, GitHub repo
Или используя режим отладки
Вы также можете запустить напрямую
Надеюсь на эту помощь.
Вот низкотехнологичный метод для использования в Windows. Поместите это в пакетный файл с именем serve.bat :
Это откроет новое окно оболочки с запущенным сервером. Пакетный файл будет блокироваться (из-за /wait ) до тех пор, пока вы не закроете окно оболочки, после чего исходная командная оболочка cmd спросит «Завершить пакетное задание (Y / N)?» Если вы ответите «N», то сервер будет перезапущен.
Каждый раз, когда вы хотите перезапустить сервер, закройте окно сервера и ответьте «N» в оболочке cmd.
Я недавно пришел к этому вопросу, потому что обычные подозреваемые не работали со связанными пакетами. Если вы похожи на меня и используете npm link во время разработки для эффективной работы над проектом, состоящим из множества пакетов, важно, чтобы изменения, возникающие в зависимостях, также вызывали перезагрузку.
Попробовав node-mon и pm2, даже следуя их инструкциям по дополнительному просмотру папки node_modules, они все равно не получили изменений. Хотя в ответах есть несколько нестандартных решений, для чего-то подобного отдельный пакет будет чище. Сегодня я сталкивался с node-dev, и он отлично работает без каких-либо опций или настроек.
В отличие от таких инструментов, как супервизор или нодмон, он не сканирует файловую систему для поиска файлов. Вместо этого он подключается к функции Node’s require () для просмотра только тех файлов, которые действительно были необходимы.
Nodejs | Автоматический перезапуск сервера NodeJs с помощью nodemon
Обычно мы запускаем следующую команду для запуска сервера NodeJs:
В этом случае, если мы внесем какие-либо изменения в проект, нам придется перезапустить сервер, убив его с помощью сочетания клавиш CTRL + C, а затем снова введя ту же команду.
Это очень беспокойная задача для процесса разработки.
Nodemon — это пакет для автоматической обработки этого процесса перезапуска, когда в файле проекта происходят изменения.
Установка nodemon: nodemon должна быть установлена глобально в нашей системе:
Теперь давайте проверим, что nodemon был правильно установлен в системе, введя следующую команду в терминале или командной строке:
Он покажет версию nodemon, как показано на скриншоте ниже.
Запуск сервера узлов с помощью nodemon:
Теперь, когда мы вносим изменения в наше приложение nodejs, сервер автоматически перезапускается с помощью nodemon, как показано на снимке экрана ниже.
Таким образом, сервер nodemon автоматически перезагружается.
Настройка при ошибке перезапуска приложения на node js?
Всем привет.
Я начинающий программист. И знаю, что при программировании появляются подводные камни и с ними надо бороться. Но тут проблемка интересная, возможно кто подскажет или поделиться ссылкой на другой ресурс, в котором я смогу найти ответ.
Мне нужно, чтобы бот работал 24-ри часа в сутки. Для этого я выделил системник на котором настроил в биосе включения по питанию. Запуск бота поместил в батовский файлик в нем прописано:
Этот батовский файл я закинул в автозагрузку виндовс. Тоесть при отключении и включении электроэнергии системник стартует, потом виндовс и автозагрузка бота. Как бы все нормально. Но, не тут то было.
При запуске бота не всегда есть интернет он может появиться после 10-20 минут после старта бота. Соответственно, при старте запускается cmd в котором запускается окно npm в котором работает бот:
[nodemon] 2.0.7
[nodemon] to restart at any time, enter `rs`
[nodemon] watching path(s): *.*
[nodemon] watching extensions: js,mjs,json
[nodemon] starting `node app.js`
Скорей всего программа должна подключиться к телеграмму и к node. B ей надо интернет для регистрации каких-то модулей.
Проблема в том, что при появлении интернета программа так и висит с ошибкой и не работает. То есть, надо настроить перезапуск приложения (ну например раз в 15 минут) и если интернет есть, то оно стартанет и все заработает. Так вот вопрос как можно сделать перезапуск приложения програмнно?
Node.js в бою (создание кластера)
Когда вы используете приложения на node.js в продакшене, вам приходится задумываться о стабильности, производительности, безопасности и удобстве поддержки. Данная статья описывает мои мысли о лучших практиках использования node.js в бою.
К окончанию данного руководства вы получите систему из 3 серверов: балансировщик (lb) и 2 сервера приложений (app1 и app2). Балансировщик будет следить за доступностью серверов и распределять между ними траффик. Серверы приложений будут использовать комбинацию systemd и кластеризации node.js для балансировки траффика между несколькими процессами ноды на сервере. Вы сможете выкатывать код с помощью одной команды со своей машины, и при этом не будет перерывов в обслуживании или необработанных запросов.
Все это можно представить в виде схемы:
Фото предоставлено: Digital Ocean
От переводчика: с распространением изоморфного подхода к построению веб-приложений все больше разработчиков сталкиваются с необходимостью использования Node.js в продакшене. Эта статья Jeff Dickey понравилась мне практичным подходом и обзорным взглядом на эту широкую тему.
UPD (2018): Исправил ссылки на github автора.
Об этой статье
Данная статья адресована тем, кто только начинает заниматься вопросами настройки серверов в боевую эксплуатацию. Однако, вы должны иметь общее представление о данном процессе, знать, что такое upstart, systemd или init, и что такое сигналы процессов в unix. Я предлагаю вам попробовать данное руководство на своих серверах (но все же использовать мой демо-код). Кроме этого, я приведу несколько полезных настроек конфигурации и скриптов, которые будут служить хорошей отправной точкой при настройке собственного окружения.
Итоговый вариант приложения находится здесь: https://github.com/jdxcode/node-sample.
В этом руководстве я буду использовать Digital Ocean и Fedora. Тем не менее, статья написана как можно более независимой от стека технологий.
Я буду использовать серверы Digital Ocean с ванильными образами Fedora 20. Я протестировал руководство несколько раз, поэтому у вас не должно возникнуть проблем при воспроизведении этих действий.
Почему Fedora?
Все дистрибутивы Linux (кроме Gentoo) переезжают c различных систем инициализации на systemd. Так как Ubuntu (пожалуй, самый популярный дистрибутив в мире) пока не перешел на него (но они это уже анонсировали), я считаю, что будет неправильно обучать вас использованию Upstart.
systemd предлагает несколько значительных преимуществ по сравнению с Upstart, включая продвинутое централизованное журналирование, упрощенную конфигурацию, производительность, и еще много каких возможностей.
Установка Node.js
Сначала вам необходимо установить node.js на свежий сервер. На Digital Ocean мне хватило всего 4 команд.
Здесь мы устанавливаем ноду через yum (который может поставить нам устаревшую версию), потом ставим отличный пакет n, который умеет устанавливать и переключать различные версии ноды. Им мы и воспользуемся для обновления node.js.
Позднее я покажу, как можно автоматизировать этот шаг с помощью Ansible.
Создайте пользователя web
Добавляем приложение
У нас есть сервер ноды, и мы можем перейти к добавлению нашего приложения:
Это простейшее приложение для ноды:
app.js
Можете зайти на сервер по IP, используя браузер, и вы увидите, что приложение работает:
Еще примечание: По умолчанию приложение запускается на порту 3000. Чтобы запустить его на 80 порту вам понадобится прокси-сервер (наподобие nginx), но для нашей конфигурации необходимо запускать сервер приложения на порту 3000, а балансировщик (на другом сервере) будет работать на порту 80.
systemd
После того, как мы научились запускать сервер приложения нам нужно добавить его в systemd, чтобы он перезапускался в случае аварии.
Мы будем использовать следующий systemd скрипт:
Кластеризация процессов
Теперь, когда мы можем запускать один процесс с нашим приложением, нам нужно воспользоваться встроенными методами кластеризации ноды, которые позволят автоматически распределять траффик по нескольким процессам.
Вот пример файла для кластеризованной версии:
node-sample.service
Балансировка
Сначала установите второй сервер приложений, повторяя предыдущие шаги. Потом создайте новый сервер в Digital Ocean (или еще где-то) и подключитесь к нему через ssh.
Установите HAProxy: # yum install haproxy
Замените файл /etc/haproxy/haproxy.cfg на следующий (подставьте IP своих серверов):
Теперь перезагрузите HAProxy: systemctl restart haproxy
Для дополнительной информации по настройке HAProxy предлагаю ознакомиться с руководством, которое я использовал, или с официальной документацией.
Деплой кода с помощью Ansible
Люди боятся Ansible. Многие считают, что он похож на сложные инструменты вроде Chef или Puppet, но на самом деле он ближе к Fabric или Capistrano. В самом простом случае он просто подключается по ssh к серверу и выполняет команды. Без клиентов, мастер-серверов, сложных cookbooks — просто команды. У него есть отличные возможности для развертывания серверов (provisioning), но вы можете их не использовать.
Вот файл Ansible, который просто деплоит код:
deploy.yml
Файл production в Ansible называется инвентарным файлом (inventory file). Он просто перечисляет адреса всех серверов и их роли.
Примечание: если вы хотите использовать личный git репозиторий, вам понадобится установить Перенаправление агента авторизации в SSH.
Ansible для развертывания (provisioning)
В идеале, мы должны автоматизировать сборку сервера приложений, чтобы не приходилось вручную повторять все шаги каждый раз. Для этого мы можем использовать следующий сценарий Ansible для развертывания сервера приложений:
Итоговое приложение
Вот итоговый результат всех этих шагов. Как там говорится, для запуска приложения нужно: обновить инвентарный файл, развернуть наши сервера и запустить деплой приложения.
Тестовая среда?
Создать новое окружение просто. Добавьте еще один инвентарный файл (ansible/production) для тестов и можете ссылаться на него, когда вызываете ansible-playbook
.
Тестирование
Что можно улучшить
Нет идеальных кластеров, и этот не исключение. Я бы спокойно выложил его в продакшен, но в будущем можно кое-что усилить:
HAProxy Failover
В данный момент HAProxy это единая точка отказа, хотя и надежная. Мы могли бы убрать ее с помощью DNS Failover. Он не мгновенный и даст несколько секунд простоя, пока запись DNS распространяется. Я не переживаю, что HAProxy упадет сам по себе, но есть большая вероятность человеческой ошибки при изменении его конфигурации.
Последовательный деплой (Rolling deploys)
На случай если очередной деплой ломает кластер, я бы настроил последовательный деплой в Ansible, чтобы постепенно выкатывать изменения, проверяя по пути доступность серверов.
Динамические инвентарные файлы
Я думаю, некоторым это будет более важно, чем мне. В данном руководстве нам приходилось сохранять адреса серверов в исходном коде. Можно сконфигурировать Ansible так, чтобы он динамически запрашивал список хостов в Digital Ocean (или другом провайдере). Можно даже так создавать новые серверы. Однако, создание сервера на Digital Ocean это не самая сложная задача.
Централизованное журналирование
JSON журналы отличная вещь, если вы хотите легко агрегировать их и искать по ним. Я бы посмотрел на Bunyan для этого.
Было бы здорово, если бы логи всех серверов стекались в одно место. Можно использовать что-нибудь вроде Loggly, а можно попробовать другие пути.
Отчеты об ошибках и мониторинг
Существует множество решений по сбору ошибок и журналированию. Ни одно из тех, что я пробовал, мне не понравилось, так что я не берусь вам что-нибудь советовать. Если вы знаете хороший инструмент для этого, пожалуйста, напишите об этом в комментариях.
Рекомендую отличное руководство по запуску Node.js в продакшен от Joyent — там много дополнительных советов.
Вот и все! Мы построили простой, стабильный кластер Node.js. Дайте мне знать, если у вас есть идеи, как улучшить его!
От переводчика: спасибо за то, что вы еще здесь. Я впервые пробую себя в роли переводчика. Уверен, что не все перевел правильно, поэтому прошу присылать сообщения об ошибках, а также опечатках и проблемах оформления по внутренней почте.