Node.js设置，易于部署和更新

一尘不染

Node.js设置，易于部署和更新

node.js

我们目前正在为一个客户开发一个网站（Apache下为TYPO3），该网站由node.js /
socket.io应用程序支持，该应用程序可实时更新CMS提供的内容。

由于这是我们的第一个node.js项目，因此在“完美设置”方面没有任何最佳实践，因此我花了一些时间研究部署技术。

对于我来说，要实现一个良好的设置还有两个问题：

易于客户部署 。这一点非常重要，因为我们的网站将集成到其“实时” TYPO3安装中，该安装可服务大量网站，并且运行在不是由客户管理的服务器上，而是由另一个（集中式）组织进行服务呼叫和服务器更改过程缓慢。
应该很容易更新。 如前所述，请求重新启动和更改服务器是一个缓慢的过程，因此，理想情况下，当节点安装收到使用推送到实时安装中的更改时，应重新启动/更新git。

部署方式

在普遍的共识似乎是使用forever，当涉及到部署节点的应用程序，防止他们逃跑。我已经测试过了forever，并且npm install forever-g（由（全局）安装）似乎工作正常。但是，这需要外部协助才能在实时环境中进行全局安装，因此，我希望从应用程序的node_modules目录中运行它，但是我无法创建一个可靠的包装器来执行此操作。

此外，forever工作正常，但必须手动启动。确保它在服务器启动时启动并保持运行的最佳方法是什么？

一个简单的init.d脚本？
写看门狗包装？
TYPO3调度程序任务会检查forever状态吗？

快速开发/更新后重启

目前，我们仍处于项目的开发阶段，每次对node.js应用程序进行更改时，我都会手动重启node或forever。这可行，但远非理想。有几个较小的npm模块，它们检查文件修改并node在检测到更改后重新启动，例如：

有人有经验吗？

更新：为什么不只使用群集？

该集群模块通过提供类似的功能重载机制，但不与节点0.5+工作。替换它的核心集群模块（节点0.6+）不具有所有这些功能，而仅提供集群。反过来，这在socket.io中效果不佳。至少不是没有使用Redis（这对我们来说是个问题，因为我们不能向客户强制提供其他先决条件服务）。

显然，forever在将项目交付给客户之前，我试图找到一种结合了更新重启程序的最稳定的解决方案，并且我真的希望任何人都能产生出经过验证的技术组合。

阅读 259

2020-07-07

共1个答案

一尘不染

结合过去一周内收集的所有知识和经过测试的方法，我决定选择以下所述的部署解决方案（我想与其他人分享类似的问题，我很乐意为他人提供帮助））：

只要脚本是在node.js脚本中生成的， forever
就可以自动处理脚本错误并在脚本更改时自动重新加载，因为它还包括脚本监视功能。
****

为此，我添加了一个server.js启动app.js我们实际上要运行的脚本：

server.js

var forever = require('forever'),
    child = new(forever.Monitor)('app.js', {
        'silent': false,
        'pidFile': 'pids/app.pid',
        'watch': true,
        'watchDirectory': '.',      // Top-level directory to watch from.
        'watchIgnoreDotFiles': true, // whether to ignore dot files
        'watchIgnorePatterns': [], // array of glob patterns to ignore, merged with contents of watchDirectory + '/.foreverignore' file
        'logFile': 'logs/forever.log', // Path to log output from forever process (when daemonized)
        'outFile': 'logs/forever.out', // Path to log output from child stdout
        'errFile': 'logs/forever.err'
    });
child.start();
forever.startServer(child);

这将监视应用程序目录中的所有文件的更改，并在更改一次后重新启动运行的脚本forever。由于日志和pidfile位于应用程序的子目录中，因此必须从文件监视中忽略它们，否则脚本将循环重启：

.foreverignore

pids/**
logs/**

为了使这一切在系统启动时启动，并使我们能够轻松地使用来控制服务start node-app，stop node- app我们使用Ubuntu的Upstart。我将两个示例（这个和这个例子）组合在一起，可以很好地完成工作：

/etc/init/node-app.conf

# This is an upstart (http://upstart.ubuntu.com/) script
# to run the node.js server on system boot and make it
# manageable with commands such as
# 'start node-app' and 'stop node-app'
#
# This script is to be placed in /etc/init to work with upstart.
#
# Internally the 'initctl' command is used to manage:
# initctl help
# initctl status node-app
# initctl reload node-app
# initctl start node-app

description "node.js forever server for node-app"
author      "Remco Overdijk <remco@maxserv.nl>"
version "1.0"

expect fork

# used to be: start on startup
# until we found some mounts weren't ready yet while booting:

start on started mountall
stop on shutdown

# Automatically Respawn:
respawn
respawn limit 99 5

env HOME=/home/user/node-app-dir

script
    # Not sure why $HOME is needed, but we found that it is:
    export HOME=$HOME
    chdir $HOME
    exec /usr/local/bin/node server.js > logs/node.log &
end script

#post-start script
#   # Optionally put a script here that will notifiy you node has (re)started
#   # /root/bin/hoptoad.sh "node.js has started!"
#end script

正如Kevin在他的文章中明智地提到的那样，以root身份运行节点是不明智的，因此我们将其更改为exec sudo -u www-data /usr/local/bin/node下周移至新服务器的时间。

因此，forever会自动启动node server.js，由来启动upstart，并监视崩溃和文件更改，从而使整个设置始终保持运行所需的时间。

我希望这对任何人都有帮助。

2020-07-07