iisnode.yml: Konfigurieren von Node.js in Windows Azure

3 Minuten Lesezeit
0 Kommentare

Wenn ich eine Node.js-Anwendung über Continuous Deployment in Windows Azure bereitstellen will, dann funktioniert das im einfachsten Fall, wie in meinem letzten Blog-Post beschrieben, ohne jegliche Konfiguration. Erfahrungsgemäß kann aber mit hoher Wahrscheinlichkeit jeder Software-Entwickler bestätigen, dass es bei diesem Fall niemals bleiben wird.

iisnode

Eine Node.js-Anwendung kann prinzipiell einfach über das Kommando node server.js gestartet werden. Dies ist allerdings für einen produktiven Einsatz nicht empfohlen. Unter Windows können Node.js-Anwendungen im IIS gehostet werden. Da dieser aber grundsätzlich erstmal nichts von Node.js kennt, kommt hierbei das Modul iisnode ins Spiel. Es verbindet node.exe, die bereitgestellte Anwendung und den IIS miteinander.

iisnode bringt mehrere Vorteile mit sich:

  • Prozess-Verwaltung: Die Web Site kann zentral gestartet, gestoppt und deren Status überprüft werden.
  • Skalierbarkeit bei Multicore-CPUs: Node.js läuft als Single-Thread-Prozess. iisnode kann mehrere Instanzen von Node.js starten und somit die Anwendung auf mehrere CPUs verteilen, sodass eine optimale Auslastung erreicht werden kann.
  • Auto-Refresh: Automatischer Neustart der Anwendung, wenn sich Dateien ändern oder ein Fehler die Anwendung zum Absturz bringt.
  • Debugging: Integration des NPM-Moduls node-inspector zum Remote-Debuggen der Anwendung von jedem WebKit-basierenden Browser aus.

Alle sonstigen Features des IIS und dessen Infrastruktur bleiben zusätzlich erhalten.

Wenn eine Node.js-Anwendung im Windows Azure Web Sites-Service läuft, dann wird im Hintergrund genau dieses iisnode-Modul verwendet.

iisnode.yml

Das iisnode-Modul lässt sich über die Datei iisnode.yml, welche im Hauptverzeichnis der Anwendung liegt, konfigurieren. Hier ein Beispiel mit einigen Einstellungen und deren Beschreibungen.

nodeProcessCommandLine: "D:\home\site\wwwroot\bin\node.exe"
node_env: production
loggingEnabled: false
devErrorsEnabled: false
debuggingEnabled: false

Eine komplett dokumentierte Version der Datei iisnode.yml findet sich im Repository von iisnode wieder.

Node-Version austauschen

Mit dem Parameter nodeProcessCommandLine ist es möglich von der von Windows Azure zur Verfügung gestellten node.exe-Version abzuweichen. Die entsprechende node.exe wird dabei einfach im Projekt-Ordner abgelegt (im Beispiel oben '\bin\node.exe').

Das Austauschen der node.exe kann nur empfohlen werden, da Windows Azure als Standard die veraltete Version 0.6.20 einsetzt und durch das Ändern der engine-Eigenschaft in der Datei package.json höchstens noch Version 0.8.4 zulässt. Nachzulesen ist das in der Windows Azure Dokumentation.

Anwendungsumgebung festlegen

node_env setzt die NODE_ENV-Umgebungsvariable, auf welche innerhalb der node.js-Anwendung zugegriffen werden kann. Die Variable kann z.B. auf production, development o.ä. gesetzt werden. Somit können in deren Abhängigkeit unterschiedliche Anwendungskonfigurationen geladen werden.

if (process.env.NODE_ENV == 'production') {
    console.log('Running in production.');
}

Logging

console.log()-Ausgaben eines in Azure laufenden Prozesses können direkt am Client überwacht werden. Mit azure site log download [sitename] kann der gesamte Log heruntergeladen werden. Ein Streaming der Logausgaben ist mit dem Kommando azure site log tail [sitename] möglich. Durch das Setzen von loggingEnabled: false kann dieses Verhalten deaktiviert werden. Mehr dazu in der Windows Azure Dokumentation.

Unerwartete Fehler

Tritt ein Fehler bei der Ausführung der Node.js-Anwendung auf, so werden die Fehlerdetails als HTTP 200-Response im Browser des Benutzers ausgegeben. Um keine kritischen Serverinformationen nach außen zu geben kann die Einstellung devErrorsEnabled: false dazu verwendet werden mit einer HTTP 500-Response ohne Meldung zu antworten.

Web.config

In dem Fall, wenn beim Deployment keine web.config im Root-Verzeichnis gefunden wurde, erzeugt und verwendet Azure automatisch diese Datei mit dem folgenden Inhalt:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <webSocket enabled="false" />
    <handlers>
      <add name="iisnode" path="server.js" verb="*" modules="iisnode"/>
    </handlers>
    <rewrite>
      <rules>
        <rule name="StaticContent">
          <action type="Rewrite" url="public{REQUEST_URI}"/>
        </rule>
        <rule name="DynamicContent">
          <conditions>
            <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="True"/>
          </conditions>
          <action type="Rewrite" url="server.js"/>
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

Will man IIS-spezifische Einstellungen vornehmen, welche mit der Datei iisnode.yml nicht abgedeckt werden können, so sollte man dieses Template als Basis für die Anpassungen verwenden.

Fazit

Beim Deployment wird ein eindeutiges Opt-In-Prinzip angewandt. Das heißt unsere Anwendung läuft erst einmal mit den Grundeinstellungen und benötigt nur den eigentlichen Anwendungscode. Lediglich wenn ich nun präzisere Einstellungen vornehmen möchte oder muss, kann ich dies mit einem sehr geringen Konfigurationsaufwand in der Datei iisnode.yml oder web.config tun. Komplexe unverständliche Mechanismen oder Tools sind hier nicht notwendig.

comments powered byDisqus