Nginx PHPVoici notre quatrième article dans la série sur Nginx. Notre précédent article traitait de l’hébergement de plusieurs sites statiques sur une même machine. Aujourd’hui nous allons aborder l’hébergement de pages dynamiques.

Héberger des pages dynamiques

Pour commencer, je crée un hôte php.slackbox.fr dans ma configuration DNS. Les pages de cet hôte seront hébergées sous l’arborescence /var/www/php-site/html.

$ cd /var/www/
$ sudo mkdir -pv php-site/html
mkdir: created directory ‘php-site’
mkdir: created directory ‘php-site/html’
$ sudo chown -R microlinux:microlinux php-site/
$ cd php-site/html/

Je crée un fichier index.php à la racine de ce site et je l’édite comme ceci.

<?php
  phpinfo();
?>

La prochaine étape consiste à installer PHP ainsi que le service PHP-FPM. J’opte pour la version 7.2 fournie par les dépôts tiers SCLo (Red Hat Software Collections). J’ai détaillé l’installation de PHP 7.2 sous CentOS 7 dans cet article.

Pour les besoins de notre atelier pratique, je me contente d’installer le minimum syndical requis.

$ sudo yum install rh-php72 rh-php72-php-fpm

J’active et je démarre le service PHP-FPM.

$ sudo systemctl enable rh-php72-php-fpm --now

Je vérifie s’il tourne correctement.

$ systemctl status rh-php72-php-fpm

Je crée un fichier /etc/nginx/conf.d/php.slackbox.fr.conf pour configurer mon hébergement.

# /etc/nginx/conf.d/php.slackbox.fr.conf
server {
  listen 80;
  server_name php.slackbox.fr;
  root /var/www/php-site/html;
  access_log /var/log/nginx/php.slackbox.fr-access.log;
  error_log  /var/log/nginx/php.slackbox.fr-error.log;
  try_files $uri $uri/ =404;
  location ~ \.php$ {
    try_files $uri =404;
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
  }
}

Cette configuration mérite quelques remarques.

  • Le contexte location concerne tous les fichiers qui se terminent par *.php. Le caractère tilde ~ indique ici que nous utilisons les expressions régulières.
  • Nginx n’est pas capable d’interpréter directement les pages PHP comme le ferait Apache avec mod_php. Au lieu de cela, il agit comme proxy inverse (reverse proxy) et passe les requêtes en question à PHP-FPM grâce à la directive fastcgi_pass.
  • La directive include prend en compte le fichier /etc/nginx/fastcgi_params.
  • Les détails inquiétants autour des paramètres FastCGI sont expliqués dans cet article. Si vous ne comprenez pas tout, cela ne vous empêchera pas de vivre.

Il ne nous reste plus qu’à ajouter index.php à la liste des index dans /etc/nginx/nginx.conf.

