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:
- Futtassa az egyéni szkriptet, ha az egyiket a
PRE_BUILD_SCRIPT_PATH
. - Futtassa
npm install
a jelölők nélkül, amely tartalmazza az npm-etpreinstall
éspostinstall
a szkripteket, és telepítidevDependencies
is. - Futtassa
npm run build
, ha egy buildszkript van megadva a package.json. - Futtassa
npm run build:azure
, ha egy build:azure-szkript van megadva a package.json. - 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:
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:prod
futtassa 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 start
elindí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 --production
vé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 (
dependencies
vs.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.
- A package.json függően előfordulhat, hogy különböző csomagok vannak telepítve éles üzemmódra (
- 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: