nodejs: менеджеры процессов и ES6-модули

в 16:28, , рубрики: forever, javascript, node.js, nodejs, pm2, process manager, systemd

В мире серверного JavaScript'а я — новичок с чистым, практически незамутнённым разумом. Поэтому когда я узнал о существовании менеджеров процессов, а конкретно — о pm2, то сразу же попробовал применить его для запуска какого-нибудь простейшего backend-сервиса на nodejs в целях самообразования. Мне очень импонирует возможность подключения модулей в JS-коде через import (ES6 modules), т.к. он позволяет использовать один и тот же код как в браузере, так и на серверной стороне, и я запилил простой сервис с ES6-модулями.

Если вкратце, то запустить ES6-версию приложения под pm2 у меня не получилось, для запуска таких приложений лучше использовать либо forever, либо systemd. Под катом — отчёт о результатах для тех, кто любит тексты подлинее.

Введение

В контексте данной публикации под менеджером процессов подразумевается сервис, основной задачей которого является мониторинг запущенного nodejs-приложения и его перезапуск в случае падения. Также менеджер процессов может (но не обязан) собирать информацию о потребляемых приложением ресурсах (процессор, память).

Тестовый сервис

Для тестирования менеджеров процессов я использовал вот такой код в ES6-сервисе (github repo):

# src/app_es6.mjs
import express from "express";
import mod from "./mod/es6.mjs";

const app = express();
const msg = "Hello World! " + mod.getName();

app.get("/", function (req, res) {
    console.log(msg);
    res.send(msg);
});

app.listen(3000, function () {
    console.log('ES6 app listening on port 3000!');
});

и в ES6-модуле:

# src/mod/es6.mjs
export default {
    getName: function () {
        return "ES6 module is here.";
    }
}

Аналогичный сервис, выполненный c CommonJS-модулями выглядит так:

# src/app_cjs.js
const express = require("express");
const mod = require("./mod/cjs.js");
const app = express();

const msg = "Hello World! " + mod.getName();

app.get("/", function (req, res) {
    console.log(msg);
    res.send(msg);
});

app.listen(3000, function () {
    console.log("CommonJS app listening on port 3000!");
});

CJS-модуль:

# src/mod/cjs.js
module.exports = {
    getName: function () {
        return "CommonJS module is here.";
    }
};

Запуск сервиса без использования менеджера процессов на nodejs v12.14.0:

$  node --experimental-modules ./src/app_es6.mjs    # ES6-service
$  node ./src/app_cjs.js    # CJS-service

pm2

pm2 на данный момент является лидером среди менеджеров процессов по предлагаемому функционалу (помимо поддержания процесса в рабочем состоянии также есть кластеризация, мониторинг использования ресурсов, различные стратегии рестарта процессов).

CJS-сервис запускается без проблем (pm2 v4.2.1):

$ pm2 start ./src/app_cjs.js -i 4

nodejs: менеджеры процессов и ES6-модули - 1

также без проблем поддерживается заданное количество экземпляров сервиса в кластере:

root@omen17:~# ps -Af | grep app_cjs
alex     29848 29828  0 15:31 ?        00:00:00 node /.../src/app_cjs.js
alex     29855 29828  0 15:31 ?        00:00:00 node /.../src/app_cjs.js
alex     29864 29828  0 15:31 ?        00:00:00 node /.../src/app_cjs.js
alex     29875 29828  0 15:31 ?        00:00:00 node /.../src/app_cjs.js

После "убийства" одного экземпляра (PID 29864) менеджер процессов сразу же поднял новый (PID 30703):

root@omen17:~# kill -s SIGKILL 29864
root@omen17:~# ps -Af | grep app_cjs
alex     29848 29828  0 15:31 ?        00:00:00 node /.../src/app_cjs.js
alex     29855 29828  0 15:31 ?        00:00:00 node /.../src/app_cjs.js
alex     29875 29828  0 15:31 ?        00:00:00 node /.../src/app_cjs.js
alex     30703 29828  7 15:35 ?        00:00:00 node /.../src/app_cjs.js

Но ES6-версия приложения не отрабатывает корректно в pm2. При передаче в nodejs аргумента "--experimental-modules":

