Een Node.js-app configureren voor Azure App Service

Artikel
06/01/2023

Node.js-apps moeten worden geïmplementeerd met alle vereiste NPM-afhankelijkheden. De App Service implementatie-engine wordt automatisch voor u uitgevoerd npm install --production wanneer u een Git-opslagplaats of een Zip-pakket implementeert waarvoor buildautomatisering is ingeschakeld. Als u uw bestanden echter implementeert met FTP/S, moet u de vereiste pakketten handmatig uploaden.

Deze handleiding bevat belangrijke concepten en instructies voor Node.js ontwikkelaars die implementeren in App Service. Als u Azure App Service nog nooit hebt gebruikt, volgt u eerst de zelfstudieNode.js en Node.js met MongoDB.

Node.js-versie weergeven

Als u de huidige Node.js versie wilt weergeven, voert u de volgende opdracht uit in de Cloud Shell:

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

Als u alle ondersteunde Node.js versies wilt weergeven, gaat u naar https://<sitename>.scm.azurewebsites.net/api/diagnostics/runtime of voert u de volgende opdracht uit in de Cloud Shell:

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

Als u de huidige Node.js versie wilt weergeven, voert u de volgende opdracht uit in de Cloud Shell:

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

Als u alle ondersteunde Node.js versies wilt weergeven, voert u de volgende opdracht uit in de Cloud Shell:

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

Node.js-versie instellen

Als u uw app wilt instellen op een ondersteunde Node.js-versie, voert u de volgende opdracht uit in de Cloud Shell om in te stellen WEBSITE_NODE_DEFAULT_VERSION op een ondersteunde versie:

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

Notitie

In dit voorbeeld wordt de aanbevolen 'tilde-syntaxis' gebruikt om de meest recente beschikbare versie van Node.js 16 runtime op App Service te richten.

Omdat de runtime regelmatig wordt gepatcht en bijgewerkt door het platform, wordt het niet aanbevolen om een specifieke secundaire versie/patch te gebruiken, omdat deze niet gegarandeerd beschikbaar zijn vanwege mogelijke beveiligingsrisico's.

Notitie

U moet de Node.js versie instellen in de versie van package.jsonuw project. De implementatie-engine wordt uitgevoerd in een afzonderlijk proces dat alle ondersteunde Node.js versies bevat.

Als u uw app wilt instellen op een ondersteunde Node.js-versie, voert u de volgende opdracht uit in de Cloud Shell:

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

Met deze instelling wordt de Node.js versie opgegeven die moet worden gebruikt, zowel tijdens runtime als tijdens het automatisch herstellen van pakketten in Kudu.

Notitie

U moet de Node.js versie instellen in de versie van package.jsonuw project. De implementatie-engine wordt uitgevoerd in een afzonderlijke container die alle ondersteunde Node.js versies bevat.

Poortnummer ophalen

Uw Node.js-app moet luisteren naar de juiste poort om binnenkomende aanvragen te ontvangen.

In App Service in Windows worden Node.js apps gehost met IISNode en moet uw Node.js app luisteren naar de poort die is opgegeven in de process.env.PORT variabele. In het volgende voorbeeld ziet u hoe u dit doet in een eenvoudige Express-app:

