Настройка приложения Node.js для Службы приложений Azure

Node.js приложения должны быть развернуты со всеми необходимыми зависимостями npm. Подсистема развертывания службы приложений автоматически запускается npm install --production при развертывании репозитория Git или при развертывании пакета ZIP с включенной автоматизацией сборки. Однако при развертывании файлов с помощью FTP/S необходимо вручную отправить необходимые пакеты.

В этой статье описываются основные понятия и приведены инструкции для разработчиков Node.js, которые развертываются в Службе приложений. Если вы никогда не использовали службу приложений Azure, выполните краткое руководство поNode.js и руководство по Node.js с помощью MongoDB .

Отображение версии Node.js

Чтобы просмотреть сведения о текущей версии Node.js, выполните следующую команду в Cloud Shell:

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

Чтобы отобразились сведения обо всех поддерживаемых версиях Node.js, выполните следующую команду в Cloud Shell:

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

Чтобы просмотреть сведения о текущей версии Node.js, выполните следующую команду в Cloud Shell:

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

Чтобы отобразились сведения обо всех поддерживаемых версиях Node.js, выполните следующую команду в Cloud Shell:

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

Настройка версии Node.js

Чтобы настроить для приложения поддерживаемую версию Node.js, выполните приведенную ниже команду в Cloud Shell. С ее помощью для WEBSITE_NODE_DEFAULT_VERSION устанавливается поддерживаемая версия.

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

Примечание.

В этом примере используется рекомендуемый синтаксис тильды для назначения последней доступной версии среды выполнения Node.js 16 в службе приложений.

Так как среда выполнения регулярно обновляется и обновляется платформой, мы не рекомендуем использовать конкретную дополнительную версию или исправление. Из-за потенциальных рисков безопасности эти версии не гарантированы.

Примечание.

Необходимо задать версию Node.js в package.json проекта. Подсистема развертывания выполняется в отдельном процессе, который содержит все поддерживаемые версии Node.js.

Чтобы настроить для приложения поддерживаемую версию Node.js, выполните следующую команду в Cloud Shell:

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

Этот параметр указывает версию Node.js для использования как во время выполнения, так и во время автоматического восстановления пакета в Kudu.

Примечание.

Необходимо задать версию Node.js в package.json проекта. Подсистема развертывания выполняется в отдельном контейнере, который содержит все поддерживаемые версии Node.js.

Что происходит с устаревшими средами выполнения в сервисе приложений?

Устаревшие среды выполнения не рекомендуется поддерживать организацию или имеют значительные уязвимости. Соответственно, они удаляются из страниц создания и настройки на портале. Если устаревшая среда выполнения скрыта на портале, любое приложение, которое по-прежнему используется этой средой выполнения, продолжает выполняться.

Если вы хотите создать приложение с устаревшей версией среды выполнения, которая больше не отображается на портале, используйте Azure CLI, шаблон ARM или Bicep. Эти варианты развертывания позволяют создавать устаревшие среды выполнения, удаленные с портала, но по-прежнему поддерживаются.

Если среда выполнения полностью удалена из платформы службы приложений, владелец подписки Azure получает уведомление по электронной почте перед удалением.

Установка номера порта

Приложение Node.js должно прослушивать правильный порт для получения входящих запросов.

В Службе приложений Windows приложения Node.js размещаются с помощью IISNode, и ваше приложение Node.js должно слушать порт, указанный в переменной process.env.PORT. В следующем примере показано, как задать порт в простом приложении Express:

