Node.js
Uso de IISNode para alojar aplicaciones web Node.js en IIS

Observaciones

`res.render('index', { virtualDirPath: virtualDirPath });`

Empezando

IISNode permite que las aplicaciones web Node.js se alojen en IIS 7/8 como lo haría una aplicación .NET. Por supuesto, puede auto hospedar su proceso node.exe en Windows, pero ¿por qué hacerlo cuando puede ejecutar su aplicación en IIS?

IISNode se encargará de escalar varios núcleos, administrará el proceso de node.exe y reciclará automáticamente su aplicación IIS cada vez que se actualice su aplicación, solo por mencionar algunos de sus beneficios .

Requerimientos

IISNode tiene algunos requisitos antes de poder alojar su aplicación Node.js en IIS.

1. Node.js debe estar instalado en el host IIS, ya sea de 32 bits o de 64 bits, ya sea compatible.
2. IISNode instaló x86 o x64 , esto debería coincidir con el bitness de su host IIS.
3. El módulo Microsoft URL-Rewrite Module para IIS instalado en su host IIS.
   • Esta es la clave, de lo contrario, las solicitudes a su aplicación Node.js no funcionarán como se espera.
4. Un Web.config en la carpeta raíz de su aplicación Node.js.
5. Configuración de IISNode a través de un archivo iisnode.yml o un elemento <iisnode> dentro de su Web.config .

Ejemplo básico de Hello World usando Express

Para que este ejemplo funcione, deberá crear una aplicación IIS 7/8 en su host IIS y agregar el directorio que contiene la aplicación web Node.js como el Directorio físico. Asegúrese de que la identidad de su grupo de aplicaciones / aplicación pueda acceder a la instalación de Node.js. Este ejemplo utiliza la instalación de 64 bits de Node.js.

Proyecto Strucure

Esta es la estructura básica del proyecto de una aplicación web IISNode / Node.js. Parece casi idéntico a cualquier aplicación web que no sea IISNode, excepto por la adición de Web.config .

- /app_root
  - package.json
  - server.js
  - Web.config

server.js - Aplicación Express

const express = require('express');
const server = express();

// We need to get the port that IISNode passes into us 
// using the PORT environment variable, if it isn't set use a default value
const port = process.env.PORT || 3000;

// Setup a route at the index of our app    
server.get('/', (req, res) => {
    return res.status(200).send('Hello World');
});

server.listen(port, () => {
    console.log(`Listening on ${port}`);
});

Configuración y Web.config

El Web.config es como cualquier otro Web.config IIS, excepto que las dos cosas siguientes deben estar presentes, URL <rewrite><rules> y un IISNode <handler> . Ambos de estos elementos son hijos del elemento <system.webServer> .

Configuración

Puede configurar IISNode utilizando un archivo iisnode.yml o agregando el elemento <iisnode> como un elemento secundario de <system.webServer> en su Web.config . Ambas configuraciones se pueden usar en conjunto, sin embargo, en este caso, Web.config deberá especificar el archivo iisnode.yml Y cualquier conflicto de configuración se eliminará del archivo iisnode.yml lugar . Esta anulación de la configuración no puede suceder al revés.

IISNode Handler

Para que IIS sepa que server.js contiene nuestra aplicación web Node.js, debemos indicarlo explícitamente. Podemos hacer esto agregando el IISNode <handler> al elemento <handlers> .

<handlers>
  <add name="iisnode" path="server.js" verb="*" modules="iisnode"/>
</handlers>

Reglas de reescritura de URL

La parte final de la configuración es garantizar que el tráfico destinado a nuestra aplicación Node.js que ingresa a nuestra instancia de IIS se dirija a IISNode. Sin las reglas de reescritura de URL, tendríamos que visitar nuestra aplicación yendo a http://<host>/server.js y, lo que es peor, al intentar solicitar un recurso proporcionado por server.js obtendrá un 404 . Esta es la razón por la cual la reescritura de URL es necesaria para las aplicaciones web de IISNode.

<rewrite>
    <rules>
        <!-- First we consider whether the incoming URL matches a physical file in the /public folder -->
        <rule name="StaticContent" patternSyntax="Wildcard">
            <action type="Rewrite" url="public/{R:0}" logRewrittenUrl="true"/>
            <conditions>
                <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true"/>
            </conditions>
            <match url="*.*"/>
        </rule>

        <!-- All other URLs are mapped to the Node.js application entry point -->
        <rule name="DynamicContent">
            <conditions>
                <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="True"/>
            </conditions>
            <action type="Rewrite" url="server.js"/>
        </rule>
    </rules>
