Configuración de Node.js para fácil implementación y actualización

Question

Actualmente estamos desarrollando un sitio web (TYPO3 en Apache) para un cliente que es compatible con una aplicación node.js/socket.io que proporciona actualizaciones en tiempo real para el contenido servido desde el CMS.

Como este es nuestro primer proyecto node.js, no tengo ninguna de las mejores prácticas para realizar cuando se trata de "la configuración perfecta", así que he dedicado un tiempo a investigar las técnicas de implementación.

Un par de preguntas siguen siendo para mí para conseguir una buena puesta a punto, que:

1. es fácil para el cliente para desplegar. Esto es muy importante porque nuestro sitio web se integrará en su instalación "en vivo" de TYPO3 que sirve a una gran cantidad de sitios web y se ejecuta en servidores que no son administrados por el cliente sino otra organización (centralizada) que hace que las llamadas de soporte y el servidor cambien Proceso lento.

2. Debería ser fácil de actualizar. Como se mencionó, la solicitud de reinicios y la realización de cambios en el servidor es un proceso lento, por lo que la instalación del nodo debería reiniciarse/actualizarse cuando recibe cambios que se envían a la instalación activa usando git.

despliegue

El general consensus parece ser el uso de forever cuando se trata de la implementación de aplicaciones de nodo para que sigan funcionando. Probé forever, y parece funcionar bien cuando se instala por npm install forever -g (global). Sin embargo, esto requeriría asistencia externa para la instalación global en el entorno en vivo, por lo que preferiría tenerlo ejecutándose desde el directorio node_modules de la aplicación, pero no he podido crear un contenedor sólido para hacerlo.

Además, forever funciona bien, pero debe iniciarse manualmente. ¿Cuál sería el mejor enfoque para garantizar que se inicie en el arranque del servidor y siga funcionando?

• Un simple init.d script?
• Escribiendo un contenedor de perro guardián?
• ¿Una tarea del programador TYPO3 que comprueba el estado forever?

El rápido desarrollo/reinicio en la actualización

Actualmente estamos todavía en la etapa de desarrollo del proyecto y cada vez que realice cambios en la aplicación Node.js reinicio manualmente node o forever. Esto funciona, pero está lejos de ser ideal. Hay varios pequeños módulos npm que comprueban las modificaciones del archivo y reinicie node de los cambios detectados, como:

• Nodemon
• Node.js Supervisor
• Bounce
• Nodules (que no requiere reiniciar el nodo, por lo podría ser más fácil de combinar con forever)
• Up

¿Alguien tiene experiencia con alguno de estos?

Actualización: ¿Por qué no utiliza Cluster?

El Cluster module proporciona una funcionalidad similar a través del mecanismo reload, pero doesn't work with Node 0.5+. El core Cluster module (Node 0.6+) que lo reemplazó no tiene todas estas características, pero solo proporciona clustering. Que a su vez doesn't play well with socket.io. Al menos not without using Redis (que es un problema para nosotros, porque no podemos forzar otro servicio previo al cliente).

-

Obviamente, yo estoy tratando de encontrar la solución más estable que combina una actualización-restarter con forever antes de entregar el proyecto al cliente y realmente espero que nadie ha producido una combinación probada de técnicas.

Answer 1

Combinando todo el conocimiento recopilado (gracias a Julian Knight por las ideas) y los métodos probados la semana pasada, decidí conformarme con la solución de implementación que se describe a continuación (pensé que sería agradable compartirla para ayudar a otros con preguntas comparables):

Auto-reinicio de errores de script y de carga automática en el guión que cambia es manejado por forever, ya que también incluye un reloj de escritura, siempre y cuando siempre se genera desde dentro de un Node.js guión.

Para ello, he añadido un server.js para poner en marcha el guión app.js que realmente queremos para funcionar:

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

Esta relojes de todos los archivos en el directorio de la aplicación de cambia y reinicia el script que se ejecuta en forever tan pronto como se modifica. Debido a que los registros y pidfile están en subdirectorios de la aplicación, éstos tienen que ser ignorado desde el reloj de archivos o el guión te reinicia el bucle:

.foreverignore

pids/** 
logs/** 

Para hacer esto todo el comienzo de arranque del sistema y que nos permite controlar fácilmente el servicio utilizando start node-app y stop node-app usamos Ubuntu's Upstart. He combinado dos ejemplos (this y this uno) en uno que hace el trabajo bastante bien:

/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 

Como Kevin wisely mentions in his article es imprudente ejecutar el nodo como root, por lo que lo cambiaremos a exec sudo -u www-data /usr/local/bin/node cuando nos mudemos a nuevos servidores la próxima semana.

Así, forever se inicia automáticamente por node server.js que consigue lanzado por upstart y monitores para los accidentes y cambios en los archivos, manteniendo toda la instalación se ejecuta como el tiempo que queramos.

espero que esto ayude a.

Answer 2

Puede que esté mejor, para uso de producción, para ver algo como Cluster. Puede que no desee las características del clúster, pero también incluye otras características de producción, como reinicios cero de inactividad, registro, trabajadores, etc.

Como dices, Forever está bien para probar pero no tiene realmente lo que se necesita para la producción utilizar.

Creo recordar vagamente que clúster o algo similar puede adoptarse en el propio nodo vienen v0.7

Answer 3

Desde mi última respuesta es para el futuro! Éstos son algunos otros enlaces para ayudar:

• 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 (véase la diapositiva 35)
• http://www.slideshare.net/the_undefined/nodejs-in-production (31 desliza hasta el final)
• When node.js goes down, how can I bring it back up automatically?

No hace todavía parece ser una respuesta perfecta, pero hay muchas personas ejecutando instancias de Nodo de producción. Con suerte, esto lo orientará en la dirección correcta.