Déploiement Laravel avec Docker : pourquoi un conteneur "healthy" ne suffit pas

Un conteneur Docker "healthy" ne garantit pas que votre application répond. Dans un déploiement Laravel avec Docker, il faut une sonde de readiness, un test de disponibilité qui interroge l'application comme le ferait un visiteur, avant de lui confier le trafic.

Que s'est-il passé dans ce déploiement Laravel avec Docker ?

Une équipe a raconté son cas sur dev.to. Elle déploie en blue-green : deux copies de l'application coexistent, et le trafic passe de l'ancienne à la nouvelle une fois celle-ci validée.

Ce jour-là, la copie "blue" démarre, Nginx (le serveur web) accepte sa configuration, Docker la déclare saine. La bascule s'arrête pourtant. La sonde envoyait le nom du service Docker comme nom de domaine, et l'équipe venait de durcir la validation de ces noms dans Laravel, qui a refusé celui-là. L'ancienne version est restée en ligne, puisque la sonde passe avant la bascule.

Pourquoi "healthy" prouve si peu

Selon ce récit, le healthcheck du conteneur PHP-FPM, le programme qui exécute le PHP derrière Nginx, vérifie la configuration et l'ouverture d'un port local. Aucune requête ne traverse Nginx jusqu'à Laravel. La readiness, elle, appelle une page /health via le conteneur web candidat et exige un code 200 avec un JSON "status":"ok".

Le correctif tient en une ligne : même destination, mais avec le nom de domaine réel de l'application. Surtout pas d'ajout des noms Docker à la liste autorisée. On n'affaiblit pas une protection pour faire passer un test, et l'auteur garde d'ailleurs un test qui doit échouer avec un nom non autorisé. Il reconnaît aussi qu'un /health réussi ne couvre ni la connexion, ni la commande, ni les files d'attente.

Base, cache et files : dans quelle sonde ?

Laravel Cloud distingue trois sondes : au démarrage, de readiness (le trafic est coupé, sans redémarrage) et de liveness (un échec redémarre l'instance). Sa documentation déconseille d'y mettre la base ou le cache : une base lente ferait redémarrer toutes les instances en boucle.

Notre position est la même. Base et cache vont dans la readiness, qui sert de barrière avant bascule et jamais de déclencheur de redémarrage. Laravel 11 fournit la route /up, et l'événement DiagnosingHealth permet d'y ajouter ces contrôles, comme l'explique la documentation de serversideup. Pour les files, la même documentation précise que ses scripts prouvent que le processus tourne, pas qu'il traite des tâches. Notre checklist des queues aide à aller plus loin.

Est-ce pour votre PME ?

Pas toujours. Un site vitrine ou un petit outil interne, hébergé classiquement et déployé par git pull, n'a rien à gagner à monter Docker et deux versions en parallèle : la complexité dépasse le bénéfice.

Cela change quand l'application porte l'activité. Prenons le portail de commande d'un de nos clients fabricants : l'important n'est pas qu'il réponde, mais que la commande arrive en facturation et chez le logisticien. Plus l'application est branchée à d'autres outils, plus une sonde honnête se justifie. Autre précaution : les migrations de base doivent rester compatibles avec les deux versions.

Côté coût, curl, Nginx et Docker sont gratuits ; reste le temps de mise en place, sans prix fiable à citer. Nous accompagnons des entreprises d'Aix-en-Provence et de Provence, pour une application sur mesure comme pour son hébergement et maintenance.

Questions fréquentes