Konfigurowanie aplikacji Node.js dla usługi Azure App Service
Node.js aplikacje muszą być wdrażane ze wszystkimi wymaganymi zależnościami NPM. Aparat wdrażania App Service jest automatycznie uruchamiany npm install --production
podczas wdrażania repozytorium Git lub pakietu zipz włączoną automatyzacją kompilacji. Jeśli jednak wdrażasz pliki przy użyciu protokołu FTP/S, musisz ręcznie przekazać wymagane pakiety.
Ten przewodnik zawiera kluczowe pojęcia i instrukcje dla deweloperów Node.js, którzy wdrażają je w App Service. Jeśli nigdy nie używasz Azure App Service, najpierw postępuj zgodnie z przewodnikiem Szybki startNode.js i Node.js z samouczkiem bazy danych MongoDB.
Pokaż wersję Node.js
Aby wyświetlić bieżącą wersję Node.js, uruchom następujące polecenie w Cloud Shell:
az webapp config appsettings list --name <app-name> --resource-group <resource-group-name> --query "[?name=='WEBSITE_NODE_DEFAULT_VERSION'].value"
Aby wyświetlić wszystkie obsługiwane wersje Node.js, przejdź do https://<sitename>.scm.azurewebsites.net/api/diagnostics/runtime
lub uruchom następujące polecenie w Cloud Shell:
az webapp list-runtimes --os windows | grep NODE
Aby wyświetlić bieżącą wersję Node.js, uruchom następujące polecenie w Cloud Shell:
az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion
Aby wyświetlić wszystkie obsługiwane wersje Node.js, uruchom następujące polecenie w Cloud Shell:
az webapp list-runtimes --os linux | grep NODE
Ustawianie wersji Node.js
Aby ustawić aplikację na obsługiwaną wersję Node.js, uruchom następujące polecenie w Cloud Shell, aby ustawić WEBSITE_NODE_DEFAULT_VERSION
obsługiwaną wersję:
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings WEBSITE_NODE_DEFAULT_VERSION="~16"
Uwaga
W tym przykładzie użyto zalecanej "składni tyldy", aby kierować do najnowszej dostępnej wersji środowiska uruchomieniowego Node.js 16 w App Service.
Ponieważ środowisko uruchomieniowe jest regularnie poprawiane i aktualizowane przez platformę, nie zaleca się określania określonej wersji pomocniczej/poprawki, ponieważ nie są one gwarantowane ze względu na potencjalne zagrożenia bezpieczeństwa.
Uwaga
Należy ustawić wersję Node.js w projekcie package.json
. Aparat wdrażania działa w osobnym procesie, który zawiera wszystkie obsługiwane wersje Node.js.
Aby ustawić aplikację na obsługiwaną wersję Node.js, uruchom następujące polecenie w Cloud Shell:
az webapp config set --resource-group <resource-group-name> --name <app-name> --linux-fx-version "NODE|14-lts"
To ustawienie określa Node.js wersję do użycia, zarówno w czasie wykonywania, jak i podczas automatycznego przywracania pakietu w kudu.
Uwaga
Należy ustawić wersję Node.js w projekcie package.json
. Aparat wdrażania działa w oddzielnym kontenerze zawierającym wszystkie obsługiwane wersje Node.js.
Pobieranie numeru portu
Aplikacja Node.js musi nasłuchiwać właściwego portu w celu odbierania żądań przychodzących.
W App Service w systemie Windows aplikacje Node.js są hostowane za pomocą programu IISNode, a aplikacja Node.js powinna nasłuchiwać portu określonego w zmiennejprocess.env.PORT
. W poniższym przykładzie pokazano, jak to zrobić w prostej aplikacji Express:
App Service ustawia zmienną środowiskową PORT
w kontenerze Node.js i przekazuje żądania przychodzące do kontenera pod tym numerem portu. Aby odbierać żądania, aplikacja powinna nasłuchiwać tego portu przy użyciu polecenia process.env.PORT
. W poniższym przykładzie pokazano, jak to zrobić w prostej aplikacji 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}`)
})
Dostosowywanie automatyzacji kompilacji
Jeśli aplikacja jest wdrażana przy użyciu narzędzia Git lub pakietów zip z włączoną automatyzacją kompilacji, App Service kroki automatyzacji kompilacji w ramach następującej sekwencji:
- Uruchom skrypt niestandardowy, jeśli został określony przez
PRE_BUILD_SCRIPT_PATH
polecenie . - Uruchom polecenie
npm install
bez żadnych flag, które obejmują narzędzie npmpreinstall
ipostinstall
skrypty, a także instaluje programdevDependencies
. - Uruchom polecenie
npm run build
, jeśli w pliku package.json określono skrypt kompilacji. - Uruchom polecenie
npm run build:azure
, jeśli w pliku package.json określono skrypt build:azure. - Uruchom skrypt niestandardowy, jeśli został określony przez
POST_BUILD_SCRIPT_PATH
polecenie .
Uwaga
Zgodnie z opisem w dokumentacji npm skrypty o nazwie prebuild
i postbuild
są uruchamiane odpowiednio przed i po build
, jeśli określono. preinstall
i postinstall
uruchomić odpowiednio przed i po install
, .
PRE_BUILD_COMMAND
i POST_BUILD_COMMAND
są zmiennymi środowiskowymi, które są domyślnie puste. Aby uruchomić polecenia przed kompilacją, zdefiniuj polecenie PRE_BUILD_COMMAND
. Aby uruchomić polecenia po kompilacji, zdefiniuj element POST_BUILD_COMMAND
.
Poniższy przykład określa dwie zmienne serii poleceń rozdzielonych przecinkami.
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"
Aby uzyskać dodatkowe zmienne środowiskowe w celu dostosowania automatyzacji kompilacji, zobacz Konfiguracja Oryx.
Aby uzyskać więcej informacji na temat App Service sposobu uruchamiania i kompilowanie Node.js aplikacji w systemie Linux, zobacz dokumentację oryx: Jak wykrywać i kompilować aplikacje Node.js.
Konfigurowanie serwera Node.js
Kontenery Node.js mają pm2, menedżera procesów produkcyjnych. Aplikację można skonfigurować tak, aby rozpoczynała się od PM2 lub NPM albo za pomocą polecenia niestandardowego.
Narzędzie | Przeznaczenie |
---|---|
Uruchamianie z pm2 | Zalecane — użycie produkcyjne lub przejściowe. PM2 zapewnia platformę zarządzania aplikacjami w pełnej usłudze. |
Uruchamianie polecenia npm start | Tylko użycie programistyczne. |
Uruchamianie polecenia niestandardowego | Programowanie lub przemieszczanie. |
Uruchamianie z pm2
Kontener automatycznie uruchamia aplikację z pm2, gdy jeden z typowych plików Node.js znajduje się w projekcie:
- bin/www
- server.js
- app.js
- index.js
- hostingstart.js
- Jeden z następujących plików PM2: process.json i ecosystem.config.js
Można również skonfigurować niestandardowy plik początkowy z następującymi rozszerzeniami:
- Plik .js
- Plik PM2 z rozszerzeniem .json, .config.js, .yaml lub .yml
Uwaga
Począwszy od środowiska Node 14 LTS, kontener nie uruchamia automatycznie aplikacji z pm2. Aby uruchomić aplikację z pm2, ustaw polecenie uruchamiania na pm2 start <.js-file-or-PM2-file> --no-daemon
. Pamiętaj, aby użyć argumentu --no-daemon
, ponieważ pm2 musi działać na pierwszym planie, aby kontener działał prawidłowo.
Aby dodać niestandardowy plik startowy, uruchom następujące polecenie w Cloud Shell:
az webapp config set --resource-group <resource-group-name> --name <app-name> --startup-file "<filename-with-extension>"
Uruchamianie polecenia niestandardowego
App Service można uruchomić aplikację przy użyciu polecenia niestandardowego, takiego jak plik wykonywalny, taki jak run.sh. Aby na przykład uruchomić polecenie npm run start:prod
, uruchom następujące polecenie w Cloud Shell:
az webapp config set --resource-group <resource-group-name> --name <app-name> --startup-file "npm run start:prod"
Uruchamianie polecenia npm start
Aby uruchomić aplikację przy użyciu polecenia npm start
, upewnij się, że start
skrypt znajduje się w pliku package.json . Przykład:
{
...
"scripts": {
"start": "gulp",
...
},
...
}
Aby użyć pliku package.json niestandardowego w projekcie, uruchom następujące polecenie w Cloud Shell:
az webapp config set --resource-group <resource-group-name> --name <app-name> --startup-file "<filename>.json"
Debugowanie zdalne
Uwaga
Debugowanie zdalne jest obecnie dostępne w wersji zapoznawczej.
Aplikację Node.js można debugować zdalnie w Visual Studio Code, jeśli skonfigurujesz ją do uruchamiania przy użyciu pm2, z wyjątkiem sytuacji, w której jest uruchamiana przy użyciu pliku .config.js,.yml lub yaml.
W większości przypadków nie jest wymagana żadna dodatkowa konfiguracja aplikacji. Jeśli aplikacja jest uruchamiana z plikiem process.json (domyślnym lub niestandardowym script
), musi mieć właściwość w katalogu głównym JSON. Przykład:
{
"name" : "worker",
"script" : "./index.js",
...
}
Aby skonfigurować Visual Studio Code na potrzeby zdalnego debugowania, zainstaluj rozszerzenie App Service. Postępuj zgodnie z instrukcjami na stronie rozszerzenia i zaloguj się do platformy Azure w Visual Studio Code.
W eksploratorze platformy Azure znajdź aplikację, którą chcesz debugować, kliknij ją prawym przyciskiem myszy i wybierz polecenie Uruchom debugowanie zdalne. Kliknij przycisk Tak , aby włączyć ją dla aplikacji. App Service uruchamia dla Ciebie serwer proxy tunelu i dołącza debuger. Następnie możesz wysyłać żądania do aplikacji i zobaczyć, jak debuger wstrzymuje się w punktach przerwania.
Po zakończeniu debugowania zatrzymaj debuger, wybierając pozycję Rozłącz. Po wyświetleniu monitu kliknij przycisk Tak , aby wyłączyć debugowanie zdalne. Aby wyłączyć ją później, ponownie kliknij aplikację prawym przyciskiem myszy w eksploratorze platformy Azure i wybierz polecenie Wyłącz debugowanie zdalne.
Uzyskiwanie dostępu do zmiennych środowiskowych
W usłudze App Service można określić ustawienia aplikacji poza kodem aplikacji. Następnie możesz uzyskać do nich dostęp przy użyciu standardowego wzorca Node.js. Aby na przykład uzyskać dostęp do ustawienia aplikacji o nazwie NODE_ENV
, użyj następującego kodu:
process.env.NODE_ENV
Run Grunt/Bower/Gulp
Domyślnie App Service automatyzacja kompilacji jest uruchamiananpm install --production
, gdy rozpoznaje aplikację Node.js jest wdrażana za pośrednictwem usługi Git lub za pośrednictwem wdrożenia zip z włączoną automatyzacją kompilacji. Jeśli aplikacja wymaga dowolnego z popularnych narzędzi automatyzacji, takich jak Grunt, Bower lub Gulp, musisz podać niestandardowy skrypt wdrożenia , aby go uruchomić.
Aby umożliwić repozytorium uruchamianie tych narzędzi, należy dodać je do zależności w pliku package.json. Na przykład:
"dependencies": {
"bower": "^1.7.9",
"grunt": "^1.0.1",
"gulp": "^3.9.1",
...
}
W lokalnym oknie terminalu zmień katalog na katalog główny repozytorium i uruchom następujące polecenia:
npm install kuduscript -g
kuduscript --node --scriptType bash --suppressPrompt
Katalog główny repozytorium ma teraz dwa dodatkowe pliki: .deployment i deploy.sh.
Otwórz deploy.sh i znajdź sekcję Deployment
, która wygląda następująco:
##################################################################################################################################
# Deployment
# ----------
Ta sekcja kończy się uruchomieniem polecenia npm install --production
. Dodaj sekcję kodu, którą należy uruchomić wymagane narzędzie na końcuDeployment
sekcji:
Zobacz przykład w przykładzie MEAN.js, w którym skrypt wdrażania uruchamia również polecenie niestandardowe npm install
.
Bower
Ten fragment kodu uruchamia polecenie 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
Ten fragment kodu uruchamia polecenie 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
Ten fragment kodu uruchamia polecenie grunt
.
if [ -e "$DEPLOYMENT_TARGET/Gruntfile.js" ]; then
cd "$DEPLOYMENT_TARGET"
eval ./node_modules/.bin/grunt
exitWithMessageOnError "Grunt failed"
cd - > /dev/null
fi
Wykrywanie sesji protokołu HTTPS
W App Service zakończenie protokołu TLS/SSL odbywa się w modułach równoważenia obciążenia sieciowego, więc wszystkie żądania HTTPS docierają do aplikacji jako niezaszyfrowane żądania HTTP. Jeśli logika aplikacji musi sprawdzać, czy żądania użytkownika są szyfrowane, czy nie, zbadaj nagłówek X-Forwarded-Proto
.
Popularne platformy internetowe umożliwiają dostęp do informacji X-Forwarded-*
w standardowym wzorcu aplikacji. W programie Express można używać serwerów proxy zaufania. Na przykład:
app.set('trust proxy', 1)
...
if (req.secure) {
// Do something when HTTPS is used
}
Uzyskiwanie dostępu do dzienników diagnostycznych
Aby uzyskać dostęp do dzienników konsoli wygenerowanych wewnątrz kodu aplikacji w usłudze App Service, włącz rejestrowanie diagnostyczne, uruchamiając następujące polecenie w usłudze Cloud Shell:
az webapp log config --resource-group <resource-group-name> --name <app-name> --docker-container-logging filesystem --level Verbose
Możliwe wartości parametru --level
to: Error
, Warning
, Info
i Verbose
. Każdy kolejny poziom obejmuje poprzedni poziom. Na przykład poziom Error
obejmuje tylko komunikaty o błędach, a poziom Verbose
obejmuje wszystkie komunikaty.
Po włączeniu rejestrowania diagnostycznego uruchom następujące polecenie, aby wyświetlić strumień dziennika:
az webapp log tail --resource-group <resource-group-name> --name <app-name>
Jeśli nie widzisz dzienników konsoli, sprawdź ponownie w ciągu 30 sekund.
Uwaga
Pliki dzienników można także sprawdzać w przeglądarce pod adresem https://<app-name>.scm.azurewebsites.net/api/logs/docker
.
Aby w dowolnym momencie zatrzymać przesyłanie strumieniowe dzienników, naciśnij kombinację klawiszy Ctrl
+C
.
Dostęp do dzienników konsoli wygenerowanych z poziomu kontenera.
Najpierw włącz rejestrowanie kontenerów, uruchamiając następujące polecenie:
az webapp log config --name <app-name> --resource-group <resource-group-name> --docker-container-logging filesystem
Zastąp <app-name>
wartości i <resource-group-name>
nazwami odpowiednimi dla aplikacji internetowej.
Po włączeniu rejestrowania kontenerów uruchom następujące polecenie, aby wyświetlić strumień dziennika:
az webapp log tail --name <app-name> --resource-group <resource-group-name>
Jeśli nie widzisz dzienników konsoli, sprawdź ponownie w ciągu 30 sekund.
Aby zatrzymać przesyłanie strumieniowe dzienników w dowolnym momencie, naciśnij klawisze Ctrl+C.
Możesz również sprawdzić pliki dziennika w przeglądarce pod adresem https://<app-name>.scm.azurewebsites.net/api/logs/docker
.
Monitorowanie za pomocą usługi Application Insights
Usługa Application Insights umożliwia monitorowanie wydajności, wyjątków i użycia aplikacji bez wprowadzania jakichkolwiek zmian w kodzie. Aby dołączyć agenta usługi App Insights, przejdź do aplikacji internetowej w portalu i wybierz pozycję Application Insights w obszarze Ustawienia, a następnie wybierz pozycję Włącz usługę Application Insights. Następnie wybierz istniejący zasób usługi App Insights lub utwórz nowy. Na koniec wybierz pozycję Zastosuj u dołu. Aby instrumentować aplikację internetową przy użyciu programu PowerShell, zapoznaj się z tymi instrukcjami
Ten agent będzie monitorować aplikację Node.js po stronie serwera. Aby monitorować kod JavaScript po stronie klienta, dodaj zestaw JAVAScript SDK do projektu.
Aby uzyskać więcej informacji, zobacz informacje o wersji rozszerzenia Usługi Application Insights.
Rozwiązywanie problemów
Gdy działająca aplikacja Node.js zachowuje się inaczej w App Service lub ma błędy, spróbuj wykonać następujące czynności:
- Uzyskiwanie dostępu do strumienia dziennika.
- Przetestuj aplikację lokalnie w trybie produkcyjnym. App Service uruchamia aplikacje Node.js w trybie produkcyjnym, dlatego należy upewnić się, że projekt działa zgodnie z oczekiwaniami w trybie produkcyjnym lokalnie. Przykład:
- W zależności od pliku package.json dla trybu produkcyjnego mogą być instalowane różne pakiety (
dependencies
adevDependencies
). - Niektóre struktury internetowe mogą wdrażać pliki statyczne inaczej w trybie produkcyjnym.
- Niektóre struktury internetowe mogą używać niestandardowych skryptów uruchamiania podczas uruchamiania w trybie produkcyjnym.
- W zależności od pliku package.json dla trybu produkcyjnego mogą być instalowane różne pakiety (
- Uruchom aplikację w App Service w trybie programowania. Na przykład w MEAN.jsmożna ustawić tryb programowania aplikacji w środowisku uruchomieniowym, ustawiając
NODE_ENV
ustawienie aplikacji.
Nie masz uprawnień do wyświetlania tego katalogu lub strony
Po wdrożeniu kodu Node.js w natywnej aplikacji systemu Windows w App Service może zostać wyświetlony komunikat You do not have permission to view this directory or page.
w przeglądarce podczas przechodzenia do adresu URL aplikacji. Najprawdopodobniej nie masz plikuweb.config (zobacz szablon i przykład).
Jeśli pliki są wdrażane przy użyciu usługi Git lub przy użyciu wdrożenia ZIP z włączoną automatyzacją kompilacji, aparat wdrażania generuje web.config w katalogu głównym aplikacji internetowej (%HOME%\site\wwwroot
), jeśli spełniony jest jeden z następujących warunków:
- Katalog główny projektu ma plik package.json , który definiuje
start
skrypt zawierający ścieżkę pliku JavaScript. - Katalog główny projektu ma server.js lub app.js.
Wygenerowany web.config jest dostosowany do wykrytego skryptu uruchamiania. W przypadku innych metod wdrażania dodaj tę web.config ręcznie. Upewnij się, że plik jest poprawnie sformatowany.
Jeśli używasz wdrożenia ZIP (na przykład za pośrednictwem Visual Studio Code), pamiętaj, aby włączyć automatyzację kompilacji, ponieważ nie jest ona domyślnie włączona. az webapp up
używa wdrożenia ZIP z włączoną automatyzacją kompilacji.
robots933456 w dziennikach
W dziennikach kontenera może zostać wyświetlony następujący komunikat:
2019-04-08T14:07:56.641002476Z "-" - - [08/Apr/2019:14:07:56 +0000] "GET /robots933456.txt HTTP/1.1" 404 415 "-" "-"
Możesz bezpiecznie zignorować ten komunikat. /robots933456.txt
jest fikcyjną ścieżką adresu URL, za pomocą której usługa App Service sprawdza, czy kontener jest w stanie obsługiwać żądania. Odpowiedź 404 oznacza po prostu, że ścieżka nie istnieje, ale pozwala usłudze App Service sprawdzić, czy kontener jest w dobrej kondycji i jest gotowy do reagowania na żądania.
Następne kroki
Możesz też zapoznać się z dodatkowymi zasobami:
Opinia
https://aka.ms/ContentUserFeedback.
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź:Prześlij i wyświetl opinię dla