我们目前正在为一位客户开发网站(在Apache下使用TYPO3),该网站由一个node.js/socket.io应用程序支持,该应用程序提供实时更新到从CMS提供的内容。
由于这是我们的第一个node.js项目,因此在“完美设置”方面我没有任何最佳实践可供参考,所以我花了一些时间研究部署技术。
还有一些问题需要解决,以实现良好的设置:
1.易于客户部署。这非常重要,因为我们的网站将集成在他们的“现场”TYPO3安装中,该安装服务于大量网站,并且运行在由另一个(集中)组织管理而不是客户管理的服务器上,这使得支持调用和服务器更改变慢的过程。 2.应该容易更新。如上所述,请求重新启动和进行服务器更改是一个缓慢的过程,因此理想情况下,当它接收到通过git推送到live installion的更改时,node安装应该重新启动/更新。
部署 普遍共识似乎是在部署Node应用程序时使用
此外,
由于这是我们的第一个node.js项目,因此在“完美设置”方面我没有任何最佳实践可供参考,所以我花了一些时间研究部署技术。
还有一些问题需要解决,以实现良好的设置:
1.易于客户部署。这非常重要,因为我们的网站将集成在他们的“现场”TYPO3安装中,该安装服务于大量网站,并且运行在由另一个(集中)组织管理而不是客户管理的服务器上,这使得支持调用和服务器更改变慢的过程。 2.应该容易更新。如上所述,请求重新启动和进行服务器更改是一个缓慢的过程,因此理想情况下,当它接收到通过git推送到live installion的更改时,node安装应该重新启动/更新。
部署 普遍共识似乎是在部署Node应用程序时使用
forever
来保持其运行。我已经测试了forever
,当通过npm install forever -g
(全局)安装时,它似乎可以正常工作。但是,在现场环境中全局安装需要外部帮助,因此我更喜欢它从应用程序的node_modules
目录运行,但我还没有能够创建一个稳定的包装器来实现这一点。此外,
forever
可以正常工作,但必须手动启动。最好的方法是确保它在服务器启动时启动并保持运行状态?
- 一个简单的
init.d
脚本? - 编写看门狗包装器?
- 检查
forever
状态的TYPO3调度程序任务?
node
或forever
。这种方法虽然可行,但远非理想。
有几个较小的npm
模块可以检查文件修改并在检测到更改时重新启动node
,例如:
- Nodemon
- Node.js Supervisor
- Bounce
- Nodules(不需要重新启动node,因此可能更容易与
forever
组合使用) - Up
有没有人使用过其中任何一个?
更新:为什么不使用Cluster?
Cluster模块通过reload机制提供类似的功能,但不支持Node 0.5+。替代它的核心Cluster模块(Node 0.6+)只提供了集群功能,而没有这些特性。这反过来与socket.io不兼容。至少没有使用Redis是不行的(对我们来说是个问题,因为我们不能强制客户使用另一个先决条件服务)。
--
显然,我正在尝试找到一种最稳定的解决方案,将更新重启程序与forever
结合起来,然后将项目交给客户。我真的希望有人已经生产出了一种经过验证的技术组合。