Mucho se viene hablando últimamente de sistemas distribuidos y basados en eventos, principalmente para aplicaciones web. Se ha hablado mucho de Twisted y Event Machine entre otros, pero la gran estrella naciente es -sin duda- Node.js. Node.js es muy eficiente a la hora de realizar procesos basados en eventos y lo mejor de todo es que un proceso jamás bloquea a los demás. Aclaro que aún así se pueden escribir aplicaciones en Node.js que sean capaces de bloquear procesos, pero en este caso utilizar Node.js habrá perdido todo el sentido.

El título de este artículo sigue el argumento básico de que si una empresa quiere tener un producto -en producción- este ha de ser lo más estable y confiable posible. A lo largo de los años he visto aplicaciones que se caen apenas reciben un pequeño aumento de tráfico, cosa que se debe a muchos factores aparte de malas prácticas a la hora de escribir código. Poner una aplicación en producción siempre es una cosa delicada y hay que cuidar todos los aspectos para que las cosas salgan como esperamos y -más aún- se mantengan estables sin importar la cantidad de tráfico que pueda venir.

El diablo está en los detalles.

Pues bien, desarrollar con Node.js no tiene mayor misterio; es básicamente JavaScript, sin más. Como siempre, existen librerías que lo hacen todo mucho más fácil. No voy a hablar en detalle de esas librerías aquí, para eso ya escribiré otro artículo. Lo que me interesa explicar ahora es como poner en producción una aplicación de Node.js sin que todo se nos venga encima (y sin hacer que nos despidan).

Voy a asumir que se tiene ya todo instalado y funcionando y que estamos trabajando con un sistema operativo Linux. En mi caso es Debian.

En vista de que nuestro código puede (y debe) cambiar con el tiempo, lo primero es que tengamos configurado un repositorio de donde podamos obtener el código fácilmente cuando hayan actualizaciones. Esto principalmente para evitar el engorroso asunto de tener que mover todos los ficheros que hayan sido cambiados desde nuestra estación de trabajo al servidor. Con repositorio la cosa es bastante más simple; ya se encarga él de descargar solo los archivos que hayan sufrido cambios, además que es mucho más sencillo volver al estado anterior si es que algo ha salido mal.

Supongamos entonces que ya tenemos todo listo; Node.js está instalado, nuestro repositorio está configurado y hemos descargado la versión más reciente del código. En caso de que tu proyecto utilice algún tipo de base de datos, esta ha de estar ejecutándose también y asegúrate de tener los controladores necesarios para que tu aplicación se pueda comunicar con la misma. (Si necesitas una base de datos rápida y fiable, entonces MongoDB puede ser una excelente opción.)

¿Cómo ejecutar mi applicación?

Para este ejemplo vamos a asumir que toda la aplicación está en un directorio llamado “aplicacion” en /var/www/aplicacion/

$> cd /var/www/aplicacion

Es también recomendable tener un usuario especifico (con permisos limitados) que sea quien corra nuestros procesos de Node.js. Agregar un usuario es bastante simple y se puede resumir con:

sudo adduser \\
    --system \\
    --shell /bin/bash \\
    --gecos 'Usuario para projectos de Node.js' \\
    --group \\
    --disabled-password \\
    --home /home/node \\
    node

En otro artículo cubriré los detalles de ejecutar una aplicación Node.js bajo otro usuario (y con privilegios limitados).

Generalmente los servidores responden a peticiones TCP en el puerto 80, no obstante para poder asociar algo, en este caso nuestra aplicación, al puerto 80 se requieren privilegios administrativos y darle este tipo de privilegios a una aplicación nunca es una buena idea. Para este ejemplo, he utilizado Express.js:

var express = require('express');
var app = express();

app.get('/', function(req, res){
  res.send('Esta es mi aplicación.');
});

app.listen(80);

Aquí, en vista de que la aplicación “escucha” en el puerto 80, se podría fácil -y tentativamente hacer esto:

$> sudo node app.js

No, no, no. Las aplicaciones no tienen por que tener privilegios administrativos.