Служба приложений задает переменную PORT среды в контейнере Node.js и пересылает входящие запросы в контейнер по указанному номеру порта. Чтобы получить запросы, приложение должно прослушивать порт, указанный в переменной process.env.PORT . В следующем примере показано, как задать порт в простом приложении 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}`)
})

Настройка автоматизации сборки

Если вы развертываете приложение с помощью Git или с помощью zip-пакетов с включенной автоматизацией сборки, автоматизация сборки Службы приложений выполняет следующие действия.

Запустите пользовательский скрипт, если он указан PRE_BUILD_SCRIPT_PATH.
Запустите без npm install флагов. Этот шаг включает npm preinstall и скриптыpostinstall, devDependencies а также устанавливает.
Запустите, npm run build если скрипт сборки указан в файле package.json .
Запустите, npm run build:azure если build:azure скрипт указан в файле package.json .
Запустите пользовательский скрипт, если он указан POST_BUILD_SCRIPT_PATH.

Примечание.

Как отмечается в документации npm, скрипты с именем prebuild и postbuild запускаются до и после build соответственно, если они заданы. Скрипты с именем preinstall и postinstall запуском до и после installэтого соответственно.

PRE_BUILD_COMMAND и POST_BUILD_COMMAND являются переменными среды, которые по умолчанию пустые. Чтобы выполнить команды перед сборкой, определите PRE_BUILD_COMMAND. Чтобы выполнить команды после сборки, определите POST_BUILD_COMMAND.

В следующем примере используются две переменные для указания ряда команд, разделенных запятыми.

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"

Сведения о дополнительных переменных среды для настройки автоматизации сборки см. в разделе "Конфигурация Oryx".

Дополнительные сведения о том, как Служба приложений выполняет и создает приложения Node.js в Linux, см. в статье документации по Oryx "Обнаружение и создание приложений Node.js".

Настройка сервера Node.js

Контейнеры Node.js поставляются с PM2, диспетчером рабочих процессов. Приложение можно настроить для начала с PM2, с npm startпомощью пользовательской команды или с помощью пользовательской команды.

Инструмент	Цель
Запуск с помощью PM2	Рекомендуется. Использование рабочей или промежуточной среды. PM2 предоставляет платформу для управления рабочими приложениями.
Запуск с помощью npm start	Только для разработки.
Запуск с помощью настраиваемой команды	Либо разработка, либо промежуточная среда.

Запуск с помощью PM2

Контейнер автоматически запускает приложение с помощью PM2, когда в проекте обнаруживается один из распространенных файлов Node.js:

bin/www;
server.js
app.js
index.js
hostingstart.js;
Один из следующих файлов PM2: process.json или ecosystem.config.js

Кроме того, вы можете настроить пользовательский файл запуска со следующими расширениями:

файл .js;
Файл PM2 с расширением .json, .config.js, YAML или .yml

Примечание.

Начиная с узла 14 LTS контейнер не запускает приложение с PM2. Чтобы запустить приложение с помощью PM2, задайте для команды startup значение pm2 start <.js-file-or-PM2-file> --no-daemon. Используйте аргумент --no-daemon, так как служба PM2 должна выполняться на переднем плане для правильной работы контейнера.

Чтобы добавить пользовательский файл запуска, выполните следующую команду в Cloud Shell:

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

Запуск с помощью настраиваемой команды

Служба приложений может запустить приложение с помощью пользовательской команды, например исполняемого файла, например run.sh. Например, чтобы запустить npm run start:prod, выполните следующую команду в Cloud Shell:

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

Запустите с помощью команды npm start

Чтобы запустить приложение npm start, просто убедитесь start , что скрипт находится в файлеpackage.json . Например:

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

Чтобы использовать в проекте настраиваемый файл package.js, выполните следующую команду в Cloud Shell:

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

Удаленная отладка

Вы можете удаленно отлаживать приложение Node.js в Visual Studio Code , если вы настроите его для работы с PM2, за исключением случаев, когда вы запускаете его с помощью .config.js, .yml или YAML-файла .

В большинстве случаев для приложения дополнительная настройка не требуется. Если приложение запускается с файлом process.json (по умолчанию или настраиваемым), оно должно иметь свойство script в корне JSON. Например:

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

Чтобы настроить Visual Studio Code для удаленной отладки, установите расширение Службы приложений. Следуйте инструкциям на странице расширения и войдите в Azure в Visual Studio Code.

В обозревателе Azure найдите приложение, которое вы хотите отлаживать, щелкните его правой кнопкой мыши и выберите "Запустить удаленную отладку". Выберите "Да", чтобы включить удаленную отладку для приложения. Служба приложений запускает прокси-сервер туннеля и подключает отладчик. Затем можно выполнить запросы к приложению и увидеть, что отладчик приостанавливается в точках останова.

После завершения отладки остановите отладчик, нажав кнопку "Отключить". При появлении запроса необходимо выбрать "Да" , чтобы отключить удаленную отладку. Чтобы отключить ее позже, снова щелкните свое приложение в Azure Explorer и выберите команду Disable Remote Debugging (Отключить удаленную отладку).

Доступ к переменным среды

В Службе приложений можно задать параметры приложения вне кода приложения. Затем вы можете получить доступ к ним с помощью стандартного шаблона Node.js. Например, для доступа к параметру приложения с именем NODE_ENV используйте следующий код:

process.env.NODE_ENV

Запуск Grunt/Bower/Gulp

По умолчанию автоматизация сборки службы приложений выполняется npm install --production при распознавании того, что приложение Node.js развертывается с помощью Git или с помощью zip-развертывания с включенной автоматизацией сборки. Если приложению требуются какие-либо популярные средства автоматизации, такие как Grunt, Bower или Gulp, вам необходимо предоставить пользовательский скрипт развертывания для запуска приложения.

Чтобы разрешить репозиторию запускать эти средства, необходимо добавить их в зависимости в файле package.json. Например:

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

В окне локального терминала измените каталог в корневой каталог репозитория и выполните следующие команды:

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

Корень репозитория теперь содержит два дополнительных файла: .deployment и deploy.sh.

Откройте файл deploy.sh и найдите раздел Deployment, который выглядит следующим образом:

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

В конце этого раздела npm install --production выполняется. Добавьте раздел кода для запуска необходимого инструмента в конец раздела Deployment:

Бельведер
Gulp;
Хрюкать

Пример см. в примере MEAN.js. В этом примере скрипт развертывания также выполняет пользовательскую npm install команду.

Беседка

Этот фрагмент кода отвечает за запуск 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 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.

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

Обнаружение сеанса HTTPS

В службе приложений завершение TLS/SSL происходит в сетевых подсистемах балансировки нагрузки, поэтому все HTTPS-запросы достигают приложения как незашифрованные HTTP-запросы. Если логика приложения должна проверить, шифруются ли запросы пользователей, проверьте X-Forwarded-Proto заголовок.

Популярные веб-платформы позволяют получить доступ к информации X-Forwarded-* в стандартном шаблоне приложения. В Express можно использовать доверенные прокси-серверы. Например:

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

Доступ к журналам диагностики

Чтобы получить доступ к журналам консоли, созданным из кода приложения в Службе Приложений, включите ведение журнала диагностики, выполнив следующую команду в Cloud Shell:

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

Возможные значения для --level: Error, Warning, Info и Verbose. Каждый последующий уровень включает предыдущий уровень. Например, Error включает только сообщения об ошибках. Verbose включает все сообщения.

После включения ведения журнала диагностики выполните следующую команду, чтобы просмотреть поток журналов:

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

Если журналы консоли не отображаются немедленно, повторите попытку через 30 секунд.

Чтобы прекратить потоковую передачу журнала в любое время, нажмите Ctrl+C.

Вы можете получить доступ к журналам консоли, созданным из контейнера.

Чтобы включить ведение журнала контейнеров, выполните следующую команду:

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

Замените <app-name> и <resource-group-name> на имена, соответствующие вашему веб-приложению.

После включения ведения журнала контейнеров выполните следующую команду, чтобы просмотреть поток журналов:

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

Если журналы консоли не отображаются немедленно, повторите попытку через 30 секунд.

Чтобы прекратить потоковую передачу журнала в любое время, нажмите Ctrl+C.

Перезаписи URL-адресов

При развертывании приложений Node.js в службе приложение Azure для Linux может потребоваться обрабатывать перезаписи URL-адресов непосредственно в приложении. Эта конфигурация особенно полезна для обеспечения перенаправления определенных шаблонов URL-адресов на правильные конечные точки без использования конфигураций веб-сервера. Существует несколько способов выполнения перезаписи URL-адресов в Node.js. Одним из примеров является использование пакета express-urlrewrite .

Мониторинг приложения с помощью Application Insights

Application Insights позволяет отслеживать производительность, исключения и использование приложения без внесения изменений в код. Чтобы подключить агент Application Insights, перейдите к веб-приложению на портале, выберите Application Insights в разделе "Мониторинг" и нажмите кнопку "Включить Application Insights". Затем выберите существующий ресурс Application Insights или создайте новый ресурс. Наконец, нажмите кнопку "Применить" в нижней части страницы. Чтобы инструментировать веб-приложение с помощью PowerShell, ознакомьтесь с этими инструкциями.

Этот агент отслеживает приложение Node.js на стороне сервера. Чтобы отслеживать JavaScript на стороне клиента, добавьте в проект пакет SDK для JavaScript.

Дополнительные сведения см. в статье "Включение мониторинга приложений" в Службе приложений Azure для .NET, Node.js, Python и java-приложений.

Устранение неполадок

Если рабочее приложение Node.js неправильно функционирует в Службе приложений или его работа сопровождается ошибками, попробуйте сделать следующее:

Получите доступ к потоку журнала.
Протестируйте приложение локально в рабочем режиме. Служба приложений запускает приложения Node.js в рабочем режиме, поэтому вам необходимо убедиться в том, что проект работает надлежащим образом локально в рабочем режиме. Например:
- В зависимости от package.json различные пакеты могут быть установлены в рабочем режиме (dependencies vs. devDependencies).
- Некоторые веб-платформы могут развертывать статические файлы по-разному в рабочем режиме.
- Некоторые веб-платформы могут использовать пользовательские скрипты запуска при выполнении в рабочем режиме.
Запустите свое приложение в Службе приложений в режиме разработки. Например, в MEAN.js можно задать режим разработки приложения во время выполнения, задав NODE_ENV параметр приложения.

У вас нет разрешения на просмотр этого каталога или страницы

После развертывания кода Node.js в собственном приложении Windows в Службе приложений может появиться сообщение You do not have permission to view this directory or page в браузере при переходе по URL-адресу приложения. Эта ошибка, скорее всего, возникает, так как у вас нет файлаweb.config . (См. шаблон и пример.)

Если вы развертываете файлы с помощью Git или с помощью ZIP-развертывания с включенной автоматизацией сборки, подсистема развертывания создает файлweb.config в веб-корне приложения (%HOME%\site\wwwroot) автоматически, если одно из следующих условий имеет значение true:

Корневой каталог проекта содержит файлpackage.json , который определяет start скрипт, содержащий путь к файлу JavaScript.
Корневой каталог проекта содержит server.js или файл app.js .

Созданный web.config файл адаптирован к обнаруженному скрипту запуска. Для других методов развертывания добавьте файл web.config вручную. Убедитесь, что файл правильно отформатирован.

Если вы используете zip-развертывание (например, с помощью Visual Studio Code), обязательно включите автоматизацию сборки. По умолчанию она отключена. az webapp up использует развертывание на основе ZIP-файла с включенной автоматизацией сборки.

Игнорировать сообщение робота933456 в журналах

В журналах контейнеров может появиться следующее сообщение:

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

Это сообщение можно проигнорировать. /robots933456.txt — это фиктивный URL-путь, с помощью которого Служба приложений проверяет, может ли контейнер обслуживать запросы. Ответ 404 указывает, что путь не существует, и он сигнализирует службе приложений о том, что контейнер работоспособен и готов реагировать на запросы.

Руководство по Node.js приложению с MongoDB

Служба приложений Azure на платформе Linux: вопросы и ответы

Справка по переменным среды и параметрам приложений

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2025-08-29

Поделиться через

Настройка приложения Node.js для Службы приложений Azure

Отображение версии Node.js

Настройка версии Node.js

Что происходит с устаревшими средами выполнения в сервисе приложений?

Установка номера порта

Настройка автоматизации сборки

Настройка сервера Node.js

Запуск с помощью PM2

Запуск с помощью настраиваемой команды

Запустите с помощью команды npm start

Удаленная отладка

Доступ к переменным среды

Запуск Grunt/Bower/Gulp

Беседка

Глотать

Ворчание

Обнаружение сеанса HTTPS

Доступ к журналам диагностики

Перезаписи URL-адресов

Мониторинг приложения с помощью Application Insights

Устранение неполадок

У вас нет разрешения на просмотр этого каталога или страницы

Игнорировать сообщение робота933456 в журналах

Связанный контент

Обратная связь

Дополнительные ресурсы