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

2025-09-09

Node.js アプリは、必要なすべての npm 依存関係と共にデプロイする必要があります。 App Service デプロイエンジンは、Git リポジトリをデプロイするとき、またはビルド自動化を有効にして Zip パッケージをデプロイするときに、npm install --production自動的に実行されます。ただし、 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="~16"

注

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

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

注

プロジェクトの 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|14-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もインストールされます。
package.jsonファイルにビルドスクリプトが指定されている場合は、npm run buildを実行します。
package.jsonファイルにbuild:azure スクリプトが指定されている場合は、npm run 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 以降では、コンテナーは 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"

リモートデバッグ

.config.js、.yml、または .yaml ファイルを使用して実行する場合を除き、PM2 で実行するように構成した場合は、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 またはビルド自動化を有効にした Zip デプロイを介してデプロイされていることが認識されると、npm install --production実行されます。アプリで 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、必要なツールを実行するために必要なコードセクションを追加します。

バウアー
飲む
グラント

例については、 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

このスニペットは 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+ キーを押します。

URL の書き換え

Node.js アプリを Azure App Service for Linux にデプロイする場合は、アプリケーション内で直接 URL の書き換え処理を行う必要がある場合があります。この構成は、Web サーバーの構成に依存せずに、特定の URL パターンが正しいエンドポイントにリダイレクトされるようにするために特に役立ちます。 Node.js で URL の書き換えを行うには、いくつかの方法があります。 1 つの例として、 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 for .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 アプリ設定を設定することで、実行時にアプリを開発モードに設定できます。

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

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

Git を使用するか、ビルド自動化を有効にした ZIP デプロイを使用してファイルをデプロイする場合、次のいずれかの条件に該当する場合、デプロイエンジンはアプリの Web ルート (%HOME%\site\wwwroot) に web.configファイルを自動的に生成します。

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

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

(たとえば、Visual Studio Code を使用して) ZIP デプロイを使用する場合は、ビルドの自動化を有効にしてください。これは、既定では有効になっていません。 az webapp up では、ビルドの自動化が有効になっている ZIP デプロイを使用します。

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

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

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

このメッセージは無視してかまいません。 /robots933456.txt は、コンテナーが要求を処理できるかどうかを調べるために App Service が使用するダミーの URL パスです。 404 応答は、パスが存在しないことを示し、コンテナーが正常であり、要求に応答できる状態であることを App Service に知らせます。

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

Azure App Service on Linux FAQ

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

フィードバック

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