Node.js
Utilizzo di IISNode per ospitare le app Web Node.js in IIS

Osservazioni

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

Iniziare

IISNode consente alle app Web di Node.js di essere ospitate su IIS 7/8 proprio come farebbe un'applicazione .NET. Ovviamente, è possibile ospitare autonomamente il processo node.exe su Windows, ma perché farlo basta quando si esegue l'app in IIS.

IISNode gestirà il ridimensionamento su più core, la gestione dei processi di node.exe e il riciclo automatico dell'applicazione IIS ogni volta che la tua app viene aggiornata, solo per citarne alcuni dei suoi vantaggi .

Requisiti

IISNode ha alcuni requisiti prima di poter ospitare l'app Node.js in IIS.

1. Node.js deve essere installato sull'host IIS, a 32 o 64 bit, o sono supportati.
2. IISNode installato x86 o x64 , questo dovrebbe corrispondere al testimone del tuo host IIS.
3. Il modulo URL-Rewrite di Microsoft per IIS installato sul tuo host IIS.
   • Questa è la chiave, altrimenti le richieste alla tua app Node.js non funzioneranno come previsto.
4. Un Web.config nella cartella principale della tua app Node.js.
5. Configurazione IISNode tramite un file iisnode.yml o un elemento <iisnode> all'interno di Web.config .

Esempio di base Hello World utilizzando Express

Per ottenere questo esempio, è necessario creare un'applicazione IIS 7/8 sul proprio host IIS e aggiungere la directory contenente l'app Web Node.js come directory fisica. Assicurarsi che l'identità del pool di applicazioni / applicazioni possa accedere all'installazione di Node.js. Questo esempio utilizza l'installazione a 64 bit di Node.js.

Struttura del progetto

Questa è la struttura di progetto di base di un'app Web IISNode / Node.js. Sembra quasi identico a qualsiasi Web App non IISNode tranne per l'aggiunta di Web.config .

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

server.js - Applicazione 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}`);
});

Configurazione e Web.config

Web.config è simile a qualsiasi altro IIS Web.config tranne che le seguenti due cose devono essere presenti, URL <rewrite><rules> e un <handler> IISNode <handler> . Entrambi questi elementi sono figli dell'elemento <system.webServer> .

Configurazione

È possibile configurare IISNode utilizzando un file iisnode.yml o aggiungendo l'elemento <iisnode> come figlio di <system.webServer> nel proprio Web.config . Entrambe queste configurazioni possono essere utilizzate in combinazione tra loro, tuttavia, in questo caso, Web.config dovrà specificare il file iisnode.yml E qualsiasi conflitto di configurazione verrà preso dal file iisnode.yml . Questa sovrascrittura della configurazione non può avvenire al contrario.

IISNode Handler

Per fare in modo che IIS sappia che server.js contiene la nostra app Web Node.js, dobbiamo dirlo esplicitamente. Possiamo farlo aggiungendo IISNode <handler> <handlers> all'elemento <handlers> .

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

Regole di riscrittura degli URL

La parte finale della configurazione sta assicurando che il traffico destinato alla nostra app Node.js in arrivo nella nostra istanza IIS venga indirizzato a IISNode. Senza le regole di riscrittura degli URL, dovremmo visitare la nostra app andando su http://<host>/server.js e, peggio ancora, quando provi a richiedere una risorsa fornita da server.js otterrai un 404 . Questo è il motivo per cui la riscrittura degli URL è necessaria per le app Web 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>

Questo è un file Web.config funzionante per questo esempio , installazione per un'installazione Node.js a 64 bit.

È tutto, ora visita il tuo sito IIS e vedi come funziona l'applicazione Node.js.

Utilizzando una directory virtuale IIS o un'applicazione nidificata tramite

L'utilizzo di una directory virtuale o di un'applicazione nidificata in IIS è uno scenario comune e molto probabilmente di cui si vorrà approfittare quando si utilizza IISNode.

IISNode non fornisce supporto diretto per directory virtuali o applicazioni nidificate tramite la configurazione, per cui è necessario avvalersi di una funzionalità di IISNode che non fa parte della configurazione ed è molto meno conosciuta. Tutti i figli dell'elemento <appSettings> con Web.config vengono aggiunti all'oggetto process.env come proprietà utilizzando la chiave appSetting.

Consente di creare una directory virtuale nei nostri <appSettings>

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

All'interno della nostra app Node.js possiamo accedere alle impostazioni virtualDirPath

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

Ora che possiamo usare l'elemento <appSettings> per la configurazione, sfruttiamo questo e lo usiamo nel nostro codice server.

// 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');
});

Possiamo usare virtualDirPath anche con le nostre risorse statiche

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

Mettiamo tutto insieme

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

Utilizzo di Socket.io con IISNode

Per ottenere Socket.io che funziona con IISNode, le uniche modifiche necessarie quando non si utilizza una directory virtuale / applicazione nidificata sono all'interno di Web.config .

Poiché Socket.io invia richieste che iniziano con /socket.io , IISNode deve comunicare a IIS che questi devono essere gestiti anche da IISNode e non sono solo richieste di file statici o altro traffico. Ciò richiede un <handler> diverso dalle app IISNode standard.

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

Oltre alle modifiche apportate ai <handlers> è inoltre necessario aggiungere una regola di riscrittura URL aggiuntiva. La regola di riscrittura invia tutto il traffico /socket.io al nostro file server su cui è in esecuzione il server Socket.io.

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

Se si utilizza IIS 8, sarà necessario disabilitare l'impostazione webSockets in Web.config in aggiunta all'aggiunta delle regole di gestione e riscrittura di cui sopra. Questo non è necessario in IIS 7 poiché non esiste il supporto webSocket.

<webSocket enabled="false" />