Configurer une application Node.js pour Azure App Service

Les applications Node.js doivent être déployées avec toutes les dépendances npm nécessaires. Le moteur de déploiement App Service exécute automatiquement npm install --production pour vous lorsque vous déployez un référentiel Git ou lorsque vous déployez un Package zip avec automatisation de génération activée. Si vous déployez vos fichiers en utilisant FTP/S, vous devez cependant télécharger les packages requis manuellement.

Cet article décrit les concepts clés et fournit des instructions pour les développeurs Node.js qui déploient sur App Service. Si vous n’avez jamais utilisé Azure App Service, suivez le Démarrage rapide Node.js et le Tutoriel Node.js avec MongoDB au préalable.

Afficher la version Node.js

Pour afficher la version actuelle de Node.js, exécutez la commande suivante dans Cloud Shell :

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

Pour afficher toutes les versions de Node.js prises en charge, exécutez la commande suivante dans Cloud Shell :

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

Pour afficher la version actuelle de Node.js, exécutez la commande suivante dans Cloud Shell :

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

Pour afficher toutes les versions de Node.js prises en charge, exécutez la commande suivante dans Cloud Shell :

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

Définir la version Node.js

Pour définir votre application dans une version de Node.js prise en charge, exécutez la commande suivante dans Cloud Shell pour définir WEBSITE_NODE_DEFAULT_VERSION sur une version prise en charge :

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

Remarque

Cet exemple utilise la syntaxe tilde recommandée pour cibler la dernière version disponible du runtime Node.js 24 sur App Service.

Le runtime étant régulièrement corrigé et mis à jour par la plateforme, nous vous déconseillons de cibler une version mineure ou un correctif spécifique. En raison des risques de sécurité potentiels, la disponibilité de ces versions n’est pas garantie.

Remarque

Vous devez définir la version de Node.js dans le fichier package.json de votre projet. Le moteur de déploiement s’exécute dans un processus distinct qui inclut toutes les versions de Node.js prises en charge.

Pour définir votre application dans une version de Node.js prise en charge, exécutez la commande suivante dans Cloud Shell :

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

Ce paramètre spécifie la version de Node.js à utiliser, à la fois lors de l’exécution et pendant la restauration de package automatisée dans Kudu.

Remarque

Vous devez définir la version de Node.js dans le fichier package.json de votre projet. Le moteur de déploiement s’exécute dans un conteneur distinct qui inclut toutes les versions de Node.js prises en charge.

Que se passe-t-il pour les runtimes obsolètes dans App Service ?

Les runtimes obsolètes sont déconseillés par l’organisation de maintenance ou présentent des vulnérabilités importantes. En conséquence, ils sont supprimés de la création et de la configuration des pages dans le portail. Lorsqu’un runtime obsolète est masqué dans le portail, toute application qui utilise toujours ce runtime continue à s’exécuter.

Si vous souhaitez créer une application avec une version d’exécution obsolète qui n’est plus affichée sur le portail, utilisez Azure CLI, un modèle ARM ou Bicep. Ces alternatives de déploiement vous permettent de créer des moteurs d’exécution obsolètes qui ont été supprimés du portail, mais qui sont toujours pris en charge.

Si un runtime est entièrement supprimé de la plateforme App Service, le propriétaire de votre abonnement Azure reçoit un e-mail avant la suppression.

Définir le numéro de port

Votre application Node.js doit écouter sur le port approprié pour recevoir les demandes entrantes.

Dans App Service sur Windows, les applications Node.js sont hébergées avec IISNode, et votre application Node.js doit écouter sur le port spécifié dans la variable process.env.PORT. L’exemple suivant montre comment le faire dans une application Express simple :

