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

Node.js setup for easy deployment and updating

提问by Rem.co

We're currently developing a website (TYPO3 under Apache) for a customer that is supported by a node.js/socket.io application that provides realtime updates to the content served from the CMS.

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

As this is our first node.js project I don't have any best practices to go by when it comes to 'the perfect setup' so I've spent some time researching deployment techniques.

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

A couple of questions remain for me to achieve a good setup which:

要实现良好的设置，我还有几个问题需要解决：

1. Is easy for the customer to deploy. This is very important because our website will be integrated in their 'live' TYPO3 installation which serves an abundance of websites and is running on servers which aren't managed by the customer but another (centralized) organization which makes support calls and server changes a slow process.

2. Should be easy to update.As mentioned requesting restarts and making server changes is a slow process, so idealy the node installation should restart / update when it receives changes that are pushed onto the live installion using git.

1. 便于客户部署。这非常重要，因为我们的网站将集成到他们的“实时”TYPO3 安装中，该安装为大量网站提供服务，并在不由客户管理的服务器上运行，而是另一个（集中式）组织，该组织可拨打支持电话和更改服务器缓慢的过程。

2. 应该很容易更新。如前所述，请求重新启动和进行服务器更改是一个缓慢的过程，因此理想情况下，节点安装应在收到使用git.

Deployment

部署

The general consensusseems to be to use foreverwhen it comes to deploying node applications to keep them running. I've tested forever, and it seems to work fine when installed by npm install forever -g(global). This would require external assistance to globally install on the live environment though, so I'd prefer to have it running from the application's node_modulesdirectory, but I haven't been able to create a solid wrapper to do so.

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

Additionally, foreverworks fine, but it has to be started manually. What would be the best approach to ensure that it gets started on server boot and keeps running?

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

• A simple init.dscript?
• Writing a watchdog wrapper?
• A TYPO3 scheduler task that checks foreverstatus?

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

Rapid development / Restart on update

快速开发/更新时重启

We're currently still in the development stage of the project and every time I make changes to the node.js application I manually restart nodeor forever. This works, but is far from ideal. There are several smaller npmmodules that check for file modifications and restart nodeupon detected changes, like:

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

• Nodemon
• Node.js Supervisor
• Bounce
• Nodules(which doesn't require restarting node, so might be easier to combine with forever)
• Up

• 节点兽
• Node.js 主管
• 弹跳
• 结节（不需要重新启动节点，因此可能更容易与 结合forever）
• 向上

Does anyone have experience with any of these?

有没有人有过这些方面的经验？

Update: Why don't you just use Cluster?

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

The Cluster moduleprovides similar functionality through the reloadmechanism, but doesn't work with Node 0.5+. The core Cluster module (Node 0.6+)that replaced it doesn't have all these features but only provides clustering. Which in turn doesn't play well with socket.io. At least not without using Redis(which is a problem for us, because we can't force another prereq service to the customer).

该集群模块通过提供类似的功能重载机制，但不与节点0.5+工作。取代它的核心集群模块（Node 0.6+）没有所有这些功能，但只提供集群。这反过来又不能很好地与 socket.io 配合使用。至少在不使用 Redis 的情况下不会（这对我们来说是个问题，因为我们不能强制向客户提供另一个 prereq 服务）。

--

——

Obviously I'm trying to find the most stable solution that combines an update-restarter with foreverbefore handing over the project to the customer and I'm really hoping anyone has produced a proven combination of techniques.

显然，我正在尝试找到最稳定的解决方案，forever在将项目移交给客户之前，将更新重新启动器与更新重新启动器相结合，我真的希望任何人都能够制作出经过验证的技术组合。

回答by Rem.co

Combining all knowledge gathered (Big thanks to Julian Knightfor the ideas) and methods tested in the past week, I've decided to settle for the deployment solution described below (I thought I'd be nice to share to help others with comparable questions):

结合所有收集的知识（非常感谢Julian Knight的想法）和过去一周测试的方法，我决定采用下面描述的部署解决方案（我想我很乐意分享以帮助其他人解决类似问题)：

Auto-restarting on script errors andautomatic reloading on script changes is handled by forever, as it also includes a script watch, as long as Forever is spawned from within a node.js script.

脚本错误时的自动重启和脚本更改时的自动重新加载由forever处理 ，因为它还包括脚本监视，只要 Forever 是从 node.js 脚本中生成的。

To do so, I've added a server.jsto launch the app.jsscript we actually want to run:

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

server.js

服务器.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);

This watches all files in the application directory for changes and restarts the script running in foreveras soon as one changes. Because the logs and pidfile are in subdirectories of the application, those have to be ignored from the file watch, or the script will loop restarts:

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

.foreverignore

.永远忽略

pids/**
logs/**

To make this all start on system boot and enabling us to easily control the service using start node-appand stop node-appwe use Ubuntu's Upstart. I've combined two examples (thisand thisone) into one that does the job quite well:

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

/etc/init/node-app.conf

/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 <[email protected]>"
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

As Kevin wisely mentions in his articleit's unwise to run node as root, so we'll change that to exec sudo -u www-data /usr/local/bin/nodewhen we move to new servers next week.

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

So, forevergets started automatically by node server.jswhich gets launched by upstart, and monitors for crashes and file changes, keeping the entire setup running as long as we want.

因此，forever由node server.jswhich启动自动启动upstart，并监控崩溃和文件更改，让整个设置在我们需要的时间内运行。

I hope this helps anyone.

我希望这可以帮助任何人。

回答by Julian Knight

Since my last answer is for the future! Here are some other links to assist:

因为我的最后一个答案是为了未来！这里有一些其他链接可以提供帮助：

• https://serverfault.com/questions/274857/how-to-use-node-js-as-a-production-web-server
• http://www.slideshare.net/the_undefined/nodejs-best-practices-10428790(see slide 35)
• http://www.slideshare.net/the_undefined/nodejs-in-production(slides 31 to the end)
• When node.js goes down, how can I bring it back up automatically?

• https://serverfault.com/questions/274857/how-to-use-node-js-as-a-production-web-server
• http://www.slideshare.net/the_undefined/nodejs-best-practices-10428790（见幻灯片 35）
• http://www.slideshare.net/the_undefined/nodejs-in-production（幻灯片 31 到最后）
• 当 node.js 出现故障时，如何自动将其恢复？

There doesn't yet seem to be a perfect answer but there are plenty of people running production Node instances. Hopefully this will point you in the right direction.

似乎还没有一个完美的答案，但有很多人在运行生产节点实例。希望这将为您指明正确的方向。

回答by Julian Knight

You might be better off, for production use, to look at something like Cluster. You might not want the cluster features but it also includes other production features such as zero downtime restarts, logging, workers, etc.

对于生产用途，您最好查看Cluster 之类的东西。您可能不需要集群功能，但它还包括其他生产功能，例如零停机重启、日志记录、工作程序等。

As you say, Forever is OK for testing but doesn't really have what it takes for production use.

正如您所说，Forever 可以用于测试，但实际上并不具备生产使用所需的功能。

I seem to vaguely remember that Cluster or something similar may be adopted into Node itself come v0.7

我似乎依稀记得，Cluster 或类似的东西可能会被采用到 Node 本身来 v0.7