Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Node.js appar måste distribueras med alla nödvändiga npm-beroenden. App Service-distributionsmotorn körs npm install --production automatiskt när du distribuerar en Git-lagringsplats eller när du distribuerar ett Zip-paketmed build automation aktiverat. Om du distribuerar dina filer med FTP/S måste du dock ladda upp de paket som krävs manuellt.
Den här artikeln beskriver viktiga begrepp och innehåller instruktioner för Node.js utvecklare som distribuerar till App Service. Om du aldrig har använt Azure App Service slutför du snabbstartenNode.js och Node.js med MongoDB först.
Visa Node.js-versionen
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-körningen 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. På grund av potentiella säkerhetsrisker är dessa versioner inte garanterade att vara tillgängliga.
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örningar är inaktuella av organisationens underhåll eller har betydande sårbarheter. 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, en ARM-mall eller Bicep. Med de här distributionsalternativen kan du skapa inaktuella körningar som tas bort från 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.
Ange portnumret
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 ställer in porten i en enkel Express-app:
App Service anger miljövariabeln PORT i containern Node.js och vidarebefordrar inkommande begäranden till containern med det portnumret. För att ta emot begäranden bör din app lyssna på den port som anges i variabeln process.env.PORT . I följande exempel visas hur du ställer in porten 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 slutför App Service Build Automation följande steg:
- Kör ett anpassat skript om ett anges av
PRE_BUILD_SCRIPT_PATH. - Kör
npm installutan flaggor. Det här steget innehåller npmpreinstallochpostinstallskript och installerardevDependenciesäven . - Kör
npm run buildom ett byggskript har angetts i dinpackage.json-fil . - Kör
npm run build:azureom ettbuild:azureskript har angetts i dinpackage.json-fil . - Kör ett anpassat skript om ett 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. Skript med namnet preinstall och postinstall körs 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 som avgränsas 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 anpassning av byggautomatisering 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 starteller 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 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 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 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 npm startkontrollerar du bara att ett start skript finns i filenpackage.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-fil .
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 och kopplar felsökningsprogrammet. Du kan sedan göra begäranden till appen och se felsökningsprogrammet pausa vid brytpunkter.
När du är klar med felsökningen 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. Du kan sedan 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
# ----------
I slutet av det här avsnittet npm install --production körs. Lägg till kodavsnittet som du behöver för att köra det nödvändiga verktyget i slutet av Deployment avsnittet:
Ett exempel finns i exempletMEAN.js. I det här exemplet kör distributionsskriptet också 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 kontrollerar du X-Forwarded-Proto huvudet.
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. Den här konfigurationen är särskilt användbar för att säkerställa 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 med hjälp av express-urlrewrite-paketet .
Övervaka din app med hjälp av 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 Övervakning 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 på sidan. 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 Aktivera programövervakning i Azure App Service för .NET-, Node.js-, Python- och Java-program.
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 (
dependenciesjämfört meddevDependencies). - 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.
- Beroende på din package.json kan olika paket installeras för 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 går till appens URL. Det här felet inträffar troligen eftersom du inte har någon web.config fil. (Se mallen och ett exempel.)
Om du distribuerar dina filer med hjälp av Git eller med hjälp av ZIP-distribution med versionsautomation aktiverat genererar distributionsmotorn en web.config fil i appens webbrot (%HOME%\site\wwwroot) automatiskt om något av följande villkor är sant:
- Projektroten innehåller en package.json fil som definierar ett
startskript som innehåller sökvägen till en JavaScript-fil. - Projektroten innehåller antingen en server.js eller en app.js fil.
Den genererade web.config-filen är anpassad till det identifierade startskriptet. För andra distributionsmetoder lägger du till filenweb.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.