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:
- Futtassa az egyéni szkriptet, ha azt a adja
PRE_BUILD_SCRIPT_PATH
meg. - Futtassa a parancsot
npm install
jelzők nélkül, amely tartalmazza az npm-etpreinstall
éspostinstall
a szkripteket, valamint telepíti a parancsotdevDependencies
. - Futtassa a parancsot
npm run build
, ha a package.json fájlban meg van adva buildszkript. - Futtassa a parancsot
npm run build:azure
, ha a package.json fájlban meg van adva egy build:azure szkript. - Futtassa az egyéni szkriptet, ha azt a adja
POST_BUILD_SCRIPT_PATH
meg.
Megjegyzés
Az npm-dokumentumokban leírtak szerint a szkriptek neve prebuild
és postbuild
futtatása a előtt és után build
tö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:prod
futtassa 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 start
szeretné 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 --production
vé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
ésdevDependencies
). - 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.
- A package.json fájltól függően különböző csomagok telepíthetők éles üzemmódra (
- 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: