Megosztás a következőn keresztül:


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. Az App Service üzembehelyezési motorja automatikusan fut npm install --production Önért Git-adattár üzembe helyezésekor, vagy ha egy Zip-csomagot helyez üzembe, és engedélyezve van a buildautomatizálás. Ha azonban FTP/S használatával telepíti a fájlokat, manuálisan kell feltöltenie a szükséges csomagokat.

Ez az útmutató az App Service-ben üzembe helyező Node.js fejlesztők alapvető fogalmait és utasításait tartalmazza. Ha még soha nem használta a Azure-alkalmazás szolgáltatást, először kövesse az Node.js rövid útmutatót, és Node.js a MongoDB oktatóanyagával.

Node.js verzió megjelenítése

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

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

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

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

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é beállítani, futtassa az alábbi parancsot a Cloud Shellben, hogy egy támogatott verzióra állítsa beWEBSITE_NODE_DEFAULT_VERSION:

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

Feljegyzés

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

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

Feljegyzés

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

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

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

Ez a beállítás megadja 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.

Feljegyzé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.

A Windows App Service-ben 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:

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

Testreszabott építési automatizálás

Ha az alkalmazást a Git használatával vagy a buildautomatizálást engedélyező zip-csomagok használatával helyezi üzembe, az App Service buildautomatizálása az alábbi sorrendben halad végig:

  1. Futtassa az egyéni szkriptet, ha az egyiket a PRE_BUILD_SCRIPT_PATH.
  2. Futtassa npm install a jelölők nélkül, amely tartalmazza az npm-et preinstall és postinstall a szkripteket, és telepíti devDependenciesis.
  3. Futtassa npm run build , ha egy buildszkript van megadva a package.json.
  4. Futtassa npm run build:azure , ha egy build:azure-szkript van megadva a package.json.
  5. Futtassa az egyéni szkriptet, ha a megadott.POST_BUILD_SCRIPT_PATH

Feljegyzés

Amint az az npm-dokumentumokban is szerepel, a szkriptek neve prebuild és postbuild futtatása előtt és utánbuild, ha meg van adva. preinstall és postinstall futtassa az előtt és után install, illetve.

PRE_BUILD_COMMAND és POST_BUILD_COMMAND alapértelmezés szerint üres környezeti változók. Az előzetes buildelési parancsok futtatásához definiálja a következőt PRE_BUILD_COMMAND: . A buildelés utáni parancsok futtatásához definiálja a következőt POST_BUILD_COMMAND:

Az alábbi példa a két változót használja a parancsok vesszővel elválasztott sorozatának megadására.

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"

A buildautomatizálás testreszabására szolgáló további környezeti változókról az Oryx konfigurációja című témakörben olvashat.

Az App Service linuxos alkalmazások futtatásáról és Node.js összeállításáról az Oryx dokumentációjában talál további információt: Az alkalmazások észlelése és létrehozása Node.js.

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

A Node.js tárolókhoz a PM2, egy termelési folyamatkezelő található. Az alkalmazást úgy konfigurálhatja, hogy PM2-vel, npm-indítással vagy egyéni paranccsal kezdődjön.

Eszköz Cél
Futtatás a PM2-vel Ajánlott – Éles vagy átmeneti használat. A PM2 teljes körű alkalmazáskezelési platformot biztosít.
Futtatás npm indítással Csak fejlesztési célokra használható.
Futtatás egyéni paranccsal Fejlesztés vagy előkészítés.

Futtatás a PM2-vel

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

  • bin/www
  • server.js
  • app.js
  • index.js
  • hostingstart.js
  • Az alábbi PM2-fájlok egyike: process.json vagy ecosystem.config.js

Egyéni kezdőfájlt a következő bővítményekkel is konfigurálhat:

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

Feljegyzé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 a következőre pm2 start <.js-file-or-PM2-file> --no-daemon: . Mindenképpen használja az argumentumot, 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 Shellben:

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

Futtatás egyéni paranccsal

Az App Service egy egyéni paranccsal indíthatja el az alkalmazást, például egy végrehajtható parancsot, például run.sh. Futtatáshoz npm run start:prodfuttassa például a következő parancsot a Cloud Shellben:

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

Futtatás npm indítással

Az alkalmazás npm startelindításához csak győződjön meg arról, hogy egy start szkript szerepel a package.json fájlban. Példa:

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

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

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

Távoli hibakeresés

Ha a Node.js alkalmazást a PM2-vel való futtatásra konfigurálja, távolról is hibakeresést végezhet a Visual Studio Code-ban, 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élda:

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

A Visual Studio Code távoli hibakereséshez való beállításához telepítse az App Service-bővítményt. Kövesse a bővítményoldal utasításait, é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 parancsot. Válassza az Igen lehetőséget az alkalmazás távoli hibakeresésének engedélyezéséhez. Az 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 gombra kattintva. Amikor a rendszer kéri, válassza az Igen lehetőséget a távoli hibakeresés letiltásához. Ha később le szeretné tiltani, kattintson 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 az App Service buildautomatizálása akkor fut npm install --production , ha felismeri, hogy egy Node.js-alkalmazás a Giten keresztül van üzembe helyezve, vagy zip-alapú üzembe helyezéssel , engedélyezve a buildautomatizálást. Ha az alkalmazásnak szüksége van a népszerű automatizálási eszközökre, például a Gruntra, a Bowerre vagy a Gulpra, egy egyéni üzembehelyezési szkriptet kell megadnia a futtatásához.

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",
  ...
}

Helyi terminálablakból 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ökérkönyvtára két további fájllal rendelkezik: .deployment és deploy.sh.

Nyissa meg a deploy.sh , és keresse meg a Deployment szakaszt, amely így néz ki:

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

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

Tekintse meg a MEAN.js mintában látható példát, amelyben az üzembehelyezési szkript egyéni npm install parancsot is futtat.

Bower

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

Korty

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

Az App Service-ben a TLS/SSL-leállítás 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 Expressben megbízhatósági proxykat használhat. Példa:

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.

Feljegyzé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 és <resource-group-name> írja be <app-name> a webalkalmazásnak megfelelő neveket.

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űkombinációt.+

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

URL-átírások

Ha Node.js-alkalmazásokat helyez üzembe Azure-alkalmazás Linux-szolgáltatásban, előfordulhat, hogy az URL-átírásokat közvetlenül az alkalmazáson belül kell kezelnie. Ez különösen hasznos annak biztosításához, hogy bizonyos URL-minták a webkiszolgáló konfigurációinak használata nélkül a megfelelő végpontokra legyenek átirányítva. Az URL-átírások többféleképpen is elvégezhetők Node.js. Ilyen például az express-urlrewrite csomag.

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 Application Insights-ügynök csatolásához nyissa meg a webalkalmazást a portálon, válassza az Application Insights lehetőséget 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ő Application Insights-erőforrást, vagy hozzon létre egy újat. Végül válassza az Alkalmaz elemet az alján. A webalkalmazás PowerShell-lel történő rendszerezéséhez 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 tekintse meg 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 másképp viselkedik az App Service-ben, 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. Az App Service éles módban futtatja Node.js alkalmazásait, ezért gondoskodnia kell arról, hogy a projekt a várt módon működjön helyileg éles módban. Például:
    • A package.json függően előfordulhat, hogy különböző csomagok vannak telepítve éles üzemmódra (dependenciesvs. devDependencies).
    • Egyes webes keretrendszerek eltérően 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 az App Service-ben fejlesztési módban. Például az MEAN.js az alkalmazás beállításával futtatáskor fejlesztési módra állíthatja be az NODE_ENV alkalmazást.

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

Miután telepítette a Node.js kódot egy natív Windows-alkalmazásba az App Service-ben, 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 vagy a zip-alapú üzembe helyezés engedélyezésével helyezi üzembe, az üzembehelyezési motor automatikusan létrehoz egy web.config-ot az alkalmazás webes gyökerében (%HOME%\site\wwwroot), ha az alábbi feltételek egyike teljesül:

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

A létrehozott web.config az észlelt indítási szkriptre van szabva. Egyéb üzembehelyezési módszerek esetén manuálisan adja hozzá ezt a web.config fájlt . 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 build automatizálását. Alapértelmezés szerint nincs engedélyezve. az webapp up ZIP-üzembe helyezést használ, és engedélyezve van a buildautomatizálás.

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