Partager via

Configurer une application PHP dans Azure App Service

Avertissement

PHP sur Windows a atteint la fin du support en novembre 2022. PHP est pris en charge uniquement pour App Service sur Linux. Cet article est destiné à des fins de référence uniquement.

Ce guide vous montre comment configurer vos applications web PHP, vos back-ends mobiles et vos applications API dans Azure App Service. Les tâches de configuration les plus courantes sont couvertes.

Si vous débutez avec App Service, vous devez d’abord suivre le guide de démarrage rapide Créer une application web PHP dans Azure App Service et déployer une application PHP, MySQL et Redis dans azure App Service .

Afficher la version PHP

Pour afficher la version actuelle de PHP, exécutez la commande suivante. Vous pouvez utiliser Azure Cloud Shell :

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

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

Remarque

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

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

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

Ce guide vous montre comment configurer vos applications web PHP, vos back-ends mobiles et vos applications API dans Azure App Service. Les tâches de configuration les plus courantes sont couvertes.

Si vous débutez avec App Service, vous devez d’abord suivre le guide de démarrage rapide Créer une application web PHP dans Azure App Service et déployer une application PHP, MySQL et Redis dans azure App Service .

Afficher la version PHP

Pour afficher la version actuelle de PHP, exécutez la commande suivante. Vous pouvez utiliser Azure Cloud Shell.

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

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

Remarque

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

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

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

Définir la version PHP

Pour définir la version PHP sur 8.1, exécutez la commande suivante :

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

Pour définir la version PHP sur 8.1, exécutez la commande suivante :

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

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

Les runtimes obsolètes sont déconseillés par l'organisation responsable de la maintenance ou présentent des vulnérabilités majeures. 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 l’interface de ligne de commande Azure, le modèle ARM ou Bicep. Ces alternatives de déploiement vous permettent de créer des environnements d'exécution déconseillés qui ont été retirés du portail, mais qui bénéficient encore d'un support.

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.

Exécuter Composer

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

À partir d’une fenêtre de terminal local, remplacez le répertoire par la racine de votre référentiel. Ensuite, suivez les instructions de Download Composer pour télécharger composer.phar vers la racine du répertoire.

Exécutez les commandes suivantes. Pour les exécuter, vous avez besoin de npm installé.

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

La racine de votre dépôt comporte désormais deux nouveaux fichiers : .deployment et deploy.sh.

Ouvrez deploy.sh et recherchez la section Deployment, qui ressemble à cet exemple :

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

À la fin de la Deployment section, ajoutez la section de code dont vous avez besoin pour exécuter l’outil requis :

# 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 à l’aide du déploiement ZIP avec l’automatisation de build activée. Composer doit maintenant s’exécuter dans le cadre de l’automatisation du déploiement.

Run Bower, Gulp ou Grunt

Si vous souhaitez qu’App Service exécute des outils d’automatisation populaires au moment du déploiement, tels que Bower, Gulp ou Grunt, vous devez fournir un script de déploiement personnalisé. App Service exécute ce script lorsque vous déployez à l’aide de Git ou à l’aide du déploiement ZIP avec l’automatisation de build activée.

Pour permettre à votre référentiel d’exécuter ces outils, vous devez les ajouter aux dépendances dans package.json. Par exemple:

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

À partir d’une fenêtre de terminal local, remplacez le répertoire par la racine de votre référentiel et exécutez les commandes suivantes. Pour les exécuter, vous avez besoin de npm installé.

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

La racine de votre dépôt comporte désormais deux nouveaux fichiers : .deployment et deploy.sh.

Ouvrez deploy.sh et recherchez la section Deployment, qui ressemble à cet exemple :

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

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

Consultez un exemple dans l’échantillon MEAN.js, où le script de déploiement exécute également une commande npm install personnalisée.

Charmille

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

Gorgée

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

Grogner

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 construction

