Déploiement PHP sans interruption : guide zero-downtime

Quand une seconde d'arrêt coûte des millions

Imaginez : vous mettez à jour votre boutique en ligne PHP, vous téléchargez une nouvelle version via FTP, et soudain le site plante pendant 5 minutes. Cinq minutes, c'est 300 secondes. Pendant ce temps, 100 clients potentiels filent chez vos concurrents, et vous perdez non seulement de l'argent, mais aussi votre réputation. Ça vous parle ?

Dans le monde moderne, où les utilisateurs ne pardonnent pas les erreurs, le déploiement zero-downtime de services PHP n'est plus un luxe, mais une nécessité. Mais comment réaliser un déploiement sans couture quand votre stack est PHP, Nginx et plusieurs serveurs ? Voyons cela avec des exemples concrets.

Pourquoi PHP est-il plus complexe qu'il n'y paraît ?

Contrairement à Node.js ou Python, PHP ne supporte pas le multithreading au sens classique. Chaque requête est traitée par un processus PHP-FPM distinct. Cela impose des contraintes : vous ne pouvez pas simplement « recharger » le code sans perdre les sessions en cours. Cependant, cette même particularité nous donne un super-pouvoir : la possibilité de basculer progressivement le trafic entre les versions.

Les principaux problèmes lors du déploiement PHP :

\n
• Coupures de connexion — l'utilisateur perd les données d'un formulaire ou sa session
\n
• Cache obsolète — l'ancien code renvoie des données d'un cache périmé
\n
• Migrations cassées — la nouvelle version de la BDD n'est pas compatible avec l'ancien code
\n

Pour éviter ces pièges, utilisons des stratégies éprouvées. Et oui, le déploiement zero-downtime n'est pas de la magie, mais un plan bien défini.

Stratégie n°1 : Blue-Green Deployment

La méthode la plus fiable consiste à maintenir deux copies complètes de l'application : la « bleue » (actuelle) et la « verte » (nouvelle). Nginx agit comme répartiteur de charge.

Comment ça se passe concrètement

Supposons que vous ayez deux serveurs : app1.example.com (blue) et app2.example.com (green). Les deux exécutent PHP-FPM. Actuellement, blue est actif. Vous déployez la nouvelle version sur green, vous la testez, puis vous basculez Nginx sur green.

Exemple de configuration Nginx pour le basculement :

# nginx.conf\nupstream php_backend {\n    # D'abord blue actif\n    server app1.example.com:9000 weight=1;  # blue\n    server app2.example.com:9000 weight=0;  # green (désactivé)\n}\n\nserver {\n    listen 80;\n    server_name maboutique.com;\n\n    location ~ \\.php$ {\n        fastcgi_pass php_backend;\n        include fastcgi_params;\n        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;\n    }\n}\n

Après le déploiement sur green, on modifie les poids :

# Après déploiement — basculement du trafic\nupstream php_backend {\n    server app1.example.com:9000 weight=0;  # blue (désactivé)\n    server app2.example.com:9000 weight=1;  # green (actif)\n}\n

On recharge Nginx sans interruption : nginx -s reload. Toutes les connexions en cours se terminent proprement, et les nouvelles vont vers green. Déploiement zero-downtime PHP assuré !

Avantages et inconvénients

Avantages : haute disponibilité totale, possibilité de revenir en arrière rapidement (il suffit de rétablir les poids).
\nInconvénients : nécessite deux fois plus de ressources (serveurs ou conteneurs).

Stratégie n°2 : Rolling Update (mise à jour progressive)

Si votre budget est limité, utilisez le rolling update. L'idée : mettre à jour les serveurs PHP un par un, sans désactiver les autres. Les utilisateurs ne remarquent aucune interruption, car Nginx redirige les requêtes vers les serveurs actifs.

Implémentation avec PHP-FPM

Supposons que vous ayez 3 serveurs avec PHP-FPM. On les retire un à un de la rotation, on met à jour le code, puis on les réintègre.

Étape 1 : Retirer le serveur du répartiteur de charge (graceful shutdown) :

# Sur le serveur à mettre à jour\nsudo systemctl stop php8.1-fpm\n# Nginx arrêtera automatiquement d'envoyer des requêtes à ce serveur, car il est indisponible\n

Étape 2 : Mettre à jour le code (via git pull, rsync ou Docker).

Étape 3 : Redémarrer PHP-FPM :

sudo