# /etc/nginx/nginx.conf
user nginx;
worker_processes auto;
events {
  worker_connections 1024;
}
http {
 include mime.types;
 include conf.d/*.conf;
 index index.php index.htm index.html;
 server {
   listen 80 default_server;
   server_name sd-100246.dedibox.fr;
   root /usr/share/nginx/html;
   access_log /var/log/nginx/sd-100246.dedibox.fr-access.log;
   error_log  /var/log/nginx/sd-100246.dedibox.fr-error.log;
   try_files $uri $uri/ =404;
 }
}

Je teste et je recharge la configuration.

$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
$ sudo systemctl reload nginx

Si tout s’est bien passé, les infos PHP s’affichent comme ceci.

Nginx PHP

Unix Domain Socket

Dans la configuration par défaut, PHP-FPM écoute sur un socket réseau, mais il peut également utiliser un socket local (Unix Domain Socket), ce qui peut améliorer sensiblement les performances.

Pour la version de PHP-FPM fournie par les Red Hat Software Collections que nous utilisons ici, la configuration se trouve dans l’arborescence /etc/opt/rh/rh-php72, dans le répertoire php-fpm.d. Ouvrir le fichier www.conf et repérer les directives suivantes.

user = apache
group = apache
listen = 127.0.0.1:9000
...
;listen.owner = nobody
;listen.group = nobody
;listen.mode = 0660

Modifier la configuration comme ceci.

user = nginx
group = nginx
listen = /var/run/php-fpm.sock
listen.owner = nginx
listen.group = nginx
listen.mode = 0660

Dans la configuration de Nginx, le socket local pourra être configuré comme ceci.

# /etc/nginx/conf.d/php.slackbox.fr.conf
server {
  listen 80;
  server_name php.slackbox.fr;
  root /var/www/slackbox-php/html;
  access_log /var/log/nginx/php.slackbox.fr-access.log;
  error_log  /var/log/nginx/php.slackbox.fr-error.log;
  try_files $uri $uri/ =404;
  location ~ \.php$ {
    try_files $uri =404;
    fastcgi_pass unix:/var/run/php-fpm.sock;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
  }
}

Relancer les deux services pour prendre en compte les modifications.

$ sudo systemctl restart rh-php72-php-fpm nginx

La suite au prochain numéro, où nous allons nous intéresser à la configuration d’un site sécurisé

Post Scriptum 1er janvier 2020 : J’ai ajouté une section sur l’utilisation d’un socket local pour la communication entre Nginx et PHP-FPM. Merci à l’utilisateur bazooka07 pour ses suggestions.


La rédaction de cette documentation demande du temps et des quantités significatives de café espresso. Vous appréciez ce blog ? Offrez un café au rédacteur en cliquant sur la tasse.

 


15 commentaires

Rémi Suinot · 31 décembre 2019 à 11 h 25 min

Bonjour.
Je lis avec beaucoup d’attention votre série sur nginx.
J’y apprend quelques trucs, merci.
La, sur php-fpm, il y a un souci qui me gène :
Vous modifiez les uid/gui des fichiers, au début, pour les mettre à ‘microlinux’. Cela ne me gène pas, sauf que php est a priori paramétré pour fonctionner ainsi que les fichiers qu’il exécuté, avec souvent « www » voir « www-data » (après, ça dépend certe du numéro qu’il y a derrière, ce n’est pas le même sous devient et sous alpine linux).
Bref, avez vous modifié le fichier de conf de php-fpm?
Cordialement.
R. Suinot.

    kikinovak · 31 décembre 2019 à 14 h 34 min

    Non, je n’ai rien modifié à php-fpm.conf. Mon utilisateur « commun mortel » c’est microlinux. Contrairement à ce que l’on voit un peu partout sur les blogs, ce n’est pas une bonne idée d’attribuer les fichiers hébergés au processus qui fait tourner le serveur web… sauf bien évidemment lorsque celui-ci doit avoir des droits d’écriture sur le contenu. Et attention, les fichiers *.php ne sont pas « exécutés ». Le terme peut facilement induire en erreur.

bazooka07 · 31 décembre 2019 à 11 h 57 min

Pourquoi passer par le réseau pour dialoguer avec le serveur PHP-FPM alors qu’il y a un socket unix plus rapide (paramètre fastcgi_pass)

Tu as un exemple de config Nginx pour un célèbre CMS avec ce lien :
https://wiki.pluxml.org/installer/nginx/

    kikinovak · 31 décembre 2019 à 14 h 31 min

    Merci pour la suggestion. J’en prends note dans un coin de ma tête, et j’en parlerai un peu plus tard, dans un article sur le peaufinage des performances.

    remi suinot · 31 décembre 2019 à 20 h 58 min

    bonsoir,
    je suis d’accord sur l’utilisation des sockets pour php-fpm, mais ce n’est pas interdit non plus. Le cas ou il est « utile » de passer par le réseau: lorsque vous êtes contenerisé (ça se dit?) : chaque processus dans son réseau et on passe que par là pour discuter.

    Pour les uid/guid, je n’avais pas envisagé le cas des « scripts » n’écrivent pas dans les répertoires…..
    Et effectivement, j’ai toujours mis +x pour les fichiers php, mais ça sert à rien!

    kikinovak · 1 janvier 2020 à 13 h 51 min

    @bazooka07 : j’ai répondu à votre suggestion, et j’ai ajouté une section « Unix Domain Socket » à l’article.

bazooka07 · 1 janvier 2020 à 1 h 10 min

C’est tellement gros que je ne l’avais pas remarqué. le fichier index.php n’a pas besoin de « echo ». Il se réduit à cette simple libre :

Et comme cela produit beaucoup d’information dquand on deboggue, je préfère cette variante :

    bazooka07 · 1 janvier 2020 à 1 h 12 min

    <?php phpinfo(); ?>
    ou encore
    <?php phpinfo(INFO_VARIABLES); ?>

      kikinovak · 1 janvier 2020 à 13 h 52 min

      Corrigé, merci.

Johnny · 3 janvier 2020 à 1 h 33 min

Avec le nginx et les page php.. Pour avoir un site sécurisé et requis maintenant, est-ce uniquement via des certificat séparé (.pem) que ce sera possible ? J’essai simplement de configurer un Owncloud avec nginx et ssl. Merci encore

    kikinovak · 3 janvier 2020 à 8 h 45 min

    Dans mon tout premier article dans la série sur Nginx, j’annonce ma démarche (« Un peu de méthodologie »). Je traiterai Nginx et OwnCloud en temps et en heure. La rédaction de ces articles nécessite pas mal de temps, et je ne peux les faire lorsque je suis disponible.

    Chat échaudé craint la charrue avant la peau de l’ours.

      Johnny · 3 janvier 2020 à 15 h 57 min

      Oh d’accord, je n’étais pas certain. Merci grandement, cela permet de comprendre centos et les configuration. Très apprécié et je vais lire avec intérêt vos prochaine publications.

Filovitch · 9 janvier 2020 à 13 h 54 min

Merci pour vos articles. J’aime beaucoup cette méthodologie progressive.

Le paquet rh-php72 a comme dépendance le paquet httpd. Ne serait-ce pas plus judicieux de s’en passer et d’installer uniquement php-fpm, php-common et php-cli dans le cas d’une utilisation avec nginx?

    kikinovak · 9 janvier 2020 à 14 h 28 min

    Sur mes machines, les paquets rh-php72* ne dépendent nullement de httpd, contrairement aux paquets php* inclus d’office dans la distribution.

      Filovitch · 9 janvier 2020 à 20 h 36 min

      En effet, j’ai confondu avec le paquet rh-php72-php qui lui dépend bien de httpd.

Répondre à Rémi Suinot Annuler la réponse

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.