Sdílet prostřednictvím


Konfigurace aplikace v Node.js pro službu Azure App Service

Node.js aplikace musí být nasazeny se všemi požadovanými závislostmi npm. Nasazovací modul služby App Service se automaticky spustí npm install --production při nasazení úložiště Git nebo při nasazení balíčku Zip s povolenou automatizací sestavení. Pokud ale soubory nasadíte pomocí FTP/S, musíte požadované balíčky nahrát ručně.

Tato příručka obsahuje klíčové koncepty a pokyny pro vývojáře Node.js, kteří nasazují službu App Service. Pokud jste službu Aplikace Azure Nikdy nepoužívali, nejprve si projděte kurz rychlý start Node.js a Node.js s MongoDB.

Zobrazit verzi Node.js

Pokud chcete zobrazit aktuální Node.js verzi, spusťte v Cloud Shellu následující příkaz:

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

Pokud chcete zobrazit všechny podporované verze Node.js, přejděte nebo https://<sitename>.scm.azurewebsites.net/api/diagnostics/runtime spusťte v Cloud Shellu následující příkaz:

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

Pokud chcete zobrazit aktuální Node.js verzi, spusťte v Cloud Shellu následující příkaz:

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

Pokud chcete zobrazit všechny podporované verze Node.js, spusťte v Cloud Shellu následující příkaz:

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

Nastavení verze Node.js

Pokud chcete aplikaci nastavit na podporovanou Node.js verzi, spusťte v Cloud Shellu následující příkaz a nastavte WEBSITE_NODE_DEFAULT_VERSION ji na podporovanou verzi:

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

Poznámka:

Tento příklad používá doporučenou syntaxi vlnovek k cílení na nejnovější dostupnou verzi modulu runtime Node.js 16 ve službě App Service.

Vzhledem k tomu, že modul runtime je pravidelně opravován a aktualizován platformou, nedoporučujeme, abyste cílili na konkrétní podverzi nebo opravu, protože tyto opravy nejsou zaručené kvůli potenciálním bezpečnostním rizikům.

Poznámka:

V projektu package.jsonbyste měli nastavit verzi Node.js . Modul nasazení běží v samostatném procesu, který obsahuje všechny podporované verze Node.js.

Pokud chcete aplikaci nastavit na podporovanou Node.js verzi, spusťte v Cloud Shellu následující příkaz:

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

Toto nastavení určuje verzi Node.js, která se má použít, a to jak za běhu, tak během automatizovaného obnovení balíčku v Kudu.

Poznámka:

V projektu package.jsonbyste měli nastavit verzi Node.js . Modul nasazení běží v samostatném kontejneru, který obsahuje všechny podporované verze Node.js.

Získání čísla portu

Aplikace Node.js musí naslouchat správnému portu pro příjem příchozích požadavků.

Ve službě App Service ve Windows jsou aplikace Node.js hostované pomocí modulu IISNode a vaše Node.js aplikace by měla naslouchat portu zadanému process.env.PORT v proměnné. Následující příklad ukazuje, jak to udělat v jednoduché aplikaci Express:

App Service nastaví proměnnou PORT prostředí v kontejneru Node.js a předá příchozí požadavky do kontejneru na toto číslo portu. Pokud chcete přijímat požadavky, měla by vaše aplikace naslouchat požadavkům na tento port pomocí process.env.PORT. Následující příklad ukazuje, jak to udělat v jednoduché aplikaci Express:

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

Přizpůsobení automatizace sestavení

Pokud nasadíte aplikaci pomocí Gitu nebo pomocí balíčků ZIP s povolenou automatizací sestavení, bude automatizace sestavení služby App Service procházet následující posloupností:

  1. Spusťte vlastní skript, pokud ho určí PRE_BUILD_SCRIPT_PATH.
  2. Spusťte npm install bez příznaků, které zahrnují npm preinstall a postinstall skripty a také nainstaluje devDependencies.
  3. Spusťte npm run build , pokud je v package.json zadaný skript sestavení.
  4. Spusťte npm run build:azure , pokud je v package.json zadaný skript build:azure.
  5. Spuštění vlastního skriptu, pokud je zadán parametrem POST_BUILD_SCRIPT_PATH.

Poznámka:

Jak je uvedeno v dokumentaci npm, skripty pojmenované prebuild a postbuild spouštěné před a za build, v uvedeném pořadí, pokud jsou zadány. preinstall a postinstall spusťte před a za install, v uvedeném pořadí.

PRE_BUILD_COMMAND a POST_BUILD_COMMAND jsou proměnné prostředí, které jsou ve výchozím nastavení prázdné. Chcete-li spustit příkazy před sestavením, definujte PRE_BUILD_COMMAND. Chcete-li spustit příkazy po sestavení, definujte POST_BUILD_COMMAND.

Následující příklad používá dvě proměnné k určení řady příkazů oddělených čárkami.

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"

Informace o dalších proměnných prostředí pro přizpůsobení automatizace sestavení naleznete v tématu Konfigurace Oryx.

Další informace o tom, jak App Service spouští a vytváří aplikace Node.js v Linuxu, najdete v dokumentaci k Oryxu: Jak se aplikace Node.js detekují a sestavují.

Konfigurace Node.js serveru

Kontejnery Node.js mají manažera výrobních procesů PM2. Aplikaci můžete nakonfigurovat tak, aby začínala na PM2, pomocí příkazu npm start nebo pomocí vlastního příkazu.

Nástroj Účel
Spuštění s PM2 Doporučeno – použití v produkčním prostředí nebo přípravném prostředí. PM2 poskytuje plnohodnotnou platformu pro správu aplikací.
Spuštění s využitím npm startu Používejte pouze vývoj.
Spuštění s vlastním příkazem Vývoj nebo příprava.

Spuštění s PM2

Kontejner automaticky spustí aplikaci pm2, když se v projektu najde jeden z běžných Node.js souborů:

  • bin/www
  • server.js
  • app.js
  • index.js
  • hostingstart.js
  • Jeden z následujících souborů PM2: process.json nebo ecosystem.config.js

Můžete také nakonfigurovat vlastní spouštěcí soubor s následujícími příponami:

  • Soubor .js
  • A PM2 soubor s příponou .json, .config.js, .yaml nebo .yml

Poznámka:

Od Node 14 LTS se kontejner nespustí automaticky pomocí PM2. Pokud chcete aplikaci spustit pomocí pm2, nastavte spouštěcí příkaz na pm2 start <.js-file-or-PM2-file> --no-daemonhodnotu . Nezapomeňte použít argument, --no-daemon protože pm2 musí běžet v popředí, aby kontejner fungoval správně.

Pokud chcete přidat vlastní spouštěcí soubor, spusťte v Cloud Shellu následující příkaz:

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

Spuštění s vlastním příkazem

App Service může aplikaci spustit pomocí vlastního příkazu, například spustitelného souboru, jako je run.sh. Pokud chcete například spustit npm run start:prod, spusťte v Cloud Shellu následující příkaz:

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

Spuštění s využitím npm startu

Pokud chcete aplikaci spustit, npm startstačí se ujistit, že start je skript v souboru package.json . Příklad:

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

Pokud chcete ve svém projektu použít vlastní package.json, spusťte v Cloud Shellu následující příkaz:

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

Vzdálené ladění

Aplikaci Node.js můžete vzdáleně ladit v editoru Visual Studio Code , pokud ji nakonfigurujete tak, aby běžela s pm2, s výjimkou případů, kdy ji spouštíte pomocí .config.js, .yml nebo .yaml.

Ve většině případů se pro vaši aplikaci nevyžaduje žádná další konfigurace. Pokud je vaše aplikace spuštěná se souborem process.json (výchozí nebo vlastní), musí mít script vlastnost v kořenovém adresáři JSON. Příklad:

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

Pokud chcete nastavit Visual Studio Code pro vzdálené ladění, nainstalujte rozšíření App Service. Postupujte podle pokynů na stránce rozšíření a přihlaste se k Azure v editoru Visual Studio Code.

V Průzkumníku Azure vyhledejte aplikaci, kterou chcete ladit, klikněte na ni pravým tlačítkem a vyberte Spustit vzdálené ladění. Pokud chcete povolit vzdálené ladění pro vaši aplikaci, vyberte Ano . App Service spustí proxy tunelu za vás a připojí ladicí program. Potom můžete do aplikace vyhovět žádostem a zobrazit pozastavení ladicího programu v zarážkách.

Po dokončení ladění zastavte ladicí program výběrem možnosti Odpojit. Po zobrazení výzvy byste měli vybrat ano, pokud chcete zakázat vzdálené ladění. Pokud ho chcete později zakázat, klikněte znovu pravým tlačítkem na aplikaci v Průzkumníku Azure a vyberte Zakázat vzdálené ladění.

Přístup k proměnným prostředí

V App Service můžete nastavit nastavení aplikace mimo kód vaší aplikace. Pak k nim můžete přistupovat pomocí standardního vzoru Node.js. Například pro přístup k aplikačnímu nastavení s názvem NODE_ENV použijete následující kód:

process.env.NODE_ENV

Spuštění Gruntu, Boweru nebo Gulpu

Ve výchozím nastavení se automatizace sestavení služby App Service spustí npm install --production , když rozpozná, že je aplikace Node.js nasazená prostřednictvím Gitu nebo prostřednictvím nasazení zip s povolenou automatizací sestavení. Pokud vaše aplikace vyžaduje některý z oblíbených automatizačních nástrojů, jako je Grunt, Bower nebo Gulp, musíte k jeho spuštění zadat vlastní skript nasazení.

Pokud chcete úložišti povolit spouštění těchto nástrojů, musíte je přidat do závislostí v package.json. Například:

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

V okně místního terminálu změňte adresář na kořenový adresář úložiště a spusťte následující příkazy:

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

Kořenový adresář úložiště teď obsahuje dva další soubory: .deployment a deploy.sh.

Otevřete deploy.sh a najděte Deployment oddíl, který vypadá takto:

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

Tento oddíl končí spuštěním npm install --production. Přidejte oddíl kódu, který potřebujete ke spuštění požadovaného nástroje na konci oddílu Deployment :

Podívejte se na příklad v ukázce MEAN.js, kde skript nasazení také spouští vlastní npm install příkaz.

Bower

Tento fragment kódu se spustí 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

Tento fragment kódu se spustí 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

Tento fragment kódu se spustí grunt.

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

Zjištění relace HTTPS

Ve službě App Service dochází k ukončení protokolu TLS/SSL v nástrojích pro vyrovnávání zatížení sítě, takže všechny požadavky HTTPS dosáhnou vaší aplikace jako nešifrované požadavky HTTP. Pokud logika vaší aplikace potřebuje zkontrolovat, jestli jsou požadavky uživatelů zašifrované, zkontrolujte hlavičku X-Forwarded-Proto .

Oblíbené webové architektury umožňují přístup k X-Forwarded-* informacím ve standardním vzoru aplikace. V Expressu můžete použít důvěryhodné proxy servery. Příklad:

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

Přístup k diagnostickým protokolům

Pokud chcete získat přístup k protokolům konzoly vygenerovaným v rámci kódu aplikace ve službě App Service, zapněte protokolování diagnostiky spuštěním následujícího příkazu v Cloud Shellu:

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

Možné hodnoty pro --level jsou: Error, Warning, Info a Verbose. Každá další úroveň zahrnuje předchozí úroveň. Například Error zahrnuje jenom chybové zprávy a Verbose zahrnuje všechny zprávy.

Jakmile je aktivované protokolování diagnostiky, spusťte následující příkaz pro zobrazení streamu protokolů:

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

Pokud nevidíte protokoly konzoly okamžitě, podívejte se znovu za 30 sekund.

Poznámka:

Soubory protokolu můžete také zkontrolovat v prohlížeči na https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Streamování protokolů můžete kdykoli zastavit zadáním Ctrl+C.

Přístup k protokolům konzoly vygenerovaným z kontejneru.

Nejprve zapněte protokolování kontejneru spuštěním následujícího příkazu:

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

Nahraďte <app-name> názvy vhodné pro vaši webovou aplikaci a <resource-group-name> nahraďte je názvy.

Jakmile je protokolování kontejneru zapnuté, spuštěním následujícího příkazu zobrazte stream protokolu:

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

Pokud nevidíte protokoly konzoly okamžitě, podívejte se znovu za 30 sekund.

Pokud chcete streamování protokolů kdykoli zastavit, zadejte Ctrl+C.

