Node.js-alkalmazás konfigurálása az Azure App Service-hez

Node.js alkalmazásokat az összes szükséges NPM-függőséggel együtt kell üzembe helyezni. A App Service üzembehelyezési motor automatikusan futnpm install --production, amikor Git-adattárat vagy olyan Zip-csomagot helyez üzembe, amelyen engedélyezve van a buildautomatizálás. Ha azonban FTP/S használatával helyezi üzembe a fájlokat, manuálisan kell feltöltenie a szükséges csomagokat.

Ez az útmutató a App Service üzembe helyező Node.js fejlesztők számára nyújt alapvető fogalmakat és utasításokat. Ha még soha nem használta a Azure App Service, először kövesse az Node.js rövid útmutatót és Node.js a MongoDB-vel című oktatóanyagot.

Node.js verzió megjelenítése

Az aktuális Node.js verzió megjelenítéséhez futtassa a következő parancsot a Cloud Shell:

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

Az összes támogatott Node.js-verzió megjelenítéséhez keresse meg https://<sitename>.scm.azurewebsites.net/api/diagnostics/runtime vagy futtassa a következő parancsot a Cloud Shell:

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

Az aktuális Node.js verzió megjelenítéséhez futtassa a következő parancsot a Cloud Shell:

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

Az összes támogatott Node.js-verzió megjelenítéséhez futtassa a következő parancsot a Cloud Shell:

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

Node.js verzió beállítása

Ha az alkalmazást egy támogatott Node.js verzióra szeretné állítani, futtassa a következő parancsot a Cloud Shell a támogatott verzió beállításáhozWEBSITE_NODE_DEFAULT_VERSION:

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

Megjegyzés

Ez a példa az ajánlott "tilde szintaxist" használja a Node.js 16 futtatókörnyezet legújabb elérhető verziójának App Service.

Mivel a futtatókörnyezetet a platform rendszeresen frissíti és frissíti, nem ajánlott egy adott alverziót/javítást célozni, mivel ezek a lehetséges biztonsági kockázatok miatt nem garantáltan elérhetők.

Megjegyzés

A Node.js verziót a projektben kell beállítania package.json. Az üzembehelyezési motor egy külön folyamatban fut, amely tartalmazza az összes támogatott Node.js verziót.

Ha az alkalmazást egy támogatott Node.js verzióra szeretné állítani, futtassa a következő parancsot a Cloud Shell:

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

Ez a beállítás határozza meg a használni kívánt Node.js verziót futásidőben és a Kuduban történő automatikus csomag-visszaállítás során is.

Megjegyzés

A Node.js verziót a projektben kell beállítania package.json. Az üzembehelyezési motor egy külön tárolóban fut, amely tartalmazza az összes támogatott Node.js verziót.

Portszám lekérése

A Node.js alkalmazásnak a megfelelő portot kell figyelnie a bejövő kérések fogadásához.

Windows App Service Node.js-alkalmazásokat az IISNode üzemelteti, és a Node.js alkalmazásnak figyelnie kell a process.env.PORT változóban megadott portot. Az alábbi példa bemutatja, hogyan teheti ezt meg egy egyszerű Express-alkalmazásban:

