Configurer une application PHP pour Azure App Service

Article
08/31/2023

Afficher la version PHP

Avertissement

PHP sur Windows été retiré en novembre 2022 et n’est pris en charge que sur App Service sur Linux. Cet article est destiné à des fins de référence uniquement..

Ce guide vous explique comment configurer les applications web PHP, les back-ends mobiles et les applications API dans Azure App Service.

Ce guide fournit les concepts et instructions clés aux développeurs PHP qui déploient des applications sur App Service. Si vous n’avez jamais utilisé Azure App Service, commencez par suivre le démarrage rapide PHP et le tutoriel PHP avec MySQL.

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

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

Notes

Pour adresser un emplacement de développement, incluez le paramètre --slot suivi du nom de l’emplacement.

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

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

Ce guide vous explique comment configurer les applications web PHP, les back-ends mobiles et les applications API dans Azure App Service.

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

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

Notes

Pour adresser un emplacement de développement, incluez le paramètre --slot suivi du nom de l’emplacement.

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

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

Définir la version PHP

Exécutez la commande suivante dans Cloud Shell pour définir la version 8.1 de PHP :

az webapp config set --resource-group <resource-group-name> --name <app-name> --php-version 8.1

Exécutez la commande suivante dans Cloud Shell pour définir la version 8.1 de PHP :

az webapp config set --resource-group <resource-group-name> --name <app-name> --linux-fx-version "PHP|8.1"

Exécuter Composer

Si vous souhaitez qu’App Service exécute Composer au moment du déploiement, le moyen le plus simple consiste à inclure le Composer dans votre référentiel.

Dans une fenêtre de terminal local, accédez à la racine de votre référentiel, puis suivez les instructions de Télécharger Composer pour télécharger composer.phar à la racine du répertoire.

Exécutez les commandes suivantes (npm doit être installé) :

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
# ----------

Ajoutez la section de code dont vous avez besoin pour exécuter l’outil requis à la fin de la section Deployment :

# 4. Use composer
echo "$DEPLOYMENT_TARGET"
if [ -e "$DEPLOYMENT_TARGET/composer.json" ]; then
  echo "Found composer.json"
  pushd "$DEPLOYMENT_TARGET"
  php composer.phar install $COMPOSER_ARGS
  exitWithMessageOnError "Composer install failed"
  popd
fi

Validez toutes vos modifications et déployez votre code à l’aide de Git ou de Zip deploy avec l’automatisation de build activée. Composer doit maintenant s’exécuter dans le cadre de l’automatisation du déploiement.

Exécuter Grunt/Bower/Gulp

Si vous souhaitez qu’App Service exécute certains outils d’automatisation populaires au moment du déploiement, par exemple Grunt, Bower ou Gulp, vous devez fournir un script de déploiement personnalisé. App Service exécute ce script lorsque vous déployez avec Git, ou avec le déploiement Zip avec l’automatisation de build activée.

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 doit être installé) :

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
# ----------

Cette section se termine par l’exécution de npm install --production. Ajoutez la section de code dont vous avez besoin pour exécuter l’outil requis à la fin de la section Deployment :

Bower
Gulp
Grunt

Consultez un exemple dans l’échantillon MEAN.js, où 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

Personnaliser l’automatisation de la génération

Si vous déployez votre application à l’aide de Git ou de packages zip avec l’automatisation de build activée, l’automatisation de build d’App Service suit la séquence suivante :

Exécution du script personnalisé s’il est spécifié par PRE_BUILD_SCRIPT_PATH.
Exécutez php composer.phar install.
Exécution du script personnalisé s’il est spécifié par POST_BUILD_SCRIPT_PATH.

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 définit les deux variables sur une série de commandes, 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 connaître les autres variables d’environnement permettant de personnaliser l’automatisation de la génération, consultez Configuration d’Oryx.

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

Personnaliser le démarrage

Si vous le souhaitez, vous pouvez exécuter une commande personnalisée au moment du démarrage du conteneur, en exécutant la commande suivante dans Cloud Shell :

az webapp config set --resource-group <resource-group-name> --name <app-name> --startup-file "<custom-command>"

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 à l’aide du modèle standard getenv(). Par exemple, pour accéder à un paramètre d’application nommé DB_HOST, utilisez le code suivant :

getenv("DB_HOST")

Modifier la racine du site

L’infrastructure web de votre choix peut utiliser un sous-répertoire en tant que racine du site. Par exemple, Laravel utilise le sous-répertoire public/ en tant que racine du site.

Pour personnaliser la racine du site, définissez le chemin d’accès de l’application virtuelle pour l’application à l’aide de la commande az resource update. L’exemple suivant définit la racine du site sur le sous-répertoire public/ de votre référentiel.

az resource update --name web --resource-group <group-name> --namespace Microsoft.Web --resource-type config --parent sites/<app-name> --set properties.virtualApplications[0].physicalPath="site\wwwroot\public" --api-version 2015-06-01

Par défaut, Azure App Service pointe le chemin d’accès à l’application virtuelle ( / ) vers le répertoire racine des fichiers d’application déployés (/).

L’infrastructure web de votre choix peut utiliser un sous-répertoire en tant que racine du site. Par exemple, Laravel utilise le sous-répertoire public/ en tant que racine du site.

L’image PHP par défaut pour App Service utilise Nginx et la racine du site se modifie en configurant le serveur Nginx avec la directive root. Cet exemple de fichier config contient les extraits de code suivants qui modifient la directive root :

server {
    #proxy_cache cache;
    #proxy_cache_valid 200 1s;
    listen 8080;
    listen [::]:8080;
    root /home/site/wwwroot/public; # Changed for Laravel

    location / {            
        index  index.php index.html index.htm hostingstart.html;
        try_files $uri $uri/ /index.php?$args; # Changed for Laravel
    }
    ...

Le conteneur par défaut utilise le fichier config qui se trouve dans /etc/nginx/sites-available/default. N’oubliez pas que toute modification que vous apportez à ce fichier est effacée lorsque l’application redémarre. Pour apporter une modification valable entre les redémarrages de l’application, ajoutez une commande de démarrage personnalisée comme dans cet exemple :

cp /home/site/wwwroot/default /etc/nginx/sites-available/default && service nginx reload

Cette commande remplace le fichier config Nginx par défaut par un fichier nommé par défaut à la racine de votre référentiel et redémarre Nginx.

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 requêtes utilisateur sont chiffrées ou non, inspectez l’en-tête X-Forwarded-Proto.

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
// Do something when HTTPS is used
}

Les frameworks web populaires vous permettent d’accéder aux informations X-Forwarded-* dans votre modèle d’application standard. Dans CodeIgniter, is_https() vérifie la valeur de X_FORWARDED_PROTO par défaut.

Personnaliser les paramètres php.ini

S'il vous faut apporter des modifications à votre installation PHP, vous pouvez modifier les directives php.ini en suivant ces étapes.

Notes

La meilleure façon de consulter la version de PHP et la configuration actuelle de php.ini consiste à appeler phpinfo() dans votre application.

Directives Customize-non-PHP_INI_SYSTEM

Pour personnaliser les directives PHP_INI_USER, PHP_INI_PERDIR et PHP_INI_ALL (consultez les directives php.ini), ajoutez un fichier .user.ini au répertoire racine de votre application.

Ajoutez des paramètres de configuration au fichier .user.ini en utilisant la même syntaxe que pour le fichier php.ini. Par exemple, si vous souhaitez activer le paramètre display_errors et régler le paramètre upload_max_filesize sur 10M, votre fichier .user.ini doit contenir le texte suivant :

 ; Example Settings
 display_errors=On
 upload_max_filesize=10M

 ; Write errors to d:\home\LogFiles\php_errors.log
 ; log_errors=On

Redéployez votre application avec les modifications et redémarrez-la.

En guise d’alternative au fichier .user.ini, vous pouvez utiliser ini_set() dans votre application pour personnaliser ces directives non-PHP_INI_SYSTEM.

Pour personnaliser les directives PHP_INI_USER, PHP_INI_PERDIR, et PHP_INI_ALL pour les applications web Linux, comme upload_max_filesize et expose_php, utilisez un fichier « ini » personnalisé. Vous pouvez le créer dans une session SSH.

Accédez à votre site KUDU https://<sitename>.scm.azurewebsites.net.
Sélectionnez Bash ou SSH dans le menu supérieur.
Dans Bash/SSH, accédez à votre répertoire « /home/site/wwwroot ».
Créez un répertoire appelé « ini » (par exemple, mkdir ini).
Remplacez le répertoire de travail actuel par le dossier « ini » que vous venez de créer.

Vous devez créer un fichier « ini » auquel ajouter vos paramètres. Dans cet exemple, nous utilisons « extensions.ini ». Il n’existe pas d’éditeurs de fichiers tels que Vi, Vim ou Nano. Vous allez donc utiliser écho pour ajouter les paramètres au fichier. Remplacez la valeur « upload_max_filesize » de 2 Mo par 50 Mo. Utilisez la commande suivante pour ajouter le paramètre, puis créez un fichier « extensions.ini » s’il n’en existe pas déjà un.

/home/site/wwwroot/ini>echo "upload_max_filesize=50M" >> extensions.ini
/home/site/wwwroot/ini>cat extensions.ini

upload_max_filesize=50M

/home/site/wwwroot/ini>

Ensuite, accédez au portail Azure et ajoutez un paramètre d’application pour analyser le répertoire « ini » que vous venez de créer afin d’appliquer la modification pour upload_max_filesize.

Accédez au portail Azure et sélectionnez votre application App Service Linux PHP.
Sélectionnez Paramètres de l’application pour l’application.
Dans la section Paramètres de l’application, sélectionnez + Ajouter un nouveau paramètre.
Pour Nom du paramètre d’application, entrez « PHP_INI_SCAN_DIR » et, pour la valeur, entrez « /home/site/wwwroot/ini ».
Sélectionnez le bouton Enregistrer.

Notes

Si vous avez recompilé une extension PHP, telle que GD, suivez les étapes décrites dans Recompilation des extensions PHP à Azure App Service - Ajout d’extensions PHP

Personnaliser les directives PHP_INI_SYSTEM

Pour personnaliser les directives PHP_INI_SYSTEM (consultez les directives php.ini), utilisez le paramètre d’application PHP_INI_SCAN_DIR.

Commencez par exécuter la commande suivante dans Cloud Shell pour ajouter un paramètre d'application appelé PHP_INI_SCAN_DIR :

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings PHP_INI_SCAN_DIR="d:\home\site\ini"

Accédez à la console Kudu (https://<app-name>.scm.azurewebsites.net/DebugConsole) et accédez à d:\home\site.

Créez un répertoire dans d:\home\site appelé ini, puis créez un fichier .ini dans le répertoire d:\home\site\ini (par exemple, settings.ini) avec les directives que vous souhaitez personnaliser. Utilisez la même syntaxe que pour un fichier php.ini.

Par exemple, pour modifier la valeur de expose_php, exécutez les commandes suivantes :

cd /home/site
mkdir ini
echo "expose_php = Off" >> ini/setting.ini

Redémarrez l'application pour que les modifications soient prises en compte.

Pour personnaliser les directives PHP_INI_SYSTEM (consultez les directives php.ini), vous ne pouvez pas utiliser l'approche .htaccess. App Service propose un mécanisme distinct utilisant le paramètre d’application PHP_INI_SCAN_DIR.

Commencez par exécuter la commande suivante dans Cloud Shell pour ajouter un paramètre d'application appelé PHP_INI_SCAN_DIR :

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings PHP_INI_SCAN_DIR="/usr/local/etc/php/conf.d:/home/site/ini"

/usr/local/etc/php/conf.d correspond au répertoire par défaut dans lequel se trouve php.ini. /home/site/ini correspond au répertoire personnalisé dans lequel vous ajouterez un fichier .ini personnalisé. Séparez les valeurs par :.

Accédez à la session SSH web avec votre conteneur Linux (https://<app-name>.scm.azurewebsites.net/webssh/host).

Créez un répertoire dans /home/site appelé ini, puis créez un fichier .ini dans le répertoire /home/site/ini (par exemple, settings.ini) avec les directives que vous souhaitez personnaliser. Utilisez la même syntaxe que pour un fichier php.ini.

Conseil

Dans les conteneurs Linux intégrés dans App Service, /home est utilisé en tant que stockage partagé persistant.

Par exemple, pour modifier la valeur de expose_php, exécutez les commandes suivantes :

cd /home/site
mkdir ini
echo "expose_php = Off" >> ini/setting.ini

Redémarrez l'application pour que les modifications soient prises en compte.

Activer les extensions PHP

Les installations PHP intégrées contiennent les extensions les plus fréquemment utilisées. Vous pouvez activer des extensions supplémentaires de la même manière que vous personnalisez les directives php.ini.

Notes

La meilleure façon de consulter la version de PHP et la configuration actuelle de php.ini consiste à appeler phpinfo() dans votre application.

Pour activer des extensions supplémentaires, effectuez les étapes suivantes :

Ajoutez un répertoire bin au répertoire racine de votre application et placez-y les fichiers d’extension .dll (par exemple mongodb.dll). Assurez-vous que les extensions sont compatibles avec la version de PHP dans Azure, ainsi qu'avec VC9 et NTS (Non-Thread Safe).

Déployez vos modifications.

Suivez les étapes décrites dans Personnaliser les directives PHP_INI_SYSTEM, ajoutez les extensions au fichier .ini personnalisé avec l'extension ou les directives zend_extension.

extension=d:\home\site\wwwroot\bin\mongodb.dll
zend_extension=d:\home\site\wwwroot\bin\xdebug.dll

Redémarrez l'application pour que les modifications soient prises en compte.

Notes

La meilleure façon de consulter la version de PHP et la configuration actuelle de php.ini consiste à appeler phpinfo() dans votre application.

Pour activer des extensions supplémentaires, effectuez les étapes suivantes :

Ajoutez un répertoire bin au répertoire racine de votre application et placez-y les fichiers d'extension .so (par exemple, mongodb.so). Assurez-vous que les extensions sont compatibles avec la version de PHP dans Azure, ainsi qu'avec VC9 et NTS (Non-Thread Safe).

Déployez vos modifications.

Suivez les étapes décrites dans Personnaliser les directives PHP_INI_SYSTEM, ajoutez les extensions au fichier .ini personnalisé avec l'extension ou les directives zend_extension.

extension=/home/site/wwwroot/bin/mongodb.so
zend_extension=/home/site/wwwroot/bin/xdebug.so

Redémarrez l'application pour que les modifications soient prises en compte.

Accéder aux journaux de diagnostic

Utilisez l’utilitaire standard error_log () pour faire apparaître vos journaux de diagnostic dans Azure App Service.

Pour accéder aux journaux de la console générés à l’intérieur 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 comprend uniquement les messages d’erreur et Verbose comprend tous les messages.

Une fois la journalisation des diagnostics activée, exécutez la commande suivante pour voir le flux de journal :

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

Si vous ne voyez pas les journaux d’activité de la console, attendez 30 secondes et vérifiez à nouveau.

Notes

Vous pouvez également inspecter les fichiers journaux à partir du navigateur sur https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Pour arrêter le streaming des journaux à tout moment, appuyez sur Ctrl+C.

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

Activez d’abord la journalisation du conteneur en exécutant la commande suivante :

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

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

Une fois la journalisation du conteneur activée, exécutez la commande suivante pour voir le flux de journal :

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

Si vous ne voyez pas les journaux d’activité de la console, attendez 30 secondes et vérifiez à nouveau.

Pour arrêter le streaming de journaux à tout moment, appuyez sur Ctrl+C.

Vous pouvez également inspecter les fichiers journaux dans un navigateur sur https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Dépannage

Si une application PHP se comporte différemment dans App Service ou présente des erreurs, essayez ce qui suit :

Accéder au flux de journaux.
Testez l’application localement en mode de production. App Service exécute votre application en mode de production et dès lors, vous devez vous assurer que votre projet fonctionne comme prévu en mode de production localement. Par exemple :
- Selon votre fichier composer.json, différents packages peuvent être installés pour le mode de production (require et require-dev).
- 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.
Dans App Service, exécutez votre application en mode de débogage. Par exemple, dans Laravel, vous pouvez configurer votre application de manière à envoyer les messages de débogage en production en définissant le paramètre d'application APP_DEBUG sur true.

robots933456 dans les journaux

Le message suivant peut s'afficher dans les journaux 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 utilisé par App Service pour vérifier si le conteneur est capable de traiter des requêtes. Une réponse 404 indique que le chemin d’accès n’existe pas, mais informe App Service que le conteneur est intègre et prêt à répondre aux requêtes.

Étapes suivantes

Tutoriel : Application PHP avec MySQL

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

Ou bien, consultez les ressources supplémentaires :

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

Partager via

Configurer une application PHP pour Azure App Service

Afficher la version PHP

Définir la version PHP

Exécuter Composer

Exécuter Grunt/Bower/Gulp

Bower

Gulp

Grunt

Personnaliser l’automatisation de la génération

Personnaliser le démarrage

Accéder aux variables d’environnement

Modifier la racine du site

Détecter une session HTTPS

Personnaliser les paramètres php.ini

Directives Customize-non-PHP_INI_SYSTEM

Personnaliser les directives PHP_INI_SYSTEM

Activer les extensions PHP

Accéder aux journaux de diagnostic

Dépannage

robots933456 dans les journaux

Étapes suivantes

Commentaires

Ressources supplémentaires