$ pm2 start ./src/app_es6.mjs -i 4 --node-args="--experimental-modules"

получается вот такая картина:
nodejs: менеджеры процессов и ES6-модули - 2

В логах видим:

$ pm2 log
...
/home/alex/.pm2/logs/app-es6-error-2.log last 15 lines:
2|app_es6  |     at /usr/lib/node_modules/pm2/node_modules/async/internal/onlyOnce.js:12:16
2|app_es6  |     at WriteStream.<anonymous> (/usr/lib/node_modules/pm2/lib/Utility.js:186:13)
2|app_es6  |     at WriteStream.emit (events.js:210:5)
2|app_es6  |     at internal/fs/streams.js:299:10
2|app_es6  | Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: /home/alex/work/sof_es6_pm/src/app_es6.mjs
2|app_es6  |     at Object.Module._extensions..mjs (internal/modules/cjs/loader.js:1029:9)
2|app_es6  |     at Module.load (internal/modules/cjs/loader.js:815:32)
2|app_es6  |     at Function.Module._load (internal/modules/cjs/loader.js:727:14)
2|app_es6  |     at /usr/lib/node_modules/pm2/lib/ProcessContainer.js:297:23
2|app_es6  |     at wrapper (/usr/lib/node_modules/pm2/node_modules/async/internal/once.js:12:16)
2|app_es6  |     at next (/usr/lib/node_modules/pm2/node_modules/async/waterfall.js:96:20)
2|app_es6  |     at /usr/lib/node_modules/pm2/node_modules/async/internal/onlyOnce.js:12:16
2|app_es6  |     at WriteStream.<anonymous> (/usr/lib/node_modules/pm2/lib/Utility.js:186:13)
2|app_es6  |     at WriteStream.emit (events.js:210:5)
2|app_es6  |     at internal/fs/streams.js:299:10

То есть, по факту pm2 не может без транспиляции запускать скрипты, в которых используются ES6-модули. Последний issue на эту тему создан 5 декабря 2019 (примерно месяц назад).

forever

forever является следующим по популярности менеджером процессов после pm2 (npmtrends). Это более старый проект (начат в 2010 году против 2013 для pm2), но у него более узкий фокус по функциональности, чем у pm2. forever "заточен" на постоянное поддержание работоспособности процесса без всяких дополнительных pm2-плюшек в виде балансировки нагрузки и мониторинга используемых ресурсов. Судя по частоте коммитов проект находится в стабильном состоянии (фазу активного развития уже прошёл) и каких-то новых функций от него ждать не приходится. Я не нашёл способа передачи аргументов в nodejs из командной строки при запуске forever, но такая возможность есть, если использовать конфигурационный файл:

{
  "uid": "app_es6",
  "max": 5,
  "spinSleepTime": 1000,
  "minUptime": 1000,
  "append": true,
  "watch": false,
  "script": "src/app_es6.mjs",
  "command": "node --experimental-modules"
}

Запуск приложения в таком варианте выглядит так:

$ forever start forever.es6.json
...
$ forever list
info:    Forever processes running
data:        uid     command                     script          forever pid  id logfile                           uptime      
data:    [0] app_es6 node --experimental-modules src/app_es6.mjs 3972    3979    /home/ubuntu/.forever/app_es6.log 0:0:0:3.354 

Вот сами процессы:

$ ps -Af | grep es6
ubuntu    3972     1  0 12:01 ?        00:00:00 /usr/bin/node /usr/lib/node_modules/forever/bin/monitor src/app_es6.mjs
ubuntu    3979  3972  0 12:01 ?        00:00:00 node --experimental-modules /home/ubuntu/sof_es6_pm/src/app_es6.mjs

При "убийстве" процесса (PID 3979) менеджер исправно поднимает новый (PID 4013):

$ kill -s SIGKILL 3979
ubuntu@vsf:~/sof_es6_pm$ ps -Af | grep es6
ubuntu    3972     1  0 12:01 ?        00:00:00 /usr/bin/node /usr/lib/node_modules/forever/bin/monitor src/app_es6.mjs
ubuntu    4013  3972  4 12:10 ?        00:00:00 node --experimental-modules /home/ubuntu/sof_es6_pm/src/app_es6.mjs

