Azure App Service 向けの Node.js アプリを構成する

Node.js アプリは、必要なすべての npm 依存関係と共にデプロイする必要があります。 App Service 展開エンジンは、npm install --productionをデプロイするとき、またはビルド自動化が有効になっている Zip パッケージをデプロイするときに、を自動的に実行します。ただし、FTP/S を使用してファイルをデプロイする場合、必要なパッケージを手動でアップロードする必要があります。

この記事では、主要な概念について説明し、App Service にデプロイする Node.js 開発者向けの手順について説明します。 Azure App Service を使用したことがない場合は、まず、Node.js クイックスタートと MongoDB を使った Node.js のチュートリアルを完了してください。

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="~24"

注

この例では、推奨されるチルダ構文を使用して、App Service 上の Node.js 24 ランタイムの最新バージョンをターゲットにします。

ランタイムはプラットフォームによって定期的に修正プログラムが適用および更新されるため、特定のマイナーバージョン/パッチをターゲットにすることはお勧めしません。潜在的なセキュリティリスクのため、これらのバージョンは使用できる保証はありません。

注

プロジェクトの package.json で Node.js バージョンを設定する必要があります。展開エンジンは、サポートされているすべての Node.js バージョンを含む別のプロセスで実行されます。

サポートされている Node.js バージョンにアプリを設定するには、Cloud Shell で次のコマンドを実行します。

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

この設定では、実行時と、Kudu でのパッケージの自動復元中の両方で使用する Node.js のバージョンを指定します。

注

プロジェクトの package.json で Node.js バージョンを設定する必要があります。デプロイエンジンは、サポートされているすべての Node.js バージョンを含む別のコンテナーで実行します。

App Service の古いランタイムはどうなりますか?

古いランタイムは、保守組織によって非推奨になっているか、重大な脆弱性があります。そのため、ポータルの作成ページと構成ページから削除されます。古いランタイムがポータルから非表示になっている場合、そのランタイムをまだ使用しているアプリは引き続き実行されます。

ポータルに表示されなくなった古いランタイムバージョンを使用してアプリを作成する場合は、Azure CLI、ARM テンプレート、または Bicep を使用してください。これらのデプロイの代替手段を使用すると、ポータルから削除されたが、引き続きサポートされている非推奨のランタイムを作成できます。

ランタイムが App Service プラットフォームから完全に削除された場合、Azure サブスクリプション所有者は削除前に電子メール通知を受け取ります。

ポート番号を設定する

Node.js アプリは、着信する要求を受信するための適切なポートをリッスンする必要があります。

Windows 上の App Service では、Node.js アプリは IISNode でホストされ、Node.js アプリは、 process.env.PORT 変数で指定されたポートをリッスンする必要があります。次の例は、単純な Express アプリでポートを設定する方法を示しています:

App Service では、Node.js コンテナーに環境変数 PORT が設定され、そのポート番号で受信要求がコンテナーに転送されます。要求を受信するには、アプリが 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 パッケージを使用してアプリをデプロイする場合、App Service ビルド自動化は次の手順を完了します:

PRE_BUILD_SCRIPT_PATH によってカスタムスクリプトが指定された場合、それを実行します。
フラグを指定せずに npm install を実行します。この手順には、npm preinstall と postinstall スクリプトが含まれており、 devDependencies もインストールされます。
npm run build ファイル内でビルドスクリプトが指定されている場合、を実行します。
npm run build:azure ファイル内で build:azure スクリプトが指定されている場合、を実行します。
POST_BUILD_SCRIPT_PATH によってカスタムスクリプトが指定された場合、それを実行します。

注

npm ドキュメントで説明されているように、prebuild および postbuild という名前のスクリプトは、それぞれbuildの前後に実行されます (指定されている場合)。 preinstall と postinstall という名前のスクリプトはそれぞれ、install の前と後に実行されます。

PRE_BUILD_COMMAND および POST_BUILD_COMMAND は、既定では空の環境変数です。ビルド前のコマンドを実行するには、PRE_BUILD_COMMAND を定義します。ビルド後のコマンドを実行するには、POST_BUILD_COMMAND を定義します。

次の例では、一連のコマンドを指定するために 2 つの変数をコンマ区切りで使用しています。

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 の構成」を参照してください。

App Service が Linux でアプリ Node.js 実行およびビルドする方法の詳細については、 Oryx のドキュメント: アプリの検出とビルド Node.js 方法に関するページを参照してください。

Node.js サーバーを構成する

