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

Artikel
09/13/2024

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öljer du först Node.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 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"

Kommentar

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-körning i 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 garanteras vara tillgängliga på grund av potentiella säkerhetsrisker.

Kommentar

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.

Kommentar

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 variabeln process.env.PORT . 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 versionsautomatisering

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.

Kommentar

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 – Användning av produktion eller mellanlagring. PM2 tillhandahåller en apphanteringsplattform med full service.
Kör med npm start	Endast utveckling används.
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

Kommentar

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 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 kontrollerar npm startdu bara att ett start skript finns i filen package.json . 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 slutar med att köra 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:

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 kontrollerar du X-Forwarded-Proto huvudet.

Med populära ramverk får du åtkomst till X-Forwarded-* information i standardappens mönster. 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 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.

Kommentar

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.

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 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. 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 MEAN.js kan du till exempel ställa in appen på utvecklingsläge vid körning 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 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.

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 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

Hämta portnummer

Anpassa versionsautomatisering

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

Bower

Klunk

Grunt

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

robots933456 i loggar

Nästa steg

Feedback

Ytterligare resurser