App Service beállítja a környezeti változót PORT a Node.js tárolóban, és továbbítja a bejövő kéréseket a tárolónak az adott portszámon. A kérések fogadásához az alkalmazásnak figyelnie kell a portot a használatával process.env.PORT. Az alábbi példa bemutatja, hogyan teheti ezt meg egy egyszerű Express-alkalmazásban:

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}`)
})

Buildautomatizálás testreszabása

Ha az alkalmazást Git használatával vagy olyan zip-csomagokkal helyezi üzembe, amelyeken engedélyezve van a buildautomatizálás, a App Service buildautomatizálási lépések az alábbi sorrendben haladnak végig:

  1. Futtassa az egyéni szkriptet, ha azt a adja PRE_BUILD_SCRIPT_PATHmeg.
  2. Futtassa a parancsot npm install jelzők nélkül, amely tartalmazza az npm-et preinstall és postinstall a szkripteket, valamint telepíti a parancsot devDependencies.
  3. Futtassa a parancsot npm run build , ha a package.json fájlban meg van adva buildszkript.
  4. Futtassa a parancsot npm run build:azure , ha a package.json fájlban meg van adva egy build:azure szkript.
  5. Futtassa az egyéni szkriptet, ha azt a adja POST_BUILD_SCRIPT_PATHmeg.

Megjegyzés

Az npm-dokumentumokban leírtak szerint a szkriptek neve prebuild és postbuild futtatása a előtt és után buildtörténik, ha meg van adva. preinstall és postinstall futtassa a parancsot a előtt és után install.

PRE_BUILD_COMMAND és POST_BUILD_COMMAND alapértelmezés szerint üres környezeti változók. A build előtti parancsok futtatásához definiálja a következőt PRE_BUILD_COMMAND: . A build utáni parancsok futtatásához adja meg a következőt POST_BUILD_COMMAND: .

Az alábbi példa a két változót egy parancssorozatra adja meg, vesszővel elválasztva.

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"

További környezeti változók a buildautomatizálás testreszabásához: Oryx-konfiguráció.

Az App Service linuxos Node.js-alkalmazások futtatásáról és buildeléséről az Oryx dokumentációja: A Node.js alkalmazások észlelése és létrehozása című témakörben talál további információt.

Node.js-kiszolgáló konfigurálása

A Node.js tárolókhoz a PM2, az éles folyamatkezelő is hozzá van érkezik. Az alkalmazást úgy konfigurálhatja, hogy PM2-vel, NPM-sel vagy egyéni paranccsal induljon el.

Eszköz Cél
Futtatás a PM2-vel Ajánlott – Éles vagy előkészítési használat. A PM2 teljes körű alkalmazáskezelési platformot biztosít.
Futtassa az npm start parancsot Csak fejlesztési célokra használható.
Egyéni parancs futtatása Fejlesztés vagy előkészítés.

Futtatás a PM2-vel

A tároló automatikusan PM2-vel indítja el az alkalmazást, amikor a projektben megtalálható az egyik gyakori Node.js fájl:

  • bin/www
  • server.js
  • app.js
  • index.js
  • hostingstart.js
  • A következő PM2-fájlok egyike: process.json és ecosystem.config.js

Egyéni kezdőfájlt is konfigurálhat a következő kiterjesztésekkel:

  • Egy.js fájl
  • .json, .config.js, .yaml vagy .yml kiterjesztésű PM2-fájl

Megjegyzés

A Node 14 LTS-től kezdve a tároló nem indítja el automatikusan az alkalmazást a PM2-vel. Ha pm2-vel szeretné elindítani az alkalmazást, állítsa az indítási parancsot értékre pm2 start <.js-file-or-PM2-file> --no-daemon. Ügyeljen arra, hogy az argumentumot használja, mert a --no-daemon PM2-nek az előtérben kell futnia ahhoz, hogy a tároló megfelelően működjön.

Egyéni kezdőfájl hozzáadásához futtassa a következő parancsot a Cloud Shell:

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

Egyéni parancs futtatása

App Service elindíthatja az alkalmazást egy egyéni paranccsal, például egy végrehajtható fájllal, például run.sh. A futtatásához npm run start:prodfuttassa például a következő parancsot a Cloud Shell:

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

Futtassa az npm start parancsot

Ha az paranccsal npm startszeretné elindítani az alkalmazást, csak győződjön meg arról, hogy egy start szkript szerepel a package.json fájlban. Például:

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

Ha egyéni package.json fájlt szeretne használni a projektben, futtassa a következő parancsot a Cloud Shell:

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

Távoli hibakeresés

Megjegyzés

A távoli hibakeresés jelenleg előzetes verzióban érhető el.

A Node.js alkalmazást távolról is hibakereséssel végezheti el a Visual Studio Code-ban , ha a PM2-vel való futtatásra konfigurálja, kivéve, ha .config.js,.yml vagy .yaml használatával futtatja.

A legtöbb esetben nincs szükség további konfigurációra az alkalmazáshoz. Ha az alkalmazás egy process.json fájllal (alapértelmezett vagy egyéni) fut, annak rendelkeznie kell egy script tulajdonsággal a JSON-gyökérben. Például:

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

A Visual Studio Code távoli hibakereséshez való beállításához telepítse a App Service bővítményt. Kövesse a bővítmény oldalán található utasításokat, és jelentkezzen be az Azure-ba a Visual Studio Code-ban.

Az Azure Explorerben keresse meg a hibakereséshez használni kívánt alkalmazást, kattintson rá a jobb gombbal, és válassza a Távoli hibakeresés indítása lehetőséget. Kattintson az Igen gombra az alkalmazás engedélyezéséhez. App Service elindít egy alagútproxyt, és csatolja a hibakeresőt. Ezután kéréseket intézhet az alkalmazáshoz, és megtekintheti, hogy a hibakereső szünetel a töréspontoknál.

Ha végzett a hibakereséssel, állítsa le a hibakeresőt a Leválasztás lehetőség kiválasztásával. Amikor a rendszer kéri, kattintson az Igen gombra a távoli hibakeresés letiltásához. Ha később le szeretné tiltani, kattintson ismét a jobb gombbal az alkalmazásra az Azure Explorerben, és válassza a Távoli hibakeresés letiltása lehetőséget.

Hozzáférés a környezeti változókhoz

Az App Service-szel az alkalmazás kódján kívül is megadhatja az alkalmazások beállításait. Ezután a standard Node.js mintával érheti el őket. Például egy NODE_ENV nevű alkalmazásbeállítás hozzáféréséhez használja a következő kódot:

process.env.NODE_ENV

Grunt/Bower/Gulp futtatása

Alapértelmezés szerint App Service buildautomatizálás akkor futnpm install --production, ha felismeri, hogy egy Node.js alkalmazás a Giten keresztül van üzembe helyezve, vagy zip-alapú üzembe helyezéssel, amelyen engedélyezve van a buildautomatizálás. Ha az alkalmazásnak szüksége van valamelyik népszerű automatizálási eszközre, például a Gruntra, a Bowerre vagy a Gulpra, a futtatásához egyéni üzembehelyezési szkriptet kell megadnia.

Ahhoz, hogy az adattár futtathassa ezeket az eszközöket, hozzá kell adnia őket a package.json függőségeihez. Például:

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

Egy helyi terminálablakban módosítsa a könyvtárat az adattár gyökerére, és futtassa a következő parancsokat:

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

Az adattár gyökerének most már két további fájlja van: .deployment és deploy.sh.

Nyissa meg deploy.sh , és keresse meg az Deployment alábbihoz hasonló szakaszt:

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

Ez a szakasz a futtatásával npm install --productionvégződik. Adja hozzá a szakasz végén a szükséges eszköz futtatásához szükséges kódszakaszt Deployment :

Tekintsen meg egy példát a MEAN.js mintában, ahol az üzembehelyezési szkript egy egyéni npm install parancsot is futtat.

Bower

Ez a kódrészlet a parancsot futtatja 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

Nyelő

Ez a kódrészlet a parancsot futtatja 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

Ez a kódrészlet a parancsot futtatja grunt.

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

HTTPS-munkamenet észlelése

A App Service A TLS/SSL leállítása a hálózati terheléselosztóknál történik, így minden HTTPS-kérés titkosítatlan HTTP-kérésként éri el az alkalmazást. Ha az alkalmazáslogikának ellenőriznie kell, hogy a felhasználói kérések titkosítva vannak-e, vizsgálja meg a fejlécet X-Forwarded-Proto .

A népszerű webes keretrendszerek lehetővé teszik a X-Forwarded-* szabványos alkalmazásminta információinak elérését. Az Expressbenmegbízhatósági proxykat használhat. Például:

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

Diagnosztikai naplók elérése

Az alkalmazáskódból létrehozott konzolnaplók App Service-ben történő eléréséhez kapcsolja be a diagnosztikai naplózást a következő parancs a Cloud Shellben történő futtatásával:

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

A --level lehetséges értékei: Error, Warning, Info és Verbose. Minden szint tartalmazza az azt megelőző szintet. Például: az Error csak a hibaüzeneteket tartalmazza, a Verbose pedig az összes üzenetet.

Ha a diagnosztikai naplózás be van kapcsolva, futtassa a következő parancsot a naplóstream megtekintéséhez:

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

Ha nem jelennek meg azonnal a konzolnaplófájlok, ellenőrizze ismét 30 másodperc múlva.

Megjegyzés

A naplófájlokat a böngészőből is megtekintheti a következő címen: https://<app-name>.scm.azurewebsites.net/api/logs/docker.

A Ctrl+C billentyűparanccsal bármikor leállíthatja a naplóstreamelést.

A tárolón belülről létrehozott konzolnaplókhoz hozzáférhet.

Először kapcsolja be a tárolónaplózást a következő parancs futtatásával:

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

Cserélje le <app-name> a és <resource-group-name> a elemet a webalkalmazásának megfelelő nevekre.

A tárolónaplózás bekapcsolása után futtassa a következő parancsot a naplóstream megtekintéséhez:

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

Ha nem jelennek meg azonnal a konzolnaplófájlok, ellenőrizze ismét 30 másodperc múlva.

Ha bármikor le szeretné állítani a naplóstreamelést, írja be a Ctrl+C billentyűt.

A naplófájlokat egy böngészőben is megvizsgálhatja a címen https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Monitorozás az Application Insights segítségével

Az Application Insights lehetővé teszi, hogy kódmódosítások nélkül monitorozza az alkalmazás teljesítményét, kivételeit és használatát. Az App Insights-ügynök csatolásához nyissa meg a webalkalmazást a portálon, és válassza az Application Insights elemet a Beállítások területen, majd válassza az Application Insights bekapcsolása lehetőséget. Ezután válasszon ki egy meglévő App Insights-erőforrást, vagy hozzon létre egy újat. Végül válassza a lenti Alkalmaz lehetőséget. A webalkalmazás PowerShell-lel történő kialakításához tekintse meg ezeket az utasításokat

Ez az ügynök figyeli a kiszolgálóoldali Node.js alkalmazást. Az ügyféloldali JavaScript monitorozásához adja hozzá a JavaScript SDK-t a projekthez.

További információkért lásd az Application Insights bővítmény kibocsátási megjegyzéseit.

Hibaelhárítás

Ha egy működő Node.js alkalmazás eltérően viselkedik App Service vagy hibákat tapasztal, próbálkozzon a következőkkel:

  • Hozzáférés a naplóstreamhez.
  • Tesztelje az alkalmazást helyileg éles módban. App Service éles módban futtatja a Node.js-alkalmazásokat, ezért gondoskodnia kell arról, hogy a projekt a várt módon működjön helyi üzemi módban. Például:
    • A package.json fájltól függően különböző csomagok telepíthetők éles üzemmódra (dependencies és devDependencies).
    • Egyes webes keretrendszerek eltérő módon helyezhetnek üzembe statikus fájlokat éles módban.
    • Egyes webes keretrendszerek egyéni indítási szkripteket használhatnak éles módban való futtatáskor.
  • Futtassa az alkalmazást App Service fejlesztési módban. Például a MEAN.js-ben az alkalmazás beállításával fejlesztési módra állíthatja az NODE_ENV alkalmazást futtatókörnyezetben.

Nincs engedélye a könyvtár vagy lap megtekintésére

Miután telepítette a Node.js-kódot egy natív Windows-alkalmazásba App Service, az alkalmazás URL-címére való navigáláskor megjelenhet az üzenet You do not have permission to view this directory or page. a böngészőben. Ez valószínűleg azért van, mert nincs web.config fájlja (lásd a sablont és egy példát).

Ha a fájlokat a Git használatával helyezi üzembe, vagy ha zip-alapú üzembe helyezést használ, és engedélyezve van a buildautomatizálás, az üzembehelyezési motor automatikusan létrehoz egy web.config az alkalmazás webes gyökerében (%HOME%\site\wwwroot), ha az alábbi feltételek valamelyike teljesül:

  • A projektgyökér rendelkezik egy package.json fájllal, amely egy start JavaScript-fájl elérési útját tartalmazó szkriptet határoz meg.
  • A projekt gyökerének server.js vagy app.jsvan.

A létrehozott web.config az észlelt indítási szkripthez van igazítva. Más üzembehelyezési módszerek esetén manuálisan adja hozzá ezt a web.config . Győződjön meg arról, hogy a fájl megfelelően van formázva.

Ha ZIP-alapú üzembe helyezést használ (például a Visual Studio Code-on keresztül), mindenképpen engedélyezze a buildautomatizálást , mert alapértelmezés szerint nincs engedélyezve. az webapp up ZIP-alapú üzembe helyezést használ, és a buildautomatizálás engedélyezve van.

robots933456 a naplókban

A következő üzenet jelenhet meg a tárolónaplókban:

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

Az üzenet biztonságosan figyelmen kívül hagyható. /robots933456.txt egy olyan próba URL-cím, amelyet az App Service annak a vizsgálatára használ, hogy a tároló képes-e a kérések kiszolgálására. A 404-es válasz egyszerűen azt jelenti, hogy a cím nem létezik, azonban jelzi az App Service számára, hogy a tároló kifogástalan állapotú, és készen áll a kérések megválaszolására.

Következő lépések

Vagy tekintse meg a további erőforrásokat:

Környezeti változók és alkalmazásbeállítások referenciája