2017-01-26 4 views
1

Ich habe eine grundlegende Knoten-Webanwendung mit Express, die eine Abhängigkeit von der Node-Sass-Bibliothek hat.Express App mit Node-sass auf Azure App Service

Dies wird auf einem Win64-Server erstellt, so dass während der npm-Installation Teil des Builds die x64-Version der verbindlichen Binärdatei aufgrund der aktuellen Umgebung heruntergeladen wird.

Wenn seine zu Azure App Service implementiert sie einen Laufzeitfehler aufgrund von Unverträglichkeit mit dem Knoten-sass Bindung binären wirft, als 32-Bit-Knoten in Azure App Dienst läuft ...

Error: Missing binding D:\home\site\wwwroot\node_modules\node-sass\vendor\win32-ia32-48\binding.node Node Sass could not find a binding for your current environment: Windows 32-bit with Node.js 6.x

Found bindings for the following environments: - Windows 64-bit with Node.js 6.x

Wenn i in explizit überprüfen the 32bit binding und wieder stelle ich manchmal erhalten einen 502-Gateway-Fehler ...

502 - Web server received an invalid response while acting as a gateway or proxy server. There is a problem with the page you are looking for, and it cannot be displayed. When the Web server (while acting as a gateway or proxy) contacted the upstream content server, it received an invalid response from the content server.

und andere Zeiten, ich bekomme einfach eine 500, aber es nicht mehr schreibt den Fehler in das Protokoll.

Die App hängt explizit von Node-Sass-Middleware Paket Version 0.11, die von Node-Sass 4.3.0 abhängt.

Ohne Fehlerprotokolle bin ich in einer Sackgasse. Sind Sie schon einmal auf dieses Problem gestoßen, und wenn ja, wie haben Sie es gelöst?

Antwort

1

Wir haben dies schließlich gelöst, indem wir node-sass-middleware für gulp-sass vertauscht haben und auch einen npm rebuild step für node-sass hinzugefügt haben. Der Hauptunterschied besteht darin, dass die CSS jetzt während des Build-Prozesses über Schluck gerendert wird. Die Ausführung von npm rebuild node-sass würde zuerst den Bindungsdownload auf den Build-Server aufrufen (falls erforderlich), und dann würde eine separate Task eine Schlucktask aufrufen, um die CSS zu rendern.

Der Rest unseres Problems war aufgrund der Tatsache, dass die web.config App.js als Einstiegspunkt angegeben, aber express4 verwendet die bin/www-Datei und verweist einfach app.js. Das Problem mit bin/www als Einstiegspunkt ist, dass iisnode jetzt bin als Arbeitsverzeichnis verwendet, was zu Problemen mit relativen Verweisen auf root führte.

Anstatt noch mehr Zeit zu verschwenden, um herauszufinden, ob wir ein anderes Arbeitsverzeichnis konfiguriert werden können, zogen wir einfach ist/www zu ./server.js und änderten die web.config-zu-Punkt

server.js

Die Express-App läuft nun wie erwartet auf azurblauen Webseiten.

1

Ich verwendete Node-Sass Example App, um einen schnellen Test zu haben, verwendete local git, um es Beispielprojekt zu Azure Web Apps bereitzustellen, das Ihr Problem reproduzierte.

Über den Einsatz Protokoll:

remote: Selected node.js version 7.4.0. Use package.json file to choose a different version. remote: Selected npm version 4.0.5

und die ähnliche Fehlermeldung nach:

Found bindings for the following environments: - Windows 64-bit with Node.js 6.x

angegeben ich die node.js Version in package.json zu:

"engines": { 
    "node": "= 6.9.1", 
    "npm": "> 3" 
} 

Dann umschichten Azure über lokalen Git, und das Beispiel funktioniert gut.

Für Ihre weitere 500 Fehler können Sie versuchen, App Service Editor zu nutzen, um die Ausgabe Ihrer Website zu überprüfen.

Geben Sie den App-Service Editor von Azure-Portal, Schalter auf Ausgang Abschnitt durch den Button Show Ausgabe klicken, klicken dann Lauf die Anwendung zu starten.

+0

Vielen Dank für Ihre Eingabe, der App Service Editor ist definitiv nützlich. Am Ende haben wir gulp-sass verwendet und npm rebuild node-sass ausgeführt, um die Bindung herunterzuladen, bevor npm install ausgeführt wurde. Wir mussten auch web.config modifizieren, um dynamische Anfragen an bin/www zu senden. Wir sind jetzt auf ein endgültiges Problem fest, das auf die Tatsache zurückzuführen ist, dass iisnode anscheinend aus dem bin-Verzeichnis ausgeführt wird, was bedeutet, dass alle Verweise auf Dateien relativ zum Stamm der App wie ./data/stuff.json nicht gefunden werden und führen zu einem Fehler von 500. Dies ist nicht ideal - ist der einzige Weg, um nicht bin/www-Datei zu verwenden? – Baldy

+1

Es scheint, dass Ihr neues Problem komplex ist. Es gibt einen Eingang Ihrer Anwendung wie 'app.js' oder' server.js' im root-Verzeichnis, und wir müssen den 'handler' und' url lineal' in 'web.cofnig' konfigurieren. Wie das Beispiel bei https://github.com/tjanczuk/iisnode/blob/master/src/samples/express/web.config. Übrigens kann ich Ihnen im Kommentar kaum klar folgen, und Ihre weitere Frage scheint wenig mit Ihrer ursprünglichen Frage zu tun zu haben. Ich empfehle Ihnen daher, eine neue Frage zu SO zu stellen, mit detaillierteren Nachrichten zu Ihrem neuen Problem. Vielen Dank. –

+0

Ja, es gab 2 Probleme im Spiel, beide jetzt gelöst. Wird meine Antwort zu diesem Beitrag hinzufügen. Danke für deine Anregungen, es war hilfreich – Baldy

Verwandte Themen