Node.js设置，便于部署和更新 [英] Node.js setup for easy deployment and updating

查看：126 发布时间：2017/5/6 16:23:07 node.js deployment updates

本文介绍了Node.js设置，便于部署和更新的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

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

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

我仍然有几个问题要实现一个很好的设置：

客户很容易部署。这是非常重要的，因为我们的网站将被整合在他们的实时TYPO3安装中，它提供丰富的网站，并且运行在不受客户管理的服务器上，而另一个（集中式）组织则支持呼叫和服务器更改

应该很容易更新。如上所述，请求重新启动并进行服务器更改是一个缓慢的过程，所以理想的节点安装应该在使用 git 收到实时安装的更改时重新启动/更新。

部署

一般共识似乎是在部署节点应用程序以使其运行时使用 forever 。我已经测试了永远，并且当由 npm install forever -g （全局）安装时，它似乎工作正常。这将需要外部帮助来全局安装在实时环境中，所以我更希望它从应用程序的 node_modules 目录中运行，但是我还没有创建一个坚实的包装器来执行此操作。

此外，永远可以正常工作，但必须手动启动。什么是最好的方法来确保它开始服务器启动并持续运行？

一个简单的 init.d 脚本？

编写看门狗包装器

一个TYPO3调度程序任务，检查永远状态？

快速开发/重新启动更新

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

Nodemon

Node.js主管

退回

结节（不需要重新启动节点，因此可能更容易与永远）

上有没有人有任何经验？

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

集群模块通过重新加载机制提供类似的功能，但不适用于Node 0.5+ 。替换它的核心群集模块（Node 0.6+）不具备所有这些功能，但只有提供聚类。反过来不能很好地与socket.io 播放。至少不使用Redis （这对我们来说是一个问题，因为我们可以' t强制另一个prereq服务给客户）。

显然，我正在寻找最稳定的解决方案，它将update-restarter与在将项目交给客户之前，我们真的希望任何人已经产生了一个经过验证的技术组合， c $ c>永远

解决方案

结合所有收集的知识（非常感谢朱利安骑士，为想法）和方法，我已经决定解决下面描述的部署解决方案（我认为我很乐意分享帮助别人提出类似的问题）：

自动重新启动脚本错误和脚本更改的自动重新加载由> 永远，因为它还包括一个脚本手表，只要Forever从一个node.js脚本中产生。

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

server.js

  var forever = 'forever'），
 child = new（forever.Monitor）（'app.js'，{
'silent'：false，
'pidFile'：'pids / app.pid' ，
'watch'：true，
'watchDirectory'：'。'，//要观看的顶级目录。 
'watchIgnoreDotFiles'：true，//是否忽略点文件
'watchIgnorePatterns'：[]，//要忽略的glob模式数组，与watchDirectory +'/.foreverignore'文件的内容合并
'logFile'：'logs / forever.log'，//从forever进程记录输出的路径（当守护进程时）
'outFile'：'logs / forever.out'，//记录输出的路径从child stdout 
'errFile'：'logs / forever.err'
}）; 
 child.start（）; 
 forever.startServer（child）;

这是监视应用程序目录中的所有文件以进行更改，并重新启动在永远一旦更改。因为日志和pidfile位于应用程序的子目录中，所以必须从文件监视器中忽略这些脚本，否则脚本将重新启动：

.foreverignore

  pids / ** 
 logs / ** 
 为了使系统启动全部启动，我们可以使用 start node-app 和 stop node-app 我们使用 Ubuntu的Upstart 。 
我结合了两个示例（此和 
 
   /etc/init/node-app.conf  
 ＃这是一个upstart（http://upstart.ubuntu.com/）脚本
＃在系统启动时运行node.js服务器，并使其成为
＃可管理的命令，如
＃'start node-app'和'stop node-app'
＃
＃这个脚本放在/ etc / init中以配合upstart。 
＃
＃在内部使用'initctl'命令来管理：
＃initctl help 
＃initctl status node-app 
＃initctl reload node-app 
＃initctl start node-app 
 
 descriptionnode.js node-app的永久服务器
 authorRemco Overdijk< remco@maxserv.nl> 
版本1.0
 
 expect fork 
 
＃曾经是：启动时启动
＃直到我们发现一些挂载还没有准备好启动：
 
开始启动挂载
停止关闭
 
＃自动重新启动：
 respawn 
重新启动限制99 5 
 
 env HOME = / home / user / node-app-dir 
 
脚本
＃不知道为什么需要$ HOME，但是我们发现它是：
 export HOME = $ HOME 
 chdir $ HOME 
 exec / usr / local / bin / node server.js> logs / node.log& 
结束脚本
 
＃post-start脚本
＃＃可以在这里放一个脚本，这样可以让你节点重启
＃＃/ root / bin /hoptoad.shnode.js已经启动了！ 
 #end脚本
   As  Kevin在他的文章中明智地提到了以root身份运行节点是不明智的，所以我们将其更改为 exec sudo -u www-data / usr / local / bin / node 当我们下周搬到新服务器时。
 
 
 所以，永远通过由 upstart 启动的 node server.js 自动启动，并监视崩溃和文件更改，保持整个设置只要我们想要运行。
 
 
 我希望这有助于任何人。
 
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.

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.

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

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.
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.
Deployment

The general consensus seems to be to use forever when 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_modules directory, but I haven't been able to create a solid wrapper to do so.

Additionally, forever works 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? 


A simple init.d script?
Writing a watchdog wrapper?
A TYPO3 scheduler task that checks forever status?  


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 node or forever. This works, but is far from ideal.
There are several smaller npm modules that check for file modifications and restart node upon detected changes, like:


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


Does anyone have experience with any of these?

Update: Why don't you just use Cluster?

The Cluster module provides similar functionality through the reload mechanism, 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).  

--

Obviously I'm trying to find the most stable solution that combines an update-restarter with forever before handing over the project to the customer and I'm really hoping anyone has produced a proven combination of techniques.
 解决方案 
Combining all knowledge gathered (Big thanks to Julian Knight for 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):

Auto-restarting on script errors and automatic 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.

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

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);
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:

.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-app we use Ubuntu's Upstart.
I've combined two examples (this and this one) into one that does the job quite well:

/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
As Kevin wisely mentions in his article it's unwise to run node as root, so we'll change that to exec sudo -u www-data /usr/local/bin/node when we move to new servers next week.

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

I hope this helps anyone.

                        这篇关于Node.js设置，便于部署和更新的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！


                    
                        查看全文

Node.js设置，便于部署和更新 [英] Node.js setup for easy deployment and updating

问题描述

相关文章

其他开发最新文章

热门教程

热门工具

登录关闭

Node.js设置，便于部署和更新 [英] Node.js setup for easy deployment and updating

问题描述

相关文章

其他开发最新文章

热门教程

热门工具

登录 关闭

登录关闭