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

2025-05-01

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="~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 変数で指定されたポートをリッスンする必要があります。次の例は、単純な簡易アプリで行う方法を示しています。

App Service では、Node.js コンテナーに環境変数 PORT が設定され、そのポート番号で受信要求がコンテナーに転送されます。要求を受信するには、アプリで process.env.PORT を使用して、そのポートがリッスンされる必要があります。次の例は、単純な簡易アプリで行う方法を示しています。

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 を実行します。
npm run build:azure 内で 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 ファイル

注

ノード 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 スクリプトが npm start ファイル内にあることを確認するだけです。次に例を示します。

{
  ...
  "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 を実行します。

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 をプロジェクトに追加します。

詳細については、 Application Insights 拡張機能のリリースノートを参照してください。

トラブルシューティング

動作中の 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 ルート (%HOME%\site\wwwroot) にweb.configが自動的に生成されます。

プロジェクトのルートにはpackage.jsonがあり、それがJavaScriptファイルのパスを含むstartスクリプトを定義します。
プロジェクトルートには、 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

または、その他のリソースを参照してください。

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