Konfigurera en Node.js-app för Azure App Service

Artikel
06/01/2023

Node.js appar måste distribueras med alla nödvändiga NPM-beroenden. Den App Service distributionsmotorn körs npm install --production automatiskt åt dig när du distribuerar en Git-lagringsplats eller ett Zip-paket med versionsautomatisering aktiverat. Om du distribuerar filer med FTP/S måste du dock ladda upp de nödvändiga paketen manuellt.

Den här guiden innehåller viktiga begrepp och instruktioner för Node.js utvecklare som distribuerar till App Service. Om du aldrig har använt Azure App Service följer du först självstudienNode.js snabbstart och Node.js med MongoDB.

Visa Node.js version

Om du vill visa den aktuella Node.js versionen kör du följande kommando i Cloud Shell:

az webapp config appsettings list --name <app-name> --resource-group <resource-group-name> --query "[?name=='WEBSITE_NODE_DEFAULT_VERSION'].value"

Om du vill visa alla Node.js versioner som stöds går du till https://<sitename>.scm.azurewebsites.net/api/diagnostics/runtime eller kör följande kommando i Cloud Shell:

az webapp list-runtimes --os windows | grep NODE

Om du vill visa den aktuella Node.js versionen kör du följande kommando i Cloud Shell:

az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion

Om du vill visa alla Node.js versioner som stöds kör du följande kommando i Cloud Shell:

az webapp list-runtimes --os linux | grep NODE

Ange Node.js version

Om du vill ställa in appen på en version som stöds Node.js kör du följande kommando i Cloud Shell för att ange WEBSITE_NODE_DEFAULT_VERSION en version som stöds:

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings WEBSITE_NODE_DEFAULT_VERSION="~16"

Anteckning

I det här exemplet används den rekommenderade "tilde-syntaxen" för att rikta den senaste tillgängliga versionen av Node.js 16-körning på App Service.

Eftersom körningen regelbundet korrigeras och uppdateras av plattformen rekommenderar vi inte att du riktar in dig på en viss delversion/korrigering eftersom dessa inte garanterat är tillgängliga på grund av potentiella säkerhetsrisker.

Anteckning

Du bör ange den Node.js versionen i projektets package.json. Distributionsmotorn körs i en separat process som innehåller alla Node.js versioner som stöds.

Om du vill ställa in appen på en version som stöds Node.js kör du följande kommando i Cloud Shell:

az webapp config set --resource-group <resource-group-name> --name <app-name> --linux-fx-version "NODE|14-lts"

Den här inställningen anger den Node.js version som ska användas, både vid körning och under automatisk paketåterställning i Kudu.

Anteckning

Du bör ange den Node.js versionen i projektets package.json. Distributionsmotorn körs i en separat container som innehåller alla Node.js versioner som stöds.

Hämta portnummer

Din Node.js app måste lyssna på rätt port för att ta emot inkommande begäranden.

I App Service i Windows finns Node.js appar med IISNode, och din Node.js-app bör lyssna på porten som anges i variabelnprocess.env.PORT. I följande exempel visas hur du gör det i en enkel Express-app:

App Service anger miljövariabeln PORT i Node.js-containern och vidarebefordrar inkommande begäranden till containern vid det portnumret. För att ta emot begäranden bör appen lyssna på porten med hjälp av process.env.PORT. I följande exempel visas hur du gör det i en enkel Express-app:

const express = require('express')
const app = express()
const port = process.env.PORT || 3000

app.get('/', (req, res) => {
  res.send('Hello World!')
})

app.listen(port, () => {
  console.log(`Example app listening at http://localhost:${port}`)
})

Anpassa versionsautomatisering

Om du distribuerar din app med Git eller zip-paket med versionsautomatisering aktiverat stegar App Service skapa automatisering genom följande sekvens:

Kör anpassat skript om det anges av PRE_BUILD_SCRIPT_PATH.
Kör npm install utan flaggor, som innehåller npm preinstall och postinstall skript och även installerar devDependencies.
Kör npm run build om ett byggskript har angetts i package.json.
Kör npm run build:azure om ett build:azure-skript har angetts i package.json.
Kör anpassat skript om det anges av POST_BUILD_SCRIPT_PATH.

Anteckning

Enligt beskrivningen i npm-dokument körs skript med namnet prebuild och postbuild före respektive efter build, om de har angetts. preinstall och postinstall kör före respektive efter install.