forever прекрасно справляется с запуском приложения, использующего ES6-модули, но возникает вопрос, зачем тянуть на linux-системы forever, если подобной функциональности можно добиться и через средства самой ОС?

systemd

systemd позволяет создавать сервисы в linux-среде и контролировать их запуск, в том числе и в случае их внезапного падения. Достаточно создать unit-файл с описанием сервиса (./app_es6.service):

[Unit]
Description=Simple web server with ES6 modules.
After=network.target

[Service]
Type=simple
Restart=always
PIDFile=/run/app_es6.pid
WorkingDirectory=/home/ubuntu/sof_es6_pm
ExecStart=/usr/bin/nodejs --experimental-modules /home/ubuntu/sof_es6_pm/src/app_es6.mjs

[Install]
WantedBy=multi-user.target

и залинковать его в каталог /etc/systemd/system (в unit-файле пути должны быть абсолютными). За рестарт сервиса в случае его внезапного останова отвечает опция:

Restart=always

Запуск сервиса осуществляется так:

# systemctl start app_es6.service
# systemctl status app_es6.service 
● app_es6.service - Simple web server with ES6 modules.
   Loaded: loaded (/home/ubuntu/sof_es6_pm/app_es6.service; linked; vendor preset: enabled)
   Active: active (running) since Thu 2020-01-02 11:09:42 UTC; 9s ago
 Main PID: 2184 (nodejs)
    Tasks: 11 (limit: 4662)
   CGroup: /system.slice/app_es6.service
           └─2184 /usr/bin/nodejs --experimental-modules /home/ubuntu/sof_es6_pm/src/app_es6.mjs

Jan 02 11:09:42 vsf systemd[1]: Started Simple web server with ES6 modules..
Jan 02 11:09:42 vsf nodejs[2184]: (node:2184) ExperimentalWarning: The ESM module loader is experimental.
Jan 02 11:09:42 vsf nodejs[2184]: ES6 app listening on port 3000!

При "убийстве" процесса (PID 2184) systemd исправно поднимает новый (PID 2233):

# ps -Af | grep app_es6
root      2184     1  0 11:09 ?        00:00:00 /usr/bin/nodejs --experimental-modules /home/ubuntu/sof_es6_pm/src/app_es6.mjs
# kill -s SIGKILL 2184
# ps -Af | grep app_es6
root      2233     1  3 11:10 ?        00:00:00 /usr/bin/nodejs --experimental-modules /home/ubuntu/sof_es6_pm/src/app_es6.mjs

Т.е., systemd делает то же самое, что и forever, но на более фундаментальном уровне.

StrongLoop

При обзоре вариантов имплементаций менеджеров процессов часто всплывает StrongLoop. Однако очень сильно похоже, что этот проект перестал развиваться (последняя версия 6.0.3 вышла 3 года назад). Мне не удалось его даже установить на Ubuntu 18.04 через npm:

# npm install -g strongloop
npm WARN deprecated swagger-ui@2.2.10: No longer maintained, please upgrade to swagger-ui@3.
...
npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2020-01-02T11_25_15_473Z-debug.log

Через yarn пакет установился, несмотря на большое количество сообщений о deprecated версиях зависимостей и ошибок установки, тем не менее, от изучения StronLoop'а я отказался.

Инструменты разработчика

Очень часто рядом с pm2 и forever встречаются такие пакеты, как nodemon, watch, onchange. Эти инструменты не являются менеджерами процессов, но позволяют мониторить изменения в файлах и выполнять команды, привязанные к этим изменениям (в том числе, и перезапускать приложение).

Резюме

Менеджер процессов, подобный pm2, является очень полезным сервисом в мире серверного JS. Но, к сожалению, сам pm2 не позволяет запускать современные nodejs-приложения (в частности — с ES6-модулями). Так как я не очень люблю транспиляцию, то наиболее приемлемым на данный момент менеджером процессов в nodejs для меня является традиционный systemd (или его альтернативы). Однако я с радостью буду использовать pm2, как только pm2 сможет поддерживать приложения с ES6-модулями.

Автор: Alex Gusev

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js