Lo correcto sería hacer que la aplicación pueda correr en cualquier momento y en un puerto que no necesite privilegio alguno. Cualquier puerto por encima de 1000 vendrá bien. Para el ejemplo voy a utilizar el puerto 9090.

var express = require('express');
var app = express();

app.get('/', function(req, res){
  res.send('Esta es mi aplicación.');
});

app.listen(9090);

y ahora

$> node app.js

Abrimos el navegador e ingresamos la dirección del servidor y el puerto 9090. Si estamos trabajando a nivel local, simplemente con escribir http://localhost:9090 será suficiente. Deberíamos ver el mensaje: “Esta es mi aplicación.”

¡Muy bien! Ya tenemos nuestra aplicación funcionando. Lo siguiente es enviar todo el tráfico del puerto 80 al puerto 9090, que es en donde “escucha” nuestra aplicación.

Importante: Para que nuestra aplicación sepa que se tiene que ejecutar en modo de producción, debemos definir la variable de entorno correspondiente antes de ejecutarla:

$> NODE_ENV=production node app.js

En este caso, sin embargo, el proceso se asocia a nuestra sesión SSH, es decir que “morirá” en cuanto nos desconectemos del servidor. Para esto hay que recurrir a otra soluciones que se indicarán en detalle en otro artículo. (Revisa las últimas líneas de este artículo para posibles pistas.) Cade destacar, también, que hay casos en los que una variable de entorno (ENV) no queda definida si se hace como sudo, principalmente por razones de seguridad. En este caso, Node.js no puede leer la variable al ejecutar el proceso ya que la misma ya habrá sido borrada o puesta en su estado por defecto.

Dicho esto, nunca hagas:

$> sudo NODE_ENV=production node app.js

¿Cómo enviar el tráfico de un puerto a otro?

Para esto también hay más de una opción. Lo más sencillo es utilizar el firewall que viene por defecto en la mayoría de sistemas operativos Linux; iptables. Podemos dar una instrucción muy simple y la cosa queda resuelta, sin embargo esa no es la mejor alternativa, con lo cual no la voy a explicar.

Mi opción favorita para enviar tráfico de un puerto a otro es nginx. Nginx es un servidor con grandes cualidades y que puede darnos una mano muy grande a la hora de poner nuestras aplicaciones de Node.js en producción. Nginx puede hacer las veces de proxy inverso, cache, balanceador, servidor web y servidor de archivos estáticos. Node.js también puede servir archivos estáticos (.css, .js, .txt, etc.) pero no es tan eficiente como nginx.

Pues bien, vamos a instalar nginx (Las instrucciones originales en inglés están aquí):

Lo primero que tenemos que hacer es añadir la firma del repositorio de nginx para evitar los mensajes de error y sobre firmas incorrectas durante la instalación de los paquetes. La firma se puede descargar desde aquí y lo más fácil es hacer esto:

$> wget http://nginx.org/keys/nginx_signing.key
$> sudo apt-key add nginx_signing.key

También tenemos que añadir la dirección del repositorio de nginx a nuestra lista de repositorios local. Los paquetes de nginx están disponibles para la versión 6 de Debian, que tiene por nombre squeeze. Con tu editor favorito (vim en mi caso) abre el archivo de repositorios: /etc/apt/sources.list y añade estas dos líneas al final:

deb http://nginx.org/packages/debian/ squeeze nginx
deb-src http://nginx.org/packages/debian/ squeeze nginx

Finalmente:

$> sudo apt-get update
$> sudo apt-get install nginx

Abrimos el navegador e ingresamos la dirección del servidor, no hace falta especificar un puerto ya que el 80 es el puerto por defecto. Deberíamos ver una página de nginx. Si no vemos dicha página o aparece un error de que la página no puede ser cargada, intentamos con reiniciar nginx:

$> sudo /etc/init.d/nginx stop
$> sudo /etc/init.d/nginx start

Ya tenemos lo que necesitamos; nuestra aplicación ejecutándose y “escuchando” en el puerto 9090 y nginx “escuchando” en el puerto 80. Lo siguiente es hacer que el tráfico sea enviado a nuestra aplicación desde nginx. Necesitamos modificar la configuración de nginx. Con tu editor favorito abre el archivo /etc/nginx/nginx.conf