Node.js コンテナーには、生産プロセスマネージャーである PM2 が付属しています。 PM2、npm start、またはカスタムコマンドで開始するようにアプリを構成できます。

ツール	目的
PM2 で実行する	推奨。運用またはステージングの使用。 PM2 がフルサービスアプリ管理プラットフォームを提供します。
npm start を使用して実行する	開発での使用のみ。
カスタムコマンドを使用して実行する	開発またはステージング。

PM2 で実行する

コンテナーは、一般的な Node.js ファイルの 1 つがプロジェクトで見つかった場合、PM2 でアプリを自動的に開始します。

bin/www
server.js
app.js
index.js
hostingstart.js
次のいずれかの PM2 ファイル: process.json または ecosystem.config.js

次の拡張子を持つカスタムスタートファイルを構成することもできます。

.js ファイル
.json、. config.js、.yaml、または .yml の拡張子を持つ PM2 ファイル

注

Node 14 LTS より後の Node.js バージョンでは、コンテナーは PM2 でアプリを自動的に起動しません。 PM2 でアプリを起動するには、スタートアップコマンドを pm2 start <.js-file-or-PM2-file> --no-daemon に設定します。コンテナーが正常に動作するには、PM2 をフォアグラウンドで実行する必要があるため、引数 --no-daemon を必ず使用してください。

カスタムスタートファイルを追加するには、 Cloud Shell で次のコマンドを実行します。

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

カスタムコマンドを使用して実行する

App Service は、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.json を使用するには、 Cloud Shell で次のコマンドを実行します。

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

リモートデバッグ

PM2 で実行するように構成した場合、*.config.js、*.yml、または .yaml を使用して実行したときを除き、Visual Studio Code で Node.js アプリをリモートからデバッグできます。

ほとんどの場合、アプリ用に追加の構成は必要ありません。 process.json ファイル (既定またはカスタム) を使用してアプリを実行する場合は、JSON ルートに script プロパティが必要です。次に例を示します。

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

リモートデバッグ用に Visual Studio Code を設定するには、 App Service 拡張機能をインストールします。拡張機能ページの指示に従い、Visual Studio Code で Azure にサインインします。

Azure エクスプローラーで、デバッグするアプリを見つけ、それを右クリックして、[リモートデバッグを開始する] を選択します。アプリのリモートデバッグを有効にするには、[ はい ] を選択します。 App Service により、トンネルプロキシが開始され、デバッガがアタッチされます。続いて、アプリに対して要求を行って、ブレークポイントで中断しているデバッガを確認できます。

デバッグが完了すると、[切断] を選択してデバッガを停止します。メッセージが表示されたら、[ はい ] を選択してリモートデバッグを無効にする必要があります。後で無効にするには、Azure エクスプローラーでアプリをもう一度右クリックし、[ リモートデバッグを無効にする] を選択します。

環境変数へのアクセス

App Service では、アプリコードの外部でアプリ設定を設定できます。その後、標準の Node.js パターンを使用して、それらにアクセスできます。たとえば、NODE_ENV というアプリ設定にアクセスするには、次のコードを使用します。

process.env.NODE_ENV

Grunt/Bower/Gulp を実行する

既定では、App Service のビルド自動化によって、Node.js アプリが Git を介して、またはnpm install --production 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 という 2 つの追加ファイルが追加されました。

deploy.sh 開き、次のようなDeployment セクションを見つけます。

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

このセクションの最後に、npm install --production が実行されます。セクションのDeployment、必要なツールを実行するために必要なコードセクションを追加します。

バウアー
Gulp
グラント

例については、MEAN.js サンプルを参照してください。このサンプルでは、デプロイスクリプトはカスタム npm install コマンドも実行します。

Bower

このスニペットは 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

このスニペットは grunt を実行します。

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

HTTPS セッションの検出

App Service では、TLS または SSL 終了がネットワークロードバランサーで発生するため、すべての HTTPS リクエストは暗号化されていない HTTP 要求としてアプリに到達します。ユーザー要求が暗号化されているかどうかをアプリロジックで確認する必要がある場合は、X-Forwarded-Proto ヘッダーを調べます。

一般的な Web フレームワークでは、標準のアプリパターンで X-Forwarded-* 情報にアクセスできます。 Express では、信頼プロキシを使用できます。次に例を示します。

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

診断ログにアクセスする

App Service のアプリケーションコード内から生成されたコンソールログにアクセスするには、 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+ キーを押します。

コンテナー内から生成されたコンソールログにアクセスできます。

コンテナーのログを有効にするには、次のコマンドを実行します。

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