App Service définit la variable d’environnement PORT dans le conteneur Node.js et transfère les demandes entrantes à votre conteneur sur ce numéro de port. Pour recevoir les demandes, votre application doit écouter le port spécifié dans la variable process.env.PORT. L’exemple suivant montre comment définir le port dans une application Express simple :

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}`)
})

Personnaliser l’automatisation de la génération

Si vous déployez votre application en utilisant Git ou de packages zip avec automatisation de génération activée, l’automatisation de génération App Service suit la séquence suivante :

Exécuter un script personnalisé si PRE_BUILD_SCRIPT_PATH en spécifie un.
Exécuter npm install sans indicateur. Cette étape inclut les scripts npm preinstall et postinstall, et installe également devDependencies.
Exécuter npm run build si un script de génération est défini dans votre package.json.
Exécuter npm run build:azure si un script build:azure est défini dans votre package.json.
Exécuter un script personnalisé si POST_BUILD_SCRIPT_PATH en spécifie un.

Remarque

Comme cela est indiqué dans la documentation npm, les scripts nommés prebuild et postbuild s’exécutent avant et après build, respectivement, s’ils sont définis. Les scripts nommés preinstall et postinstall s’exécutent avant et après install, respectivement.

PRE_BUILD_COMMAND et POST_BUILD_COMMAND sont des variables d’environnement qui sont vides par défaut. Pour exécuter des commandes pré-build, définissez PRE_BUILD_COMMAND. Pour exécuter des commandes post-build, définissez POST_BUILD_COMMAND.

L’exemple suivant utilise les deux variables pour spécifier une série de commandes, qui sont séparées par des virgules.

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"

Pour plus d’informations sur les autres variables d’environnement permettant de personnaliser l’automatisation de génération, consultez Configuration Oryx.

Pour plus d’informations sur la façon dont App Service exécute et génère des applications Node.js dans Linux, consultez Documentation Oryx : comment les applications Node.js sont détectées et générées.

Configurer un serveur Node.js

Les conteneurs Node.js sont fournis avec PM2, un gestionnaire de processus de production. Vous pouvez configurer votre application pour qu’elle démarre avec PM2, avec npm start ou avec une commande personnalisée.

Outil	Objectif
Exécuter avec PM2	Recommandé. Utilisation en production ou en gestion intermédiaire. PM2 fournit une plateforme complète de gestion des applications.
Exécuter avec npm start	À utiliser uniquement dans un environnement de développement.
Exécuter avec une commande personnalisée	À utiliser dans un environnement de développement intermédiaire.

Exécuter avec PM2

Le conteneur démarre automatiquement votre application avec PM2 lorsqu’un des fichiers Node.js communs se trouve dans votre projet :

bin/www
server.js
app.js
index.js
hostingstart.js
Un des fichiers PM2 suivants : process.json ou ecosystem.config.js

Vous pouvez également configurer un fichier de démarrage personnalisé avec les extensions suivantes :

Fichier .js
Fichier PM2 qui a une extension .json, .config.js, .yaml ou .yml

Remarque

Avec Node.js versions après Node 14 LTS, le conteneur ne démarre pas automatiquement votre application avec PM2. Pour démarrer votre application avec PM2, définissez la commande de démarrage sur pm2 start <.js-file-or-PM2-file> --no-daemon. Utilisez l’argument --no-daemon, car PM2 doit s’exécuter au premier plan pour que le conteneur fonctionne correctement.

Pour ajouter un fichier de démarrage personnalisé, exécutez la commande suivante dans Cloud Shell :

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

Exécuter avec une commande personnalisée

App Service peut démarrer votre application à l’aide d’une commande personnalisée, par exemple un exécutable tel que run.sh. Par exemple, pour exécuter npm run start:prod, exécutez la commande suivante dans Cloud Shell :

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

Exécuter avec npm start

Pour démarrer votre application avec npm start, assurez-vous qu’un script start se trouve dans le fichier package.json. Exemple :

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

Pour utiliser un fichier package.json personnalisé dans votre projet, exécutez la commande suivante dans Cloud Shell :

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

Déboguer à distance

Vous pouvez déboguer votre application Node.js à distance dans Visual Studio Code si vous la configurez de manière à s’exécuter avec PM2, sauf lorsque vous l’exécutez à l’aide d’un fichier .config.js, yml, ou .yaml.

Dans la plupart des cas, aucune configuration supplémentaire n’est nécessaire pour votre application. Si votre application est exécutée avec un fichier process.json (par défaut ou personnalisé), elle doit avoir une propriété script dans la racine JSON. Exemple :

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

Pour configurer Visual Studio Code pour le débogage à distance, installez l’extension App Service. Suivez les instructions sur la page d’extension et connectez-vous à Azure dans Visual Studio Code.

Dans l’Explorateur Azure, recherchez l’application que vous souhaitez déboguer, cliquez dessus avec le bouton droit et sélectionnez Démarrer le débogage à distance. Sélectionnez Oui pour activer le débogage à distance pour votre application. App Service démarre un proxy de tunnel pour vous et joint le débogueur. Vous pouvez ensuite effectuer des requêtes auprès de l’application et voir les interruptions du débogueur au niveau des points d’arrêt.

Une fois que vous avez fini le débogage, arrêtez le débogueur en sélectionnant Déconnecter. Lorsque vous y êtes invité, vous devez sélectionner Oui pour désactiver le débogage à distance. Pour le désactiver ultérieurement, cliquez une nouvelle fois sur votre application dans l’Explorateur Azure, puis sélectionnez Désactiver le débogage à distance.

Accéder aux variables d’environnement

Dans App Service, vous pouvez définir les paramètres de l’application en dehors de votre code d’application. Vous pouvez ensuite y accéder en utilisant le modèle Node.js standard. Par exemple, pour accéder à un paramètre d’application nommé NODE_ENV, utilisez le code suivant :

process.env.NODE_ENV

Exécuter Grunt/Bower/Gulp

Par défaut, l’automatisation de génération App Service exécute npm install --production lorsqu’elle reconnaît qu’une application Node.js est déployée via Git ou un déploiement Zip avec automatisation de génération activée. Si votre application requiert des outils d’automatisation populaires, tels que Grunt, Bower ou Gulp, vous devez fournir un script de déploiement personnalisé pour l’exécution.

Pour permettre à votre dépôt d’exécuter ces outils, vous devez les ajouter aux dépendances dans package.json. Exemple :

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

Dans une fenêtre de terminal locale, remplacez le répertoire par la racine du référentiel et exécutez les commandes suivantes :

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

La racine du référentiel comporte désormais deux fichiers supplémentaires : .deployment et deploy.sh.

Ouvrez deploy.sh et recherchez la section Deployment, qui ressemble à ce qui suit :

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

À la fin de cette section, npm install --production est exécuté. Ajoutez la section de code dont vous avez besoin pour exécuter l’outil requis à la fin de la section Deployment :

Bower
Gulp
Grunt

Pour obtenir un exemple, consultez l’exemple MEAN.js. Dans cet exemple, le script de déploiement exécute également une commande npm install personnalisée.

Bower

Cet extrait de code exécute 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

Cet extrait de code exécute 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

Cet extrait de code exécute grunt.

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

Détecter une session HTTPS

Dans App Service, une terminaison TLS/SSL se produit au niveau des équilibreurs de charge réseau. Toutes les requêtes HTTPS accèdent donc à votre application en tant que requêtes HTTP non chiffrées. Si votre logique d’application doit vérifier si les demandes utilisateur sont chiffrées, inspectez l’en-tête X-Forwarded-Proto.

Les frameworks web populaires vous permettent d’accéder aux informations X-Forwarded-* dans votre modèle d’application standard. Dans Express, vous pouvez utiliser des proxies de confiance. Exemple :

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

Accéder aux journaux de diagnostic

Pour accéder aux journaux de console générés à partir du code de votre application dans App Service, activez la journalisation des diagnostics en exécutant la commande suivante dans Cloud Shell :

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

Les valeurs possibles pour --level sont Error, Warning, Info, et Verbose. Chaque niveau suivant comprend le niveau précédent. Par exemple, Error inclut uniquement les messages d’erreur. Verbose inclut tous les messages.

Après avoir activé la journalisation des diagnostics, exécutez la commande suivante pour afficher le flux de journaux :

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

Si les logs de console ne s’affichent pas immédiatement, revérifiez dans 30 secondes.

Pour arrêter le streaming de journaux à tout moment, sélectionnez Ctrl+C.

Vous pouvez accéder aux journaux de la console qui sont générés à partir du conteneur.

Pour activer la journalisation des conteneurs, exécutez la commande suivante :

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

Remplacez les valeurs <app-name> et <resource-group-name> par des noms appropriés pour votre application web.

Après avoir activé la journalisation des conteneurs, exécutez la commande suivante pour afficher le flux de journaux :

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

Si les logs de console ne s’affichent pas immédiatement, revérifiez dans 30 secondes.

Pour arrêter le streaming des logs (journaux) à tout moment, utilisez le raccourci clavier Ctrl+C.

Réécritures d’URL

Lors du déploiement d’applications Node.js sur Azure App Service pour Linux, vous devez peut-être gérer les réécritures d’URL directement au sein de votre application. Cette configuration est particulièrement utile pour garantir que des modèles d’URL spécifiques sont redirigés vers les points de terminaison appropriés sans compter sur les configurations de serveur web. Il existe plusieurs façons d’effectuer des réécritures d’URL dans Node.js. L’un des exemples consiste à utiliser le package express-urlrewrite.

Surveiller votre application en utilisant Application Insights

Application Insights vous permet de superviser les performances, les exceptions et l’utilisation de votre application sans modifier le code. Pour attacher l’agent Application Insights, accédez à votre application web dans le portail, sélectionnez Application Insights sous Paramètres, puis sélectionnez Activer Application Insights. Sélectionnez ensuite une ressource Application Insights existante ou créez-en une. Enfin, sélectionnez Appliquer en bas de la page. Pour instrumenter votre application web en utilisant PowerShell, consultez ces instructions.

Cet agent supervise votre application de Node.js côté serveur. Pour superviser votre code JavaScript côté client, ajoutez le SDK JavaScript à votre projet.

Pour plus d’informations, consultez Activer la surveillance des applications dans les applications Azure App Service pour .NET, Node.js, Python et Java.

Dépannage

Quand une application Node.js en fonctionnement se comporte différemment dans App Service ou comporte des erreurs, essayez ce qui suit :

Accéder au flux de journaux.
Testez l’application localement en mode de production. App Service exécute vos applications Node.js en mode de production et dès lors, vous devez vous assurer que votre projet fonctionne comme prévu en mode de production localement. Exemple :
- En fonction de votre package.json, différents packages peuvent être installés pour le mode de production (dependencies et devDependencies).
- Certaines infrastructures web peuvent déployer des fichiers statiques différemment en mode de production.
- Certaines infrastructures web peuvent utiliser des scripts de démarrage personnalisés lorsqu’elles s’exécutent en mode de production.
Exécutez votre application dans App Service en mode de développement. Par exemple, dans MEAN.js, vous pouvez configurer votre application en mode de développement au moment du runtime en configurant le paramètre d’application NODE_ENV.

Vous n'êtes pas autorisé à voir ce répertoire ou cette page

Après avoir déployé votre code Node.js dans une application Windows native dans App Service, le message You do not have permission to view this directory or page peut s’afficher dans le navigateur quand vous accédez à l’URL de votre application. Cette erreur se produit probablement, car vous n’avez pas de fichier web.config. (Consultez le modèle et un exemple.)

Si vous déployez vos fichiers en utilisant Git, ou un déploiement ZIP avec automatisation de génération activée, le moteur de déploiement génère automatiquement un fichier web.config dans la racine web de votre application (%HOME%\site\wwwroot) si l’une des conditions suivantes est vraie :

La racine de votre projet comprend un fichier package.json qui définit un script start qui contient le chemin d’un fichier JavaScript.
La racine de votre projet contient un fichier server.js ou app.js.

Le fichier web.config généré est adapté au script de démarrage détecté. Pour les autres méthodes de déploiement, ajoutez le fichier web.config manuellement. Vérifiez que le fichier est mis en forme correctement.

Si vous utilisez un déploiement ZIP (par exemple, par le biais de Visual Studio Code), veillez à activer l’automatisation de génération. Elle n’est pas activée par défaut. az webapp up utilise le déploiement ZIP avec automatisation de génération activée.

Ignorer le message robots933456 dans les logs informatiques

Le message suivant peut s’afficher dans les journaux d’activité du conteneur :

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

Vous pouvez sans risque ignorer ce message. /robots933456.txt est un chemin d’URL factice. App Service l’utilise pour vérifier si le conteneur est capable de traiter les demandes. Une réponse d’erreur « 404 » indique que le chemin d’accès n’existe pas et signale à App Service que le conteneur est sain et prêt à répondre aux demandes.

Tutoriel : application Node.js avec MongoDB

Questions fréquentes (FAQ) sur Azure App Service sur Linux

Informations de référence sur les variables d’environnement et les paramètres d’application

Rétroaction

Cette page vous a-t-elle été utile ?

Last updated on 2025-11-02

Partager via

Configurer une application Node.js pour Azure App Service

Afficher la version Node.js

Définir la version Node.js

Que se passe-t-il pour les runtimes obsolètes dans App Service ?

Définir le numéro de port

Personnaliser l’automatisation de la génération

Configurer un serveur Node.js

Exécuter avec PM2

Exécuter avec une commande personnalisée

Exécuter avec npm start

Déboguer à distance

Accéder aux variables d’environnement

Exécuter Grunt/Bower/Gulp

Bower

Gulp

Grunt

Détecter une session HTTPS

Accéder aux journaux de diagnostic

Réécritures d’URL

Surveiller votre application en utilisant Application Insights

Dépannage

Vous n'êtes pas autorisé à voir ce répertoire ou cette page

Ignorer le message robots933456 dans les logs informatiques

Contenu connexe

Rétroaction

Ressources additionnelles