user nginx;
worker_processes 1;

error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for"';

    access_log /var/log/nginx/access.log  main;

    sendfile on;
    keepalive_timeout  65;

    include /etc/nginx/sites-enabled/*;
    include /etc/nginx/conf.d/*.conf;
}

En este caso mi archivo es muy básico. Se pueden incluir muchas más opciones globales, como por ejemplo compresión, cache y demás, pero para este ejemplo lo vamos a saltar. En cualquier caso es preferible definir ciertas configuraciones a nivel local, es decir para cada sitio virtual. Para poder tener varios sitios virtuales, necesitamos incluir la línea correspondiente en el archivo:

include /etc/nginx/sites-enabled/*;

Ahora, cada vez que nginx se inicie, cargará todos los archivos que encuentre dentro de /etc/nginx/sites-enabled/

El directorio antes mencionado no existe, de modo que lo vamos a crear y dentro del mismo definir nuestros archivos de configuración para los sitios virtuales:

$> sudo mkdir /etc/nginx/sites-available
$> sudo mkdir /etc/nginx/sites-enabled

El primer directorio contendrá todas las configuraciones (sitios virtuales) y el segundo únicamente las que estén activas en un determinado momento. Esta estructura está inspirada en la utilizada por Apache, que en su caso llama “virtual hosts” a cada uno de los sitios.

Vamos entonces a crear un archivo para nuestra aplicación. En /etc/nginx/sites-available/ vamos a crear un archivo llamado “aplicacion” con este contenido:

upstream aplicacion_node {
    server 127.0.0.1:9090;
}

server {
    listen  80;
    server_name aplicacion;

    access_log logs/aplicacion.access.log main;

    location / {
        root /var/www/aplicacion/public;

        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_redirect off;

        if (!-f $request_filename) {
            proxy_pass http://aplicacion_node;
            break;
        }
    }
}

Las primeras líneas definen a donde se enviará el tráfico entrante. Esto funciona en conjunto con la configuración proxy que está más abajo. En este caso queremos que nginx envíe nuestro tráfico al puerto 9090, que es en donde tenemos nuestra aplicación Node.js.

La línea root /var/www/aplicacion/public; le indica a nginx en donde están los archivos estáticos, de manera que cualquier solicitud es enviada directamente allá sin tener que pasar primero por nuestra aplicación. Esto alivia el trabajo de Node.js y además le permite a nginx hacer un mejor trabajo, pudiendo también guardar temporalmente los archivos en cache para un mejor rendimiento.

La última sección:

if (!-f $request_filename) {
    proxy_pass http://aplicacion_node;
    break;
}

Le indica a nginx que si la petición no es para un archivo, entonces que envíe el tráfico a nuestra aplicación, que, en este caso, se llama “aplicacion_node”.

En vista de que hemos creado nuestra aplicación en el directorio /etc/nginx/sites-available/ y en la configuración le hemos indicado a Nginx que utilice los archivos que encuentre en /etc/nginx/sites-enabled/, tenemos que crear un enlace simbólico desde un sitio al otro. Para eso hacemos esto:

$> cd /etc/nginx/sites-enabled/
$> sudo ln -s /etc/nginx/sites-available/aplicacion aplicacion

Tenemos que reiniciar nginx para que la nueva configuración entre en acción:

$> sudo /etc/init.d/nginx stop
$> sudo /etc/init.d/nginx start

Cualquier error de configuración aparecerá durante el proceso de arranque. Si todo ha ido bien, entonces podemos abrir nuestro navegador e ingresar la dirección de nuestro servidor sin puerto (80 por defecto). Veremos el mensaje “Esta es mi aplicación.”

¡Todo listo! Hay muchos aspectos que no he cubierto en este artículo. No obstante, escribiré una segunda parte cubriendo muchos otros aspectos que son importantes para (evitar que nos despidan) poner nuestras aplicación de Node.js en producción. Para los que no puedan esperar, aquí hay un par de sugerencias: Monit, Upstart, Forever.

Aquí está la continuación.