<app-name>と<resource-group-name>の値を、Web アプリに適した名前に置き換えます。

コンテナーログがオンになったら、次のコマンドを実行して、ログのストリームを確認します。

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

コンソールログがすぐに表示されない場合は、30 秒後にもう一度確認してください。

ログストリーミングをいつでも停止するには、キーボードショートカット Ctrl + C キーを使用します。

URL の書き換え

Node.js アプリを Azure App Service for Linux にデプロイする場合は、アプリケーション内で直接 URL の書き換え処理を行う必要がある場合があります。この構成は、Web サーバーの構成に依存せずに、特定の URL パターンが正しいエンドポイントにリダイレクトされるようにするために特に便利です。 Node.js で URL の書き換えを行うには、いくつかの方法があります。たとえば、express-urlrewrite パッケージです。

Application Insights を使用してアプリを監視する

Application Insights を使用すると、コードを変更することなく、アプリケーションのパフォーマンス、例外、使用状況を監視できます。 Application Insights エージェントをアタッチするには、ポータルで自分の Web アプリにアクセスし、[監視] で [Application Insights] を選択してから、[Application Insights を有効にする] を選択します。次に、既存の Application Insights リソースを選択するか、新しいものを作成します。最後に、ページの下部にある [適用] を選択します。 PowerShell を使用して Web アプリをインストルメント化するには、これらの手順を参照してください。

このエージェントは、サーバー側の Node.js アプリケーションを監視します。クライアント側の JavaScript を監視するには、 JavaScript SDK をプロジェクトに追加します。

詳細については、「Azure App Service での .NET、Node.js、Python、Java アプリケーションのアプリケーション監視を有効にする」を参照してください。

トラブルシューティング

動作中の Node.js アプリが App Service で異なる動作をしたり、エラーが発生した場合は、次のことを試してください。

ログストリームにアクセスします。
実稼働モードでローカルにアプリをテストします。 App Service では、実稼働モードで Node.js アプリが実行されるので、プロジェクトがローカルで実稼働モードで予想どおりに動作することを確認する必要があります。次に例を示します。
- package.jsonによっては、運用モード (dependenciesとdevDependencies) に異なるパッケージがインストールされる場合があります。
- 特定の Web フレームワークでは、実稼働モードで静的ファイルを別にデプロイすることがあります。
- 特定の Web フレームワークでは、実稼働モードで実行しているときにカスタムスタートアップスクリプトを使用することがあります。
開発モードの App Service でアプリを実行します。たとえば、MEAN.jsでは、NODE_ENV アプリ設定を設定することで、実行時にアプリを開発モードに設定できます。

このディレクトリまたはページを表示するアクセス許可がない

App Service でネイティブ Windows アプリに Node.js コードをデプロイした後、アプリの URL に移動すると、ブラウザーに You do not have permission to view this directory or page というメッセージが表示される場合があります。このエラーは、web.config ファイルがないために発生する可能性が最も高いです。 ( テンプレートと例を参照してください)。

Git を使用してファイルをデプロイした場合、またはビルドの自動化を有効にして ZIP デプロイを使用した場合、以下のいずれかの条件が満たされると、展開エンジンによって、アプリの Web ルート () に、web.config%HOME%\site\wwwroot ファイルが自動的に生成されます:

プロジェクトルートに、JavaScript ファイルのパスを含むスクリプトを定義する、start ファイルが含まれています。
プロジェクトルートに、server.js または app.js ファイルのいずれかが含まれています。

生成された web.config ファイルは、検出された開始スクリプトに合わせて調整されています。その他のデプロイ方法の場合は、この web.config ファイルを手動で追加してください。ファイルが適切に書式設定されていることを確認します。

ZIPデプロイ(例えばVisual Studio Codeやaz webapp deploy)を使っている場合は、必ずビルド自動化を有効にしてください。これは、既定では有効になっていません。

ログ内の robots933456 メッセージを無視する

コンテナーログで次のメッセージが表示されることがあります。

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

このメッセージは無視してかまいません。 /robots933456.txt はダミーの URL パスです。 App Service はそれを使用して、コンテナーが要求を提供できるかどうかを確認します。 "404" エラー応答は、パスが存在しないことを示し、コンテナーが正常であり、要求に応答する準備ができていることを App Service に通知します。

チュートリアル: MongoDB を使用してアプリを Node.js する

Azure App Service on Linux の FAQ

環境変数とアプリ設定のリファレンス

フィードバック

このページはお役に立ちましたか?

最終更新: 2025-09-09