route node javascript deployment node.js production-environment

javascript - route - Despliegue de un servidor Node.js de producción



node js install (6)

Escribí una aplicación Node.js, estoy buscando que funcione en una de nuestras máquinas de producción. Esto parece una petición bastante común, pero no puedo encontrar una solución adecuada. ¿No hay soluciones establecidas para implementar aplicaciones de producción Node.js?

La aplicación es simple (<100 LOC), pero necesita ser muy eficiente, confiable y funcionar continuamente durante años sin reiniciar. Se ejecutará en un sitio grande, con docenas de conexiones / segundo. (la aplicación no se usa como un servidor web, solo tiene una API JSON)

Estos son los enfoques que he considerado, pero todavía no estoy seguro de:

Usando un marco (por ejemplo, Express)

Debido a que la aplicación necesita ser de alto rendimiento y es tan simple, agregar algo en forma de marco es algo que quiero evitar.

Iniciando el servidor con nohup

El principal problema aquí es con el manejo de excepciones, nosotros (obviamente) no queremos que todo el servidor falle debido a una excepción. Por lo que entiendo, envolver toda la aplicación en un ciclo try {} catch {} no ayudará porque el intérprete de Javascript se queda en un estado impredecible después de una excepción. ¿Es eso correcto?

Usando algo como Forever

Instalé Forever en una máquina FreeBSD nuestra y fue muy defectuoso. Terminó generando procesos interminables que no podían ser eliminados de Forever. Tuve que ejecutar kill -9 para recuperar mi máquina y no me siento demasiado seguro para ejecutar una aplicación de producción en Forever. También parece que Upstart (herramienta similar, pero más genérica) no se ejecutará en FreeBSD.

Soluciones alojadas (p. Ej., Heroku, Rackspace, Amazon EC2, etc.)

Esta es probablemente la solución más simple, pero ya tenemos un hardware serio para el resto de nuestros servidores web. Por consideraciones financieras, no tiene sentido.

Seguramente debe haber alguna solución establecida para esto? ¿Me estoy perdiendo de algo?

Aquí hay tres preguntas, creo.

Pregunta 0: "¿Debo usar un marco para mi aplicación de nodo?"

Pregunta 1: "¿Cómo ejecuto los servidores de nodos en las máquinas de producción?"

Pregunta 2: "¿Cómo despliegue las aplicaciones de nodo en la producción?".

Para la Pregunta 1 , realmente me gusta Cluster (aunque la última versión de Node tiene algo así como incorporado, así que puedes comprobarlo). He tenido éxito con algo como Monit / Upstart para monitorear eventos de nivel de sistema operativo y asegurarme de que sus servidores estén en buen estado. (Esto supervisaba N clusters de servidores Ruby Thin, pero lo mismo).

Dependiendo del tráfico, es posible que desee ejecutar el clúster en varias máquinas, y luego poner un equilibrador de carga en frente de eso. Esto depende de su tráfico, de cuánto tardan las solicitudes en completarse / cuánto tiempo se bloquea el ciclo de eventos, y de cuántas instancias de procesadores / nodos se inician por máquina.

Un marco te ofrece un mejor manejo de errores y detecta errores que saldrían de las aplicaciones normales de node.js. Si lo hace sin un marco, asegúrese de leer sobre el manejo de errores en node.js.

Para la Pregunta 2 , no creo que la comunidad de nodos tenga un buen estándar de implementación todavía. Podría intentar usar la herramienta Capistrano de Ruby (y aquí hay una entrada de blog que habla sobre la implementación de clúster con Capinstrano ).

Lo malo de Capistrano es que hace algunas suposiciones que pueden no ser ciertas (es decir, que estás implementando un proyecto de Rails), por lo que puedes terminar peleando mucho con el framework.

Mi solución de implementación goto en general es la herramienta Fabric de Python, que le brinda herramientas de implementación y le permite hacer lo que necesita hacer.

Otra opción de implementación es "la nube", con cosas como Nodester : Nodester que se encarguen de eso.

Es posible que obtenga mejores respuestas en ServerFault, pero aquí hay una descripción de la experiencia de un usuario utilizando supervisord . Necesitarás usar algún tipo de observador de procesos para mantener vivo el proceso del node , y otra recomendación común parece ser la de las conexiones de proxy inverso al proceso del node alguna manera. Probablemente votaría por nginx (de esta manera puedes hacer que nginx maneje el registro, la autenticación o cualquier otra característica HTTP de nivel superior que necesites en lugar de unirlos de algún modo al nodo), pero el artículo mencionado menciona haproxy en los comentarios aquí y allí que puede ser más ligero. Su elección de proxy inverso probablemente dependerá en gran medida de si necesita o no compatibilidad con WebSocket.

No estoy seguro de que exista más flujo de trabajo "estándar" para el nodo por el momento; no es tan maduro como algo como Rails que tiene una gran cantidad de formas de mantener una aplicación web en funcionamiento.

Los chicos de Cloudkick escribieron una excelente solución para esto. Se llama Cast , http://cast-project.org/ .

Instale cast en su servidor y en su estación de trabajo. Usted inicia el agente de reparto en el servidor y hace que su estación de trabajo firme con la instancia de lanzamiento de servidores. A continuación, puede crear "paquetes", subirlos al servidor, crear / actualizar / destruirlos, así como iniciar / detener sus instancias. Cast automáticamente reiniciará sus servicios cuando se bloqueen. También puede rastrear stdout / strerr de forma remota, así como obtener una lista de las instancias en ejecución y los números PID y administrar sus instancias / servidores desde su estación de trabajo (no se requiere SSHing). Los documentos están un poco desactualizados, pero los resultados valen la pena un poco de trabajo extra. Todas las interacciones / comandos son a través de HTTPS y una API RESTful.

Antes de esto, estaba haciendo todas las actualizaciones a mano con SCP / SSH. Hemos supervise mantener las cosas. No hemos mirado atrás.

Ver aplicaciones de nodo de alojamiento .

Este tutorial lo guiará en la configuración de un servidor que pueda alojar aplicaciones node.js para aplicaciones de JavaScript del lado del servidor. En este momento, las opciones de alojamiento de node.js se reducen a ejecutar procesos de daemon de nodos que hablan con un servidor web. La mayoría de los servidores web pueden conectar por proxy a un puerto diferente, por lo que podrá utilizar Apache o nginx para hacerlo.

  • Realmente deberías usar un framework (recomiendo algo como Express ya que fue probado en batalla) a menos que quieras manejar sesiones, cookies, middleware, etc. por ti mismo. Express es muy ligero.
  • Iniciando el servidor con nohup: no debería hacer eso, simplemente comience con el comando regular "node". También Express ajusta las rutas en un try-catch, por lo que su servidor no se bloqueará en una ruta. Sin embargo, si su servidor tiene un problema grave, no debe temer reiniciarlo (además, si tiene 2-3 procesos al menos, solo uno morirá, por lo que habrá al menos 1-2 restantes y el usuario ganó '' siento algo).
  • Para el monitoreo, personalmente prefiero algo más en el nivel del sistema operativo, como Upstart y Monit .
  • Solución de alojamiento: ya que tiene sus propias cosas serias de hardware, no necesita invertir dinero en otra cosa. Simplemente use un equilibrador de carga (tal vez nginx o node-http-proxy) para proxy.