App Service stelt de omgevingsvariabele PORT in de Node.js container in en stuurt de binnenkomende aanvragen door naar uw container op dat poortnummer. Als u de aanvragen wilt ontvangen, moet uw app naar die poort luisteren met behulp van process.env.PORT. In het volgende voorbeeld ziet u hoe u dit doet in een eenvoudige 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}`)
})

De automatisering van bouwbewerkingen aanpassen

Als u uw app implementeert met behulp van Git of zip-pakketten waarvoor build-automatisering is ingeschakeld, wordt de App Service buildautomatisering de volgende volgorde doorlopen:

Voer aangepast script uit als dit is opgegeven door PRE_BUILD_SCRIPT_PATH.
Voer uit npm install zonder vlaggen, waaronder npm preinstall en postinstall scripts en installeert devDependenciesook .
Voer uit npm run build als er een buildscript is opgegeven in uw package.json.
Voer uit npm run build:azure als er een build:azure-script is opgegeven in uw package.json.
Voer aangepast script uit als dit is opgegeven door POST_BUILD_SCRIPT_PATH.

Notitie

Zoals beschreven in npm-documenten, worden scripts met de naam prebuild en postbuild uitgevoerd vóór en na buildrespectievelijk, indien opgegeven. preinstall en postinstall respectievelijk vóór en na installuitvoeren.

PRE_BUILD_COMMAND en POST_BUILD_COMMAND zijn omgevingsvariabelen die standaard leeg zijn. Als u vooraf gebouwde opdrachten wilt uitvoeren, definieert u PRE_BUILD_COMMAND. Als u achteraf gebouwde opdrachten wilt uitvoeren, definieert u POST_BUILD_COMMAND.

In het volgende voorbeeld worden de twee variabelen voor een reeks opdrachten opgegeven, gescheiden door komma's.

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"

Zie Oryx-configuratie voor aanvullende omgevingsvariabelen om bouwautomatisering aan te passen.

Zie De Oryx-documentatie: Hoe Node.js apps worden gedetecteerd en gebouwd voor meer informatie over hoe App Service wordt uitgevoerd en Node.js apps in Linux bouwt.

Node.js-server configureren

De Node.js containers worden geleverd met PM2, een productieprocesmanager. U kunt uw app configureren om te beginnen met PM2, met NPM of met een aangepaste opdracht.

Hulpprogramma	Doel
Uitvoeren met PM2	Aanbevolen : gebruik van productie of fasering. PM2 biedt een volledig app-beheerplatform.
Npm start uitvoeren	Alleen ontwikkelingsgebruik.
Aangepaste opdracht uitvoeren	Ontwikkeling of fasering.

Uitvoeren met PM2

De container start uw app automatisch met PM2 wanneer een van de algemene Node.js bestanden in uw project wordt gevonden:

bin/www
server.js
app.js
index.js
hostingstart.js
Een van de volgende PM2-bestanden: process.json en ecosystem.config.js

U kunt ook een aangepast startbestand configureren met de volgende extensies:

Een .js-bestand
Een PM2-bestand met de extensie .json, .config.js, .yaml of .yml

Notitie

Vanaf Node 14 LTS start de container uw app niet automatisch met PM2. Als u uw app wilt starten met PM2, stelt u de opstartopdracht in op pm2 start <.js-file-or-PM2-file> --no-daemon. Zorg ervoor dat u het --no-daemon argument gebruikt, omdat PM2 op de voorgrond moet worden uitgevoerd om de container goed te laten werken.

Als u een aangepast startbestand wilt toevoegen, voert u de volgende opdracht uit in de Cloud Shell:

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

Aangepaste opdracht uitvoeren

App Service kunt uw app starten met behulp van een aangepaste opdracht, zoals een uitvoerbaar bestand zoals run.sh. Als u bijvoorbeeld wilt uitvoerennpm run start:prod, voert u de volgende opdracht uit in de Cloud Shell:

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

Npm start uitvoeren

Als u uw app wilt starten met npm start, moet u ervoor zorgen dat er een start script in het bestand package.json staat. Bijvoorbeeld:

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

Als u een aangepaste package.json in uw project wilt gebruiken, voert u de volgende opdracht uit in de Cloud Shell:

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

Foutopsporing op afstand

Notitie

Externe foutopsporing is momenteel beschikbaar als preview-versie.

U kunt op afstand fouten opsporen in uw Node.js-app in Visual Studio Code als u deze configureert voor uitvoering met PM2, behalve wanneer u de app uitvoert met behulp van een .config.js,.yml of .yaml.

In de meeste gevallen is er geen extra configuratie vereist voor uw app. Als uw app wordt uitgevoerd met een process.json-bestand (standaard of aangepast), moet deze een script eigenschap hebben in de JSON-hoofdmap. Bijvoorbeeld:

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

Als u Visual Studio Code wilt instellen voor foutopsporing op afstand, installeert u de extensie App Service. Volg de instructies op de extensiepagina en meld u aan bij Azure in Visual Studio Code.

Zoek in Azure Explorer de app die u wilt opsporen, klik er met de rechtermuisknop op en selecteer Externe foutopsporing starten. Klik op Ja om dit in te schakelen voor uw app. App Service start een tunnelproxy voor u en voegt het foutopsporingsprogramma toe. U kunt vervolgens aanvragen indienen bij de app en zien dat het foutopsporingsprogramma wordt onderbroken bij onderbrekingspunten.

Als u klaar bent met foutopsporing, stopt u het foutopsporingsprogramma door Verbinding verbreken te selecteren. Wanneer u hierom wordt gevraagd, moet u op Ja klikken om foutopsporing op afstand uit te schakelen. Als u dit later wilt uitschakelen, klikt u opnieuw met de rechtermuisknop op uw app in de Azure-verkenner en selecteert u Externe foutopsporing uitschakelen.

Toegang tot omgevingsvariabelen

In App Service kunt u app-instellingen configureren buiten uw app-code. Vervolgens kunt u ze openen met behulp van het standaardpatroon Node.js. Voor toegang tot bijvoorbeeld de app-instelling NODE_ENV gebruikt u de volgende code:

process.env.NODE_ENV

Grunt/Bower/Gulp uitvoeren

Standaard wordt App Service buildautomatisering uitgevoerd npm install --production wanneer wordt herkend dat een Node.js app wordt geïmplementeerd via Git of via zip-implementatie waarvoor buildautomatisering is ingeschakeld. Als uw app een van de populaire automatiseringsprogramma's vereist, zoals Grunt, Bower of Gulp, moet u een aangepast implementatiescript opgeven om deze uit te voeren.

Als u wilt dat uw opslagplaats deze hulpprogramma's kan uitvoeren, moet u ze toevoegen aan de afhankelijkheden in package.json. Bijvoorbeeld:

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

Wijzig vanuit een lokaal terminalvenster de map in de hoofdmap van de opslagplaats en voer de volgende opdrachten uit:

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

De hoofdmap van de opslagplaats heeft nu twee extra bestanden: .deployment en deploy.sh.

Open deploy.sh en zoek de Deployment sectie, die er als volgt uitziet:

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

Deze sectie eindigt met het uitvoeren van npm install --production. Voeg de codesectie toe die u nodig hebt om het vereiste hulpprogramma uit te voeren aan het einde van de Deployment sectie:

Bower
Gulp
Grunt

Zie een voorbeeld in het voorbeeld MEAN.js, waarin het implementatiescript ook een aangepaste npm install opdracht uitvoert.

Bower

Met dit codefragment wordt uitgevoerd 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

Gulp

Met dit codefragment wordt uitgevoerd 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

Met dit codefragment wordt uitgevoerd grunt.

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

HTTPS-sessie detecteren

In App Service vindt TLS/SSL-beëindiging plaats bij de netwerktaakverdelers, zodat alle HTTPS-aanvragen uw app bereiken als niet-versleutelde HTTP-aanvragen. Inspecteer de header X-Forwarded-Proto als de app-logica moet controleren of de aanvragen van gebruikers al dan niet zijn versleuteld.

Populaire webframeworks bieden toegang tot de X-Forwarded-*-informatie in het patroon van de standaard-app. In Express kunt u vertrouwensproxy's gebruiken. Bijvoorbeeld:

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

Toegang tot diagnostische logboeken

Als u toegang wilt tot de consolelogboeken die worden gegenereerd binnen uw toepassingscode in de App Service, schakelt u diagnostische logboekregistratie in door de volgende opdracht in de Cloud Shell uit te voeren:

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

Mogelijk waarden voor --level zijn: Error, Warning, Info en Verbose. Elk hoger niveau omvat het vorige niveau. Bijvoorbeeld: Error omvat alleen foutberichten en Verbose omvat alle berichten.

Nadat diagnostische logboekregistratie is ingeschakeld, voert u de volgende opdracht uit om de logboekstream te zien:

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

Als u de consolelogboeken niet meteen ziet, probeert u het opnieuw na 30 seconden.

Notitie

U kunt ook de logboekbestanden van de browser inspecteren op https://<app-name>.scm.azurewebsites.net/api/logs/docker.

U kunt op elk gewenst moment Ctrl+C typen om te stoppen met logboekstreaming.

U hebt vanuit de container toegang tot de consolelogboeken.

Schakel eerst logboekregistratie voor containers in door de volgende opdracht uit te voeren:

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

Vervang <app-name> en <resource-group-name> door de namen die van toepassing zijn op uw web-app.

Zodra logboekregistratie is ingeschakeld, voert u de volgende opdracht uit om de logboekstream te zien:

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

Als u de consolelogboeken niet meteen ziet, probeert u het opnieuw na 30 seconden.

U kunt op elk gewenst moment stoppen met logboekstreaming door Ctrl+C te typen.

U kunt ook de logboekbestanden in een browser inspecteren op https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Controleren met behulp van Application Insights

Met Application Insights kunt u de prestaties, uitzonderingen en het gebruik van uw toepassing bewaken zonder codewijzigingen aan te brengen. Als u de App Insights-agent wilt koppelen, gaat u naar uw web-app in de portal en selecteert u Application Insights onder Instellingen en selecteert u vervolgens Application Insights inschakelen. Selecteer vervolgens een bestaande App Insights-resource of maak een nieuwe. Selecteer ten slotte Toepassen onderaan. Raadpleeg deze instructies om uw web-app te instrumentatie met behulp van PowerShell

Deze agent bewaakt uw Node.js toepassing aan de serverzijde. Als u uw JavaScript aan de clientzijde wilt bewaken, voegt u de JavaScript-SDK toe aan uw project.

Zie de opmerkingen bij de release van de Application Insights-extensie voor meer informatie.

Problemen oplossen

Wanneer een werkende Node.js-app zich anders gedraagt in App Service of fouten bevat, probeert u het volgende:

Open de logboekstream.
Test de app lokaal in de productiemodus. App Service uw Node.js-apps in de productiemodus uitvoert, dus u moet ervoor zorgen dat uw project lokaal werkt zoals verwacht in de productiemodus. Bijvoorbeeld:
- Afhankelijk van uw package.json kunnen verschillende pakketten worden geïnstalleerd voor de productiemodus (dependencies vs. devDependencies).
- In bepaalde webframeworks kunnen statische bestanden mogelijk anders worden geïmplementeerd in de productiemodus.
- Bepaalde webframeworks kunnen aangepaste opstartscripts gebruiken wanneer ze worden uitgevoerd in de productiemodus.
Voer uw app uit in App Service in de ontwikkelingsmodus. In MEAN.jskunt u uw app bijvoorbeeld instellen op de ontwikkelmodus in runtime door de NODE_ENV app-instelling in te stellen.

U bent niet gemachtigd om deze map of pagina weer te geven

Nadat u uw Node.js code hebt geïmplementeerd in een systeemeigen Windows-app in App Service, ziet u mogelijk het bericht You do not have permission to view this directory or page. in de browser wanneer u naar de URL van uw app navigeert. Dit komt waarschijnlijk omdat u geen web.config-bestand hebt (zie de sjabloon en een voorbeeld).

Als u uw bestanden implementeert met behulp van Git of met behulp van ZIP-implementatie waarvoor buildautomatisering is ingeschakeld, genereert de implementatie-engine automatisch een web.config in de webhoofdmap van uw app (%HOME%\site\wwwroot) als aan een van de volgende voorwaarden wordt voldaan:

De hoofdmap van het project bevat een package.json die een start script definieert dat het pad van een JavaScript-bestand bevat.
De hoofdmap van het project heeft een server.js of een app.js.

De gegenereerde web.config is afgestemd op het gedetecteerde beginscript. Voor andere implementatiemethoden voegt u deze web.config handmatig toe. Zorg ervoor dat het bestand juist is geformatteerd.

Als u zip-implementatie gebruikt (bijvoorbeeld via Visual Studio Code), moet u bouwautomatisering inschakelen , omdat dit niet standaard is ingeschakeld. az webapp up maakt gebruik van ZIP-implementatie met bouwautomatisering ingeschakeld.

robots933456 in logboeken

U ziet mogelijk het volgende bericht in de containerlogboeken:

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

U kunt dit bericht veilig negeren. /robots933456.txt is een dummy-URL-pad dat App Service gebruikt om te controleren of de container aanvragen kan verwerken. Een 404-antwoord geeft alleen aan dat het pad niet bestaat, maar laat App Service wel weten dat de container in orde is en klaar is om te reageren op aanvragen.

Volgende stappen

Zelfstudie: Node.js-app met MongoDB

Veelgestelde vragen over App Service Linux

Of zie aanvullende resources:

Naslaginformatie over omgevingsvariabelen en app-instellingen

Een Node.js-app configureren voor Azure App Service

Node.js-versie weergeven

Node.js-versie instellen

Poortnummer ophalen

De automatisering van bouwbewerkingen aanpassen

Node.js-server configureren

Uitvoeren met PM2

Aangepaste opdracht uitvoeren

Npm start uitvoeren

Foutopsporing op afstand

Toegang tot omgevingsvariabelen

Grunt/Bower/Gulp uitvoeren

Bower

Gulp

Grunt

HTTPS-sessie detecteren

Toegang tot diagnostische logboeken

Controleren met behulp van Application Insights

Problemen oplossen

U bent niet gemachtigd om deze map of pagina weer te geven

robots933456 in logboeken

Volgende stappen

Aanvullende resources