PRE_BUILD_COMMAND och POST_BUILD_COMMAND är miljövariabler som är tomma som standard. Om du vill köra förskapade kommandon definierar du PRE_BUILD_COMMAND. Om du vill köra kommandon efter kompilering definierar du POST_BUILD_COMMAND.

I följande exempel anges de två variablerna till en serie kommandon, avgränsade med kommatecken.

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings PRE_BUILD_COMMAND="echo foo, scripts/prebuild.sh"
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings POST_BUILD_COMMAND="echo foo, scripts/postbuild.sh"

Ytterligare miljövariabler för att anpassa byggautomatisering finns i Oryx-konfiguration.

Mer information om hur App Service kör och skapar Node.js-appar i Linux finns i Oryx-dokumentationen: Så här identifieras och skapas Node.js appar.

Konfigurera Node.js server

De Node.js containrarna levereras med PM2, en produktionsprocesshanterare. Du kan konfigurera appen så att den börjar med PM2, NPM eller med ett anpassat kommando.

Verktyg	Syfte
Kör med PM2	Rekommenderas – användning av produktion eller mellanlagring. PM2 tillhandahåller en plattform för apphantering med full service.
Kör npm start	Endast utveckling.
Kör anpassat kommando	Antingen utveckling eller mellanlagring.

Kör med PM2

Containern startar automatiskt appen med PM2 när en av de vanliga Node.js-filerna finns i projektet:

bin/www
server.js
app.js
index.js
hostingstart.js
En av följande PM2-filer: process.json och ecosystem.config.js

Du kan också konfigurera en anpassad startfil med följande tillägg:

En .js fil
En PM2-fil med filnamnstillägget .json, .config.js, .yaml eller .yml

Anteckning

Från och med Node 14 LTS startar containern inte appen automatiskt med PM2. Om du vill starta appen med PM2 anger du startkommandot till pm2 start <.js-file-or-PM2-file> --no-daemon. Se till att använda --no-daemon argumentet eftersom PM2 måste köras i förgrunden för att containern ska fungera korrekt.

Om du vill lägga till en anpassad startfil kör du följande kommando i Cloud Shell:

az webapp config set --resource-group <resource-group-name> --name <app-name> --startup-file "<filename-with-extension>"

Kör anpassat kommando

App Service kan starta appen med ett anpassat kommando, till exempel en körbar fil som run.sh. Kör till npm run start:prodexempel följande kommando i Cloud Shell:

az webapp config set --resource-group <resource-group-name> --name <app-name> --startup-file "npm run start:prod"

Kör npm start

Om du vill starta appen med kontrollerar npm startdu bara att ett start skript finns i filen package.json . Exempel:

{
  ...
  "scripts": {
    "start": "gulp",
    ...
  },
  ...
}

Om du vill använda en anpassad package.json i projektet kör du följande kommando i Cloud Shell:

az webapp config set --resource-group <resource-group-name> --name <app-name> --startup-file "<filename>.json"

Felsöka via en fjärranslutning

Anteckning

Fjärrfelsökning är för närvarande i förhandsversion.

Du kan felsöka din Node.js-app via fjärranslutning i Visual Studio Code om du konfigurerar den så att den körs med PM2, förutom när du kör den med hjälp av en .config.js,.yml eller .yaml.

I de flesta fall krävs ingen extra konfiguration för din app. Om din app körs med en process.json-fil (standard eller anpassad) måste den ha en script egenskap i JSON-roten. Exempel:

{
  "name"        : "worker",
  "script"      : "./index.js",
  ...
}

Om du vill konfigurera Visual Studio Code för fjärrfelsökning installerar du tillägget App Service. Följ anvisningarna på tilläggssidan och logga in på Azure i Visual Studio Code.

Leta reda på den app som du vill felsöka i Azure Explorer, högerklicka på den och välj Starta fjärrfelsökning. Klicka på Ja för att aktivera det för din app. App Service startar en tunnelproxy åt dig och kopplar felsökningsprogrammet. Du kan sedan göra begäranden till appen och se felsökningsprogrammet pausa vid brytpunkter.

När felsökningen är klar stoppar du felsökningsprogrammet genom att välja Koppla från. När du uppmanas till det bör du klicka på Ja för att inaktivera fjärrfelsökning. Om du vill inaktivera den senare högerklickar du på din app igen i Azure Explorer och väljer Inaktivera fjärrfelsökning.

Få åtkomst till miljövariabler