</rewrite>

Este es un archivo Web.config trabajo para este ejemplo , configuración para una instalación de Node.js de 64 bits.

Eso es todo, ahora visite su sitio IIS y vea cómo funciona su aplicación Node.js.

Uso de un directorio virtual de IIS o una aplicación anidada a través de

El uso de un directorio virtual o una aplicación anidada en IIS es un escenario común y muy probablemente el que querrá aprovechar al usar IISNode.

IISNode no proporciona soporte directo para directorios virtuales o aplicaciones anidadas a través de la configuración, por lo que para lograrlo, deberemos aprovechar una característica de IISNode que no forma parte de la configuración y es mucho menos conocida. Todos los elementos <appSettings> elemento <appSettings> con Web.config se agregan al objeto process.env como propiedades mediante la clave appSetting.

Permite crear un directorio virtual en nuestros <appSettings>

<appSettings>
  <add key="virtualDirPath" value="/foo" />
</appSettings>

Dentro de nuestra aplicación Node.js podemos acceder a la configuración virtualDirPath

console.log(process.env.virtualDirPath); // prints /foo

Ahora que podemos usar el elemento <appSettings> para la configuración, aprovechemos eso y lo usemos en nuestro código de servidor.

// Access the virtualDirPath appSettings and give it a default value of '/'
// in the event that it doesn't exist or isn't set
var virtualDirPath = process.env.virtualDirPath || '/';

// We also want to make sure that our virtualDirPath 
// always starts with a forward slash
if (!virtualDirPath.startsWith('/', 0))
  virtualDirPath = '/' + virtualDirPath;

// Setup a route at the index of our app    
server.get(virtualDirPath, (req, res) => {
    return res.status(200).send('Hello World');
});

Podemos usar virtualDirPath con nuestros recursos estáticos también

// Public Directory
server.use(express.static(path.join(virtualDirPath, 'public')));
// Bower
server.use('/bower_components', express.static(path.join(virtualDirPath, 'bower_components')));

Vamos a poner todo eso juntos

const express = require('express');
const server = express();

const port = process.env.PORT || 3000;

// Access the virtualDirPath appSettings and give it a default value of '/'
// in the event that it doesn't exist or isn't set
var virtualDirPath = process.env.virtualDirPath || '/';

// We also want to make sure that our virtualDirPath 
// always starts with a forward slash
if (!virtualDirPath.startsWith('/', 0))
  virtualDirPath = '/' + virtualDirPath;

// Public Directory
server.use(express.static(path.join(virtualDirPath, 'public')));
// Bower
server.use('/bower_components', express.static(path.join(virtualDirPath, 'bower_components')));

// Setup a route at the index of our app    
server.get(virtualDirPath, (req, res) => {
    return res.status(200).send('Hello World');
});

server.listen(port, () => {
    console.log(`Listening on ${port}`);
});

Usando Socket.io con IISNode

Para que Socket.io trabaje con IISNode, los únicos cambios necesarios cuando no se utiliza un Directorio virtual / Aplicación anidada están dentro de Web.config .

Dado que Socket.io envía solicitudes que comienzan con /socket.io , IISNode necesita comunicarse con IIS para que éstas también se manejen con IISNode y no sean solo solicitudes de archivos estáticos u otro tipo de tráfico. Esto requiere un <handler> diferente a las aplicaciones estándar de IISNode.

<handlers>
    <add name="iisnode-socketio" path="server.js" verb="*" modules="iisnode" />
</handlers>

Además de los cambios en los <handlers> , también debemos agregar una regla de reescritura de URL adicional. La regla de reescritura envía todo el tráfico /socket.io a nuestro archivo de servidor donde se ejecuta el servidor Socket.io.

<rule name="SocketIO" patternSyntax="ECMAScript">
    <match url="socket.io.+"/>
    <action type="Rewrite" url="server.js"/>
</rule>

Si está utilizando IIS 8, deberá deshabilitar la configuración de webSockets en su Web.config además de agregar el controlador anterior y volver a escribir las reglas. Esto no es necesario en IIS 7 ya que no hay soporte webSocket.

<webSocket enabled="false" />