Soubory protokolu můžete také zkontrolovat v prohlížeči na adrese https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Přepsání adresy URL

Při nasazování Node.js aplikací ve službě Aplikace Azure Service pro Linux možná budete muset zpracovávat přepisy adres URL přímo v aplikaci. To je užitečné zejména pro zajištění přesměrování konkrétních vzorů adres URL na správné koncové body bez nutnosti spoléhat se na konfigurace webového serveru. Existuje několik způsobů, jak v Node.js přepsat adresy URL. Jedním z příkladů je balíček express-urlrewrite .

Monitorování pomocí Application Insights

Application Insights umožňuje monitorovat výkon, výjimky a použití vaší aplikace, aniž byste museli provádět změny kódu. Pokud chcete připojit agenta Application Insights, přejděte na portálu ke své webové aplikaci, vyberte Application Insights v části Nastavení a pak vyberte Zapnout Application Insights. Dále vyberte existující prostředek Application Insights nebo vytvořte nový. Nakonec vyberte Použít v dolní části. Pokud chcete instrumentovat webovou aplikaci pomocí PowerShellu, přečtěte si tyto pokyny.

Tento agent bude monitorovat Node.js aplikaci na straně serveru. Pokud chcete monitorovat JavaScript na straně klienta, přidejte do projektu sadu JavaScript SDK.

Další informace najdete v poznámkách k verzi rozšíření Application Insights.

Řešení problému

Když se pracovní Node.js aplikace chová jinak ve službě App Service nebo obsahuje chyby, zkuste následující:

  • Přístup ke streamu protokolu
  • Otestujte aplikaci místně v produkčním režimu. App Service spouští vaše Node.js aplikace v produkčním režimu, takže musíte zajistit, aby váš projekt fungoval očekávaným způsobem v produkčním režimu místně. Příklad:
    • V závislosti na vašem package.json se můžou nainstalovat různé balíčky pro produkční režim (dependencies vs. devDependencies).
    • Některé webové architektury můžou v produkčním režimu nasazovat statické soubory jinak.
    • Některé webové architektury můžou při spuštění v produkčním režimu používat vlastní spouštěcí skripty.
  • Spusťte aplikaci ve službě App Service v režimu vývoje. Například v MEAN.js můžete aplikaci nastavit na vývojový režim za běhu nastavením NODE_ENV nastavení aplikace.

Nemáte oprávnění k zobrazení tohoto adresáře nebo stránky.

Po nasazení kódu Node.js do nativní aplikace pro Windows ve službě App Service se může při přechodu na adresu URL vaší aplikace zobrazit zpráva You do not have permission to view this directory or page v prohlížeči. To je nejpravděpodobnější, protože nemáte soubor web.config . (Viz šablona a příklad.)

Pokud nasadíte soubory pomocí Gitu nebo pomocí nasazení ZIP s povolenou automatizací sestavení, modul nasazení vygeneruje web.config ve webovém kořenovém adresáři vaší aplikace (%HOME%\site\wwwroot) automaticky, pokud platí jedna z následujících podmínek:

  • Kořenový adresář projektu má package.json , který definuje start skript, který obsahuje cestu k souboru JavaScriptu.
  • Kořen projektu má server.js nebo app.js.

Vygenerovaný web.config je přizpůsobený zjištěnému spouštěcímu skriptu. Pro jiné metody nasazení přidejte tento web.config ručně. Ujistěte se, že je soubor správně naformátovaný.

Pokud používáte nasazení ZIP (například prostřednictvím editoru Visual Studio Code), nezapomeňte povolit automatizaci sestavení. Ve výchozím nastavení není povolená. az webapp up používá nasazení ZIP s povolenou automatizací sestavení.

robots933456 v protokolech

V protokolech kontejneru se může zobrazit následující zpráva:

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

Tuto zprávu klidně ignorujte. /robots933456.txt je fiktivní cesta URL, kterou App Service používá ke kontrole, jestli kontejner dokáže obsloužit požadavky. Odpověď 404 jednoduše indikuje, že příslušná cesta neexistuje, ale dá službě App Service vědět, že kontejner je v pořádku a je připravený reagovat na požadavky.

Další kroky

Nebo se podívejte na další zdroje informací:

Referenční informace k proměnným prostředí a nastavením aplikace