I App Service kan du ange appinställningar utanför din appkod. Sedan kan du komma åt dem med hjälp av standardmönstret Node.js. Om du till exempel vill få åtkomst till en appinställning med namnet NODE_ENV använder du följande kod:

process.env.NODE_ENV

Kör Grunt/Bower/Gulp

Som standard körs npm install --production App Service build automation när den identifierar en Node.js app distribueras via Git eller via Zip-distribution med byggautomatisering aktiverat. Om din app kräver något av de populära automatiseringsverktygen, till exempel Grunt, Bower eller Gulp, måste du ange ett anpassat distributionsskript för att köra det.

Om du vill att lagringsplatsen ska kunna köra dessa verktyg måste du lägga till dem i beroendena i package.json. Till exempel:

"dependencies": {
  "bower": "^1.7.9",
  "grunt": "^1.0.1",
  "gulp": "^3.9.1",
  ...
}

Från ett lokalt terminalfönster ändrar du katalogen till lagringsplatsens rot och kör följande kommandon:

npm install kuduscript -g
kuduscript --node --scriptType bash --suppressPrompt

Lagringsplatsens rot har nu ytterligare två filer: .deployment och deploy.sh.

Öppna deploy.sh och leta upp Deployment avsnittet som ser ut så här:

##################################################################################################################################
# Deployment
# ----------

Det här avsnittet slutar med att köra npm install --production. Lägg till kodavsnittet som du behöver för att köra det verktyg som krävs i slutet av Deployment avsnittet:

Bower
Klunk
Grunt

Se ett exempel i MEAN.js exempel, där distributionsskriptet även kör ett anpassat npm install kommando.

Bower

Det här kodfragmentet kör bower install.

if [ -e "$DEPLOYMENT_TARGET/bower.json" ]; then
  cd "$DEPLOYMENT_TARGET"
  eval ./node_modules/.bin/bower install
  exitWithMessageOnError "bower failed"
  cd - > /dev/null
fi

Klunk

Det här kodfragmentet kör gulp imagemin.

if [ -e "$DEPLOYMENT_TARGET/gulpfile.js" ]; then
  cd "$DEPLOYMENT_TARGET"
  eval ./node_modules/.bin/gulp imagemin
  exitWithMessageOnError "gulp failed"
  cd - > /dev/null
fi

Grunt

Det här kodfragmentet kör grunt.

if [ -e "$DEPLOYMENT_TARGET/Gruntfile.js" ]; then
  cd "$DEPLOYMENT_TARGET"
  eval ./node_modules/.bin/grunt
  exitWithMessageOnError "Grunt failed"
  cd - > /dev/null
fi

Identifiera HTTPS-sessionen

I App Service sker TLS/SSL-avslutning hos nätverkslastbalanserarna, så alla HTTPS-begäranden når din app som okrypterade HTTP-begäranden. Om din applogik behöver kontrollera om användarbegäranden är krypterade eller inte kan du kontrollera X-Forwarded-Proto-rubriken.

Med populära ramverk får du åtkomst till X-Forwarded-* information i standardappens mönster. I Express kan du använda betrodda proxyservrar. Exempel:

app.set('trust proxy', 1)
...
if (req.secure) {
  // Do something when HTTPS is used
}

Få åtkomst till diagnostikloggar

Om du vill komma åt konsolloggarna som genereras i din programkod i App Service aktiverar du diagnostisk loggning genom att köra följande kommando i Cloud Shell:

az webapp log config --resource-group <resource-group-name> --name <app-name> --docker-container-logging filesystem --level Verbose

Möjliga värden för --level är: Error, Warning, Info och Verbose. Varje efterföljande nivå omfattar den föregående nivån. Exempel: Error omfattar endast felmeddelanden och Verbose omfattar alla meddelanden.

När diagnostisk loggning har aktiverats kör du följande kommando för att visa loggströmmen:

az webapp log tail --resource-group <resource-group-name> --name <app-name>

Om du inte ser konsolloggarna omedelbart kan du titta efter igen efter 30 sekunder.

Anteckning

Du kan även granska loggfilerna från din webbläsare via https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Skriv Ctrl+C när som helst för att stoppa loggströmningen.

Du kan komma åt konsolloggarna som genereras inifrån containern.

Aktivera först containerloggning genom att köra följande kommando:

az webapp log config --name <app-name> --resource-group <resource-group-name> --docker-container-logging filesystem

Ersätt <app-name> och <resource-group-name> med de namn som är lämpliga för din webbapp.

När containerloggning har aktiverats kör du följande kommando för att visa loggströmmen:

az webapp log tail --name <app-name> --resource-group <resource-group-name>

Om du inte ser konsolloggarna omedelbart kan du titta efter igen efter 30 sekunder.

Om du vill stoppa loggströmningen när som helst skriver du Ctrl+C.

Du kan också granska loggfilerna i en webbläsare på https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Övervaka med Application Insights

Med Application Insights kan du övervaka programmets prestanda, undantag och användning utan att göra några kodändringar. Om du vill koppla App Insights-agenten går du till din webbapp i portalen och väljer Application Insights under Inställningar och väljer sedan Aktivera Application Insights. Välj sedan en befintlig App Insights-resurs eller skapa en ny. Välj slutligen Använd längst ned. Om du vill instrumentera din webbapp med PowerShell kan du läsa de här anvisningarna

Den här agenten övervakar Node.js program på serversidan. Om du vill övervaka JavaScript på klientsidan lägger du till JavaScript SDK i projektet.

Mer information finns i viktig information om Application Insights-tillägget.

Felsökning

När en fungerande Node.js app beter sig annorlunda i App Service eller har fel kan du prova följande:

Få åtkomst till loggströmmen.
Testa appen lokalt i produktionsläge. App Service kör dina Node.js-appar i produktionsläge, så du måste se till att projektet fungerar som förväntat i produktionsläge lokalt. Exempel:
- Beroende på package.json kan olika paket installeras för produktionsläge (dependencies jämfört med devDependencies).
- Vissa webbramverk kan distribuera statiska filer på olika sätt i produktionsläge.
- Vissa webbramverk kan använda anpassade startskript när de körs i produktionsläge.
Kör appen i App Service i utvecklingsläge. I MEAN.jskan du till exempel ställa in appen på utvecklingsläge i körningsläge genom att ange appinställningenNODE_ENV.

Du har inte behörighet att visa den här katalogen eller sidan

När du har distribuerat din Node.js-kod till en inbyggd Windows-app i App Service kan du se meddelandet You do not have permission to view this directory or page. i webbläsaren när du navigerar till appens URL. Detta beror troligen på att du inte har någon web.config fil (se mallen och ett exempel).

Om du distribuerar dina filer med hjälp av Git, eller genom att använda ZIP-distribution med versionsautomatisering aktiverat, genererar distributionsmotorn en web.config i appens webbrot (%HOME%\site\wwwroot) automatiskt om något av följande villkor är sant:

Projektroten har en package.json som definierar ett start skript som innehåller sökvägen till en JavaScript-fil.
Projektroten har antingen en server.js eller en app.js.

Den genererade web.config är anpassad efter det identifierade startskriptet. För andra distributionsmetoder lägger du till den här web.config manuellt. Kontrollera att filen är korrekt formaterad.

Om du använder ZIP-distribution (till exempel via Visual Studio Code) måste du aktivera byggautomatisering eftersom den inte är aktiverad som standard. az webapp up använder ZIP-distribution med versionsautomatisering aktiverat.

robots933456 i loggar

Följande meddelande kan visas i containerloggarna:

2019-04-08T14:07:56.641002476Z "-" - - [08/Apr/2019:14:07:56 +0000] "GET /robots933456.txt HTTP/1.1" 404 415 "-" "-"

Du kan ignorera det här meddelandet. /robots933456.txt är en dummysökväg för URL:en som App Service använder till att kontrollera om containern kan hantera begäranden. Ett 404-svar innebär helt enkelt att sökvägen inte finns, men det låter App Service veta att containern är felfri och redo att svara på begäranden.

Nästa steg

Självstudier: Node.js-app med MongoDB

Vanliga frågor och svar om App Service på Linux

Eller se ytterligare resurser:

Referens för miljövariabler och appinställningar

Konfigurera en Node.js-app för Azure App Service

Visa Node.js version

Ange Node.js version

Hämta portnummer

Anpassa versionsautomatisering

Konfigurera Node.js server

Kör med PM2

Kör anpassat kommando

Kör npm start

Felsöka via en fjärranslutning

Få åtkomst till miljövariabler

Kör Grunt/Bower/Gulp

Bower

Klunk

Grunt

Identifiera HTTPS-sessionen

Få åtkomst till diagnostikloggar

Övervaka med Application Insights

Felsökning

Du har inte behörighet att visa den här katalogen eller sidan

robots933456 i loggar

Nästa steg

Ytterligare resurser