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

2025-05-27

Node.js appar måste distribueras med alla nödvändiga npm-beroenden. App Service-distributionsmotorn körs npm install --production automatiskt åt dig när du distribuerar en Git-lagringsplats eller när du distribuerar ett Zip-paket med versionsautomatisering aktiverat. Om du distribuerar dina filer med FTP /S måste du dock ladda upp de paket som krävs 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ölj först Node.js snabbstartsguide och handledningen 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 kör du 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 ange en Node.js version som stöds 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 in sig på den senaste tillgängliga versionen av Node.js 16-runtime i App Service.

Eftersom runtime-miljön regelbundet patchas och uppdateras av plattformen rekommenderar vi inte att du riktar in dig på en specifik delversion eller patch eftersom dessa inte garanteras vara tillgängliga på grund av 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 ange en Node.js version som stöds 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 vid 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.

Vad händer med inaktuella körmiljöer i App Service?

Inaktuella körningsmiljöer avvecklas av den underhållande organisationen eller har visat sig ha betydande säkerhetsrisker. Därför tas de bort från skapa och konfigurera sidor i portalen. När en föråldrad runtime är dold från portalen fortsätter alla appar som fortfarande använder den att köra.

Om du vill skapa en app med en inaktuell körningsversion som inte längre visas på portalen använder du Azure CLI, ARM-mallen eller Bicep. Med de här distributionsalternativen kan du skapa inaktuella körmiljöer som har tagits bort i portalen, men som fortfarande stöds.

Om en runtime tas bort helt från App Service-plattformen får ägaren till din Azure-prenumeration ett e-postmeddelande innan borttagningen.

Hämta portnummer

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

På App Service på Windows är Node.js-appar värd med IISNode, och din Node.js-app bör lyssna på den port som anges i process.env.PORT-variabeln. I följande exempel visas hur du gör det i en enkel Express-app:

App Service anger miljövariabeln PORT i containern Node.js och vidarebefordrar inkommande begäranden till containern vid det portnumret. Om du vill ta emot begäranden bör appen lyssna på den 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 build-automatisering

Om du distribuerar din app med hjälp av Git eller med hjälp av zip-paket med versionsautomation aktiverat går App Service Build Automation igenom följande sekvens:

Kör anpassat skript om ett 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 din package.json.
Kör npm run build:azure om ett build:azure-skript har angetts i din package.json.
Kör anpassat skript om det anges av POST_BUILD_SCRIPT_PATH.

Anteckning

Som anges i npm-dokumenten körs skript med namnet prebuild och postbuild före respektive efter build, om de anges. 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örhandsversionskommandon definierar du PRE_BUILD_COMMAND. Om du vill köra kommandon efter bygget definierar du POST_BUILD_COMMAND.

I följande exempel används de två variablerna för att ange 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"

Information om ytterligare miljövariabler för att anpassa versionsautomation finns i Oryx-konfiguration.

Mer information om hur App Service kör och bygger Node.js appar i Linux finns i Oryx-dokumentationen: Hur Node.js appar identifieras och skapas.

Konfigurera Node.js server

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

Verktyg	Syfte
Kör med PM2	Rekommenderas – För användning i produktion eller stagingmiljö. PM2 tillhandahåller en apphanteringsplattform med full service.
Kör med npm start	Endast för utvecklingsbruk.
Kör med ett 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 eller ecosystem.config.js

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

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

Anteckning

Från Node 14 LTS startar containern inte din app 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 argumentet --no-daemon 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 med ett anpassat kommando

App Service kan starta din app med ett anpassat kommando, till exempel en körbar fil som run.sh. Om du till exempel vill köra npm run start:prodkör du 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 med npm start

Om du vill starta appen med hjälp av npm start, se bara till att det finns ett start-skript i package.json-filen. Till 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

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 appen körs med en process.json fil (standard eller anpassad) måste den ha en script egenskap i JSON-roten. Till exempel:

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

Installera App Service-tillägget för att konfigurera Visual Studio Code för fjärrfelsökning. Följ anvisningarna på tilläggssidan och logga in på Azure i Visual Studio Code.

I Azure Explorer letar du reda på den app som du vill felsöka, högerklickar på den och väljer Starta fjärrfelsökning. Välj Ja för att aktivera fjärrfelsökning 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 att göra det bör du välja 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 att 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 reda på avsnittet Deployment som ser ut så här:

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

Det här avsnittet avslutas med att man kör npm install --production. Lägg till kodavsnittet som du behöver för att köra det nödvändiga verktyget i slutet av Deployment avsnittet:

Berså
Klunk
Grymtning

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

Berså

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

Grymta

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, inspektera X-Forwarded-Proto headern.

Med populära webb-ramverk får du åtkomst till X-Forwarded-* information i din standardappstruktur. I Express kan du använda betrodda proxyservrar. Till 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 inifrån programkoden i App Service aktiverar du diagnostikloggning 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, Infooch Verbose. Varje efterföljande nivå omfattar den föregående nivån. Till exempel innehåller Error endast felmeddelanden. Verbose innehåller alla meddelanden.

När du har aktiverat diagnostikloggning kör du följande kommando för att se loggströmmen:

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

Om konsolloggarna inte visas omedelbart kontrollerar du igen om 30 sekunder.

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

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

Om du vill aktivera containerloggning kör du 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 namn som är lämpliga för din webbapp.

När du har aktiverat containerloggning kör du följande kommando för att se loggströmmen:

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

Om konsolloggarna inte visas omedelbart kontrollerar du igen om 30 sekunder.

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

URL-omskrivningar

När du distribuerar Node.js appar i Azure App Service för Linux kan du behöva hantera URL-omskrivningar direkt i ditt program. Detta är särskilt användbart för att se till att specifika URL-mönster omdirigeras till rätt slutpunkter utan att förlita sig på webbserverkonfigurationer. Det finns flera sätt att utföra URL-omskrivningar i Node.js. Ett exempel är via express-urlrewrite-paketet .

Ö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 Application Insights-agenten går du till webbappen i portalen, väljer Application Insights under Inställningar och väljer sedan Aktivera Application Insights. Välj sedan en befintlig Application Insights-resurs eller skapa en ny. Välj slutligen Använd längst ned. Om du vill instrumentera din webbapp med Hjälp av PowerShell kan du läsa de här anvisningarna

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

Mer information finns i versionsanteckningarna för 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. Till exempel:
- Beroende på din 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

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 meddelandet You do not have permission to view this directory or page visas 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 build automation 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 skräddarsydd för 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 versionsautomatisering. Det är inte aktiverat som standard. az webapp up använder ZIP-distribution med build automation aktiverat.

Ignorera robots933456-meddelandet i loggar

Du kan se följande meddelande 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 dummy-URL-sökväg som App Service använder för att kontrollera om containern kan tjäna förfrågningar. Ett 404-svar anger att sökvägen inte finns och signalerar till App Service 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 Azure App Service on Linux

Eller se ytterligare resurser:

Referens för miljövariabler och appinställningar

Dela via

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

Visa Node.js version

Ange Node.js version

Vad händer med inaktuella körmiljöer i App Service?

Hämta portnummer

Anpassa build-automatisering

Konfigurera Node.js server

Kör med PM2

Kör med ett anpassat kommando

Kör med npm start

Felsöka via en fjärranslutning

Få åtkomst till miljövariabler

Kör Grunt/Bower/Gulp

Berså

Klunk

Grymta

Identifiera HTTPS-sessionen

Få åtkomst till diagnostikloggar

URL-omskrivningar

Övervaka med Application Insights

Felsökning

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

Ignorera robots933456-meddelandet i loggar

Nästa steg

Feedback

Ytterligare resurser