Si vous déployez votre application à l’aide de Git ou en utilisant des packages ZIP avec l’automatisation de build activée, l’automatisation de build dans App Service effectue les étapes de la séquence suivante :

  1. Exécutez un script personnalisé si PRE_BUILD_SCRIPT_PATH le spécifie.
  2. Exécutez php composer.phar install.
  3. Exécutez un script personnalisé si POST_BUILD_SCRIPT_PATH le spécifie.

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

L’exemple suivant spécifie les deux variables à 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 d’autres variables d’environnement permettant de personnaliser l’automatisation de la génération, consultez Configuration d’Oryx.

Pour en savoir plus sur la façon dont App Service exécute et génère des applications PHP sous Linux, consultez la documentation Oryx sur la façon dont les applications PHP sont détectées et créées.

Personnaliser le démarrage

Vous pouvez exécuter une commande personnalisée au moment du démarrage du conteneur. Exécutez la commande suivante:

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 d’application en dehors de votre code d’application. Vous pouvez ensuite accéder à ces paramètres à 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 comme racine du site. Par exemple, Laravel utilise le public/ sous-répertoire comme 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 public/ sous-répertoire 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 de l’application virtuelle racine (/) vers le répertoire racine des fichiers d’application déployés (sites\wwwroot).

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

L’image PHP par défaut pour App Service utilise NGINX et vous modifiez la racine du site en configurant le serveur NGINX avec la root directive. Cet exemple de fichier de configuration contient l’extrait de code suivant qui modifie la root directive :

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 de configuration à l’adresse /etc/nginx/sites-available/default. Toute modification que vous apportez à ce fichier est effacée lorsque l’application redémarre. Pour apporter une modification efficace dans les redémarrages d’applications, ajoutez une commande de démarrage personnalisée comme cet exemple :

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

Cette commande remplace le fichier de configuration NGINX par défaut par un fichier nommé default à 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 demandes utilisateur sont chiffrées, 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, la fonction is_https() vérifie par défaut la valeur de X_FORWARDED_PROTO.

Personnaliser les paramètres php.ini

Si vous avez besoin d’apporter des modifications à votre installation PHP, vous pouvez modifier l’une des directivesphp.ini en procédant comme suit.

Remarque

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

Personnaliser les directives non-PHP_INI_SYSTEM

Pour personnaliser PHP_INI_USER, PHP_INI_PERDIRet PHP_INI_ALL directives, ajoutez un .user.ini fichier au répertoire racine de votre application.

Ajoutez des paramètres de configuration au .user.ini fichier à l’aide de la même syntaxe que celle utilisée dans un php.ini fichier. 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 contient ce texte :

 ; 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.

Au lieu d'utiliser un 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, telles que upload_max_filesize et expose_php, utilisez un fichier .ini personnalisé. Vous pouvez le créer dans une session SSH. Tout d’abord, configurez le répertoire :

  1. Accédez à votre site Kudu. Pour obtenir les valeurs de hachage et de région aléatoires, dans votre application Vue d’ensemble, copiez le domaine par défaut.
  2. Dans le menu supérieur, sélectionnez Déboguer la console, puis Bash ou SSH.
  3. Dans Bash ou SSH, accédez à votre /home/site/wwwroot répertoire.
  4. Créez un répertoire appelé ini (par exemple, mkdir ini).
  5. Remplacez le répertoire de travail actuel par le ini dossier que vous avez créé.

Ensuite, créez un fichier .ini dans lequel vous ajoutez vos paramètres. Cet exemple utilise extensions.ini. Il n’y a pas d’éditeurs de fichiers tels que Vi, Vim ou Nano, alors utilisez-le Echo pour ajouter les paramètres au fichier. Modifiez la valeur upload_max_filesize de 2M à 50M. Utilisez la commande suivante pour ajouter le paramètre et créer un extensions.ini fichier s’il n’existe pas encore :

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

Dans le Portail Azure, ajoutez un paramètre d’application pour analyser le répertoire ini que vous venez de créer pour appliquer la modification de upload_max_filesize :

  1. Accédez au portail Azure et sélectionnez votre application PHP Linux App Service.
  2. Accédez à paramètres>variables d’environnement.
  3. Sélectionnez + Ajouter.
  4. Pour Nom , entrez PHP_INI_SCAN_DIR et pour Valeur, entrez :/home/site/wwwroot/ini.
  5. Sélectionnez Appliquer, puis Appliquez à nouveau. Confirmez vos modifications.

Remarque

Si vous recompilez une extension PHP, telle que GD, suivez les étapes de recompilation des extensions PHP.

Personnaliser les directives PHP_INI_SYSTEM

Pour personnaliser les PHP_INI_SYSTEM directives, utilisez le paramètre d’application PHP_INI_SCAN_DIR .

Tout d’abord, exécutez la commande suivante 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"

Dans le portail Azure, sélectionnez votre application. Sous Outils de développement dans le menu latéral, sélectionnez Outils avancés, puis passez à l’utilisation de d:\home\site SSH.

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

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

Pour que les modifications prennent effet, redémarrez l’application.

Pour personnaliser les directives PHP_INI_SYSTEM, vous ne pouvez pas utiliser l’approche .htaccess. App Service fournit un mécanisme distinct qui utilise le paramètre d’application PHP_INI_SCAN_DIR .

Tout d’abord, exécutez la commande suivante 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"

La valeur /usr/local/etc/php/conf.d est le répertoire par défaut où php.ini il existe. La valeur /home/site/ini est le répertoire personnalisé dans lequel vous ajoutez un fichier .ini personnalisé. Vous séparez les valeurs par un signe deux-points (:).

Accédez à la session Web SSH avec votre conteneur Linux.

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

Conseil / Astuce

Les conteneurs Linux intégrés dans App Service sont utilisés /home comme 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

Pour que les modifications prennent effet, redémarrez l’application.

Activer les extensions PHP

Les installations PHP intégrées contiennent les extensions les plus couramment utilisées. Vous pouvez activer d’autres extensions de la même manière que vous personnalisez php.ini directives.

Remarque

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

Pour activer d’autres extensions, procédez comme suit :

  1. Ajoutez un bin répertoire 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 sur Azure, et qu’elles sont compatibles avec VC9 et non thread-safe (NTS).

  2. Déployez vos modifications.

  3. Suivez les étapes de la section Personnaliser les directives PHP_INI_SYSTEM et ajoutez les extensions dans le fichier .ini personnalisé avec l’extension ou la directive zend_extension :

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

Pour que les modifications prennent effet, redémarrez l’application.

Les installations PHP intégrées contiennent les extensions les plus couramment utilisées. Vous pouvez activer d’autres extensions de la même manière que vous personnalisez php.ini directives.

Remarque

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

Pour activer d’autres extensions, procédez comme suit :

  1. Ajoutez un bin répertoire 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 sur Azure, et qu’elles sont compatibles avec VC9 et non thread-safe (NTS).

  2. Déployez vos modifications.

  3. Suivez les étapes de la section Personnaliser les directives PHP_INI_SYSTEM et ajoutez les extensions dans le fichier .ini personnalisé avec l’extension ou la directive zend_extension :

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

Pour que les modifications prennent effet, redémarrez l’application.

Accéder aux journaux de diagnostic

Utilisez l’outil standard error_log() pour afficher vos journaux de diagnostic dans Azure App Service.

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 console générés depuis le 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 <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 de journaux à tout moment, sélectionnez Ctrl+C.

Résolution des problèmes

Lorsqu’une application PHP opérationnelle se comporte différemment dans App Service ou présente des erreurs, essayez les solutions suivantes :

  • Accédez au flux de journaux de diagnostic.
  • Testez l’application localement en mode de production. App Service exécute votre application en mode de production. Vous devez donc vous assurer que votre projet fonctionne comme prévu en mode de production localement. Par exemple:
    • Selon le fichier composer.json, différents packages peuvent être installés pour le mode de production (require contre 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.
  • Exécutez votre application dans App Service en mode débogage. Par exemple, dans Laravel, vous pouvez configurer votre application pour générer des messages de débogage en production en définissant le APP_DEBUG paramètre trued’application sur .

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 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 et qu’il signale à App Service que le conteneur est sain et prêt à répondre aux demandes.

Contenu connexe