"post-install-cmd": [
    "bin/console cache:clear --env=prod",
    "bin/console doctrine:migrations:migrate --no-interaction"
]

post-install-cmd s’exécute pendant composer install, qui dans le Dockerfile de production tourne au moment du build de l’image. Il n’y a pas de base de données disponible pendant un build Docker. La commande de migration échouait silencieusement, se connectait à rien, ou était ignorée par Doctrine faute de schéma à comparer. Dans tous les cas, elle ne migrait rien.

C’est une violation nette du Facteur XII : les processus d’administration — migrations, scripts ponctuels, commandes console — doivent s’exécuter dans le même environnement que l’application, contre les vraies données de production. Les faire tourner au build inverse la relation. L’image ne devrait pas savoir qu’il y a une base de données. La base devrait être là quand l’image en a besoin.

Le déplacement vers l’entrypoint

La commande de migration a quitté composer.json pour docker-entrypoint.sh. Le changement semble petit dans un diff. Les implications ne le sont pas.

L’entrypoint s’exécute quand le container démarre, pas quand l’image est construite. La base de données est accessible. L’entrypoint l’attend — jusqu’à 60 secondes, une tentative par seconde — avant de faire quoi que ce soit :

ATTEMPTS_LEFT_TO_REACH_DATABASE=60
until [ $ATTEMPTS_LEFT_TO_REACH_DATABASE -eq 0 ] || \
  DATABASE_ERROR=$(php bin/console dbal:run-sql -q "SELECT 1" 2>&1); do
    sleep 1
    ATTEMPTS_LEFT_TO_REACH_DATABASE=$((ATTEMPTS_LEFT_TO_REACH_DATABASE - 1))
done

if [ $ATTEMPTS_LEFT_TO_REACH_DATABASE -eq 0 ]; then
    echo "$DATABASE_ERROR"
    exit 1
fi

Si la base ne répond pas dans les 60 secondes, le container sort en erreur et Kubernetes le redémarre. Une fois la base prête, la migration tourne :

if [ "$( find ./migrations -iname '*.php' -print -quit )" ]; then
    php bin/console doctrine:migrations:migrate --no-interaction --all-or-nothing
fi

Deux changements par rapport à la commande d’origine : --all-or-nothing garantit que si une migration dans un batch échoue, le batch entier est annulé. Et le guard find passe la commande si aucun fichier de migration n’existe — utile pour les services qui n’utilisent pas les migrations Doctrine.

C’est franchement mieux. La base est là. La migration tourne dans le vrai environnement. Le flag --all-or-nothing apporte une atomicité que la version au build n’avait jamais eue.

Ce que ça ne résout pas

Deux pods qui redéploient simultanément exécutent tous les deux l’entrypoint. Tous les deux atteignent la base. Tous les deux trouvent des migrations en attente. Tous les deux appellent doctrine:migrations:migrate.

Doctrine a un mécanisme de verrouillage : une table doctrine_migration_versions qui enregistre quelles migrations ont tourné, et la commande la consulte avant d’appliquer quoi que ce soit. Dans les conditions normales c’est suffisant : le deuxième pod trouve la table à jour et sort proprement. Les cas de défaillance réels sont plus précis : une migration assez longue pour dépasser le timeout du verrou de base de données, ce qui laisse un deuxième runner démarrer la même migration avant que le premier ait terminé ; ou un pod qui se vautre à mi-migration avant d’avoir enregistré la version dans la table, laissant le schéma dans un état appliqué-mais-non-enregistré que le pod suivant va tenter d’appliquer à nouveau.

La position de l’équipe est explicite : un downtime léger au déploiement est acceptable. Les versions d’application ne sont pas nécessairement compatibles avec des versions de schéma plus anciennes, donc faire tourner N et N+1 simultanément contre la même base ne serait de toute façon pas sûr. La stratégie de déploiement est Recreate : tous les anciens pods sont terminés avant que les nouveaux ne démarrent. La migration tourne au premier démarrage, sans chevauchement entre les versions. Ça fonctionne.

Mais “ça fonctionne” et “c’est la bonne architecture” sont deux réponses différentes.

Ce que feraient les alternatives

Le Facteur XII dit que les processus d’administration doivent tourner dans des “processus ponctuels”. Un processus qui tourne une fois, dans un but précis, contre l’environnement de production. L’entrypoint n’est pas ponctuel — il tourne à chaque démarrage de container, y compris les redémarrages, les événements de scaling, et les déplacements de pods par Kubernetes.

Trois alternatives existent, chacune avec une réponse différente à la question de la propriété :

Un init container Kubernetes tourne avant le container principal, dans le même pod. Il peut exécuter la migration, sortir, et laisser le container principal démarrer seulement après son succès. La migration est isolée du runtime applicatif. Le problème : l’init container est une image supplémentaire à construire et maintenir, et il tourne à chaque démarrage de pod — une plateforme de 14 services démarrant simultanément a toujours une race potentielle.

Un Kubernetes Job tourne une fois, à la demande ou déclenché par le pipeline de déploiement. Il peut être configuré pour s’exécuter avant la mise à jour des pods — séquentiel, isolé, avec un signal clair de succès ou d’échec. La race condition disparaît. La complexité se déplace vers le processus de déploiement : le Job doit se terminer avant que le rollout du Deployment commence, et le pipeline CI doit coordonner les deux.

Un hook Helm est le même concept exprimé de façon déclarative dans le chart Helm. Un hook pre-upgrade exécute la migration avant la mise à jour des pods applicatifs. C’est la réponse la plus idiomatique pour Kubernetes. Ça signifie aussi que le chart Helm est désormais responsable de l’exécution des migrations — une décision qui appartient à qui possède le chart.

Cette dernière phrase explique pourquoi l’entrypoint n’a pas changé. Déplacer les migrations hors de l’application signifie décider que l’infrastructure de déploiement — pas l’application elle-même — est responsable du schéma. C’est une question de gouvernance autant que de technique, et les questions de gouvernance prennent plus de temps à résoudre que les changements de code.

La fin honnête

Le bloc de migration dans l’entrypoint, c’est deux lignes. Littéralement : le guard if [ "$( find ./migrations... )" ], et le php bin/console doctrine:migrations:migrate qui suit. Onze autres facteurs ont des résolutions nettes. Le cache est passé sur Redis. Les logs vont vers stdout. Le système de fichiers est un bucket S3. Le CI assemble les images de production depuis le même commit qu’il teste. Les secrets ne voyagent plus dans les layers d’image.

Le Facteur XII a une réponse. Ce n’est juste pas la réponse finale.

Les migrations tournent au démarrage, avec une vraie base de données, avec atomicité, avec une fenêtre de retry bornée. C’est mieux que de tourner au build contre rien. La question de savoir si elles finiront dans un Job ou un hook Helm est une conversation sur qui possède le schéma — une question à laquelle un kubectl apply ne peut pas répondre.

Pendant les quarante secondes suivantes — sur les soixante possibles — ce container était en train de poller la base de données.

Les requêtes qui atterrissaient dessus pendant cette fenêtre récoltaient des erreurs. Pas beaucoup — la fenêtre était courte — mais assez pour apparaître comme du bruit dans le monitoring. Le genre de bruit qu’on classe comme « problème réseau transitoire » et qu’on ne signale nulle part. Le déploiement a réussi. Le pod a fini par devenir prêt. Le mécanisme qui en était la cause était toujours là, attendant le prochain déploiement.

Le script d’entrypoint fait cinq choses avant que FrankenPHP démarre : copier un fichier de version, vérifier le répertoire vendor, attendre jusqu’à soixante secondes la base de données, jouer les migrations en attente, installer les assets et configurer les permissions filesystem. Sous Docker Compose, c’est invisible. Sur Kubernetes, l’écart devient du trafic en erreur.

L’écart entre démarré et prêt

Kubernetes décide d’envoyer du trafic à un pod en surveillant sa readiness probe. Un pod dont la readiness probe passe reçoit des requêtes. Un pod dont la readiness probe échoue est retiré de la rotation du load balancer jusqu’à ce qu’il récupère. C’est le mécanisme qui rend les rolling deploys sûrs : Kubernetes ne bascule pas vers un nouveau pod tant que ce pod n’indique pas qu’il est prêt.

Le compose.yaml définit un healthcheck sur chaque service :

healthcheck:
    test: [ "CMD", "php", "-v" ]
    interval: 30s
    timeout: 10s
    retries: 3
    start_period: 10s

php -v réussit dès que le binaire PHP est présent — ce qui est vrai depuis la première milliseconde de vie du container. Le start_period: 10s donne dix secondes avant que les vérifications commencent. Mais la boucle de polling de l’entrypoint tourne jusqu’à soixante secondes avant que FrankenPHP démarre. À la dixième seconde, le healthcheck passe. L’application attend toujours la base de données.

Le Dockerfile a un meilleur signal :

HEALTHCHECK --start-period=60s CMD curl -f http://localhost:2019/metrics || exit 1

Le port 2019 est le serveur de métriques intégré à Caddy, embarqué directement dans FrankenPHP. L’endpoint est compatible Prometheus et ne répond qu’une fois que la stack HTTP de Caddy est pleinement initialisée et que les workers PHP acceptent des connexions. php -v se termine en cinquante millisecondes quel que soit l’état de l’application — il vérifie le binaire, pas le serveur. :2019/metrics ne répond que quand le serveur sert vraiment. Ce n’est pas non plus un endpoint ajouté exprès pour la probe : chaque service de la plateforme l’a déjà scraped par Prometheus, donc le signal est actif indépendamment de toute configuration de healthcheck.

C’est plus proche. Mais sur Kubernetes, l’instruction HEALTHCHECK du Dockerfile est totalement ignorée. Kubernetes utilise sa propre configuration de probes. Sans définitions de probes explicites dans les manifests Kubernetes, il n’y a aucune vérification de readiness — et un pod est considéré prêt dès que son container démarre.

Ce qui signifie : le pod démarre, l’entrypoint commence à poller, Kubernetes route du trafic, l’application n’est pas encore en état de le traiter. Les requêtes arrivent sur un container qui n’est pas prêt à les gérer.

Trois signaux, trois questions

Kubernetes sépare le cycle de vie d’un container en trois questions distinctes, chacune avec son propre type de probe :

startupProbe — « L’application a-t-elle fini de démarrer ? » Se déclenche à répétition jusqu’à ce qu’elle passe, puis passe la main à la liveness. Empêche la liveness probe de tuer un container qui est légitimement long à initialiser. Pour un container dont l’entrypoint peut prendre soixante secondes, c’est l’outil adapté.

readinessProbe — « L’application est-elle prête à traiter des requêtes ? » Échoue et passe tout au long de la vie du container. Quand elle échoue, le pod est retiré du load balancer. C’est ce qui rend un rolling deploy sûr.

livenessProbe — « L’application est-elle toujours vivante ? » Si elle échoue, Kubernetes redémarre le container. Conçue pour détecter les processus bloqués, pas les démarrages lents.

La boucle de polling de soixante secondes appartient à la patience de la startupProbe, pas au code applicatif :

startupProbe:
    httpGet:
        path: /metrics
        port: 2019
    failureThreshold: 12    # 12 tentatives × 5s = 60s max
    periodSeconds: 5

Une fois la startupProbe passée, une readinessProbe sur le même endpoint prend le relais — indiquant à Kubernetes quand le pod peut recevoir du trafic — et une livenessProbe surveille les processus bloqués. Mais c’est la startupProbe qui absorbe le démarrage lent. La boucle de polling de l’entrypoint devient redondante : son rôle était de maintenir le container en vie pendant que la base de données devenait disponible. Sans elle, l’application tente de se connecter, échoue, et le container quitte — Kubernetes redémarre alors le pod, et la startupProbe maintient son cycle de tentatives jusqu’à ce que la base réponde et que l’application démarre proprement. La responsabilité du retry passe de l’intérieur de l’entrypoint à l’orchestrateur, ce qui est exactement là où elle devrait être.

Le problème des migrations

La boucle de polling est le problème le plus visible, mais les migrations en créent un plus subtil.

Avec un rolling deploy et deux replicas, Kubernetes démarre un nouveau pod pendant que l’ancien sert encore du trafic. Les deux pods jouent le même entrypoint. Les deux atteignent doctrine:migrations:migrate.

La table de migrations de Doctrine trace quelles migrations ont déjà été exécutées, donc une migration complétée ne se jouera pas deux fois. Mais si deux pods démarrent simultanément et voient tous les deux une migration en attente, les deux tentent de la jouer en même temps. Si c’est sûr ou non dépend de la migration : les changements de schéma additifs passent en général bien ; les destructifs moins. Et on ne choisit pas lesquels s’exécutent lors d’un déploiement qui n’a pas prévu de se coordonner. --all-or-nothing enveloppe les migrations dans une transaction et fait un rollback si l’une échoue — c’est une question d’atomicité au sein d’une seule exécution, pas de coordination entre processus.

L’approche plus propre sépare ces deux préoccupations en deux init containers : l’un qui attend la base de données, l’autre qui joue les migrations. Le container principal ne démarre qu’une fois les deux terminés :

initContainers:
    - name: wait-for-db
      image: authentication:latest
      command: ["php", "bin/console", "dbal:run-sql", "-q", "SELECT 1"]
    - name: migrate
      image: authentication:latest
      command: ["php", "bin/console", "doctrine:migrations:migrate", "--no-interaction", "--all-or-nothing"]

Les deux init containers réutilisent la même image que l’application. Ce n’est pas du gaspillage : ils ont besoin du même binaire PHP et du même câblage d’environnement pour atteindre la base de données et trouver les classes de migration. Une image dédiée plus légère réduirait le temps de démarrage, mais nécessiterait de maintenir une installation PHP séparée en synchronisation avec l’image principale.

Même avec des init containers, plusieurs pods démarrant simultanément — déploiement initial, après une défaillance de nœud, ou sous pression d’autoscaling — tenteront chacun de jouer les migrations. Le résoudre proprement — via un hook pre-upgrade Helm, une stratégie maxSurge: 0, ou un Job de migration séparé — est un sujet en soi. Ce qui compte ici, c’est que l’entrypoint est le mauvais endroit pour prendre cette décision : il ne peut pas se coordonner entre pods, et il lie l’exécution des migrations au démarrage de l’application d’une façon difficile à démêler plus tard. La question de quelle alternative convient à cette codebase — et pourquoi l’entrypoint n’a pas encore été remplacé — fait l’objet de l’article suivant dans cette série .

Le Facteur XII de la méthodologie twelve-factor — les processus d’administration tournent dans le même environnement que l’application — est respecté dans les deux cas. La question est de savoir si « même environnement » signifie « même script d’entrypoint » ou « même image, processus séparé ». Sur Kubernetes, le second est plus sûr.

La vraie responsabilité de l’entrypoint

Enlever l’attente de la base de données (maintenant une startupProbe ou un init container), les migrations (maintenant un init container ou un Job), et l’installation des assets (une opération de build-time qui appartient au Dockerfile), et l’entrypoint n’a plus qu’une seule responsabilité : démarrer l’application.

exec docker-php-entrypoint "$@"

Le Facteur IX de la twelve-factor app demande un démarrage rapide et un arrêt propre. Un container dont le démarrage prend soixante secondes parce qu’il attend des dépendances externes n’est pas rapide. Ça signifie des rolling deploys lents, une reprise après crash lente, et un scale-out horizontal qui crée une fenêtre de soixante secondes avant que chaque nouveau pod contribue.

Le démarrage rapide n’est pas juste un confort. C’est ce qui fait fonctionner le reste du modèle cloud. Quand un pod peut démarrer en secondes, l’orchestrateur peut scaler agressivement et récupérer vite. Quand ça prend une minute, on ajoute des marges partout — timeouts de probes plus longs, fenêtres de déploiement plus larges, politiques de scaling plus conservatrices — et le système devient rigide.

La taxe Docker Compose

L’entrypoint accumule ces responsabilités pour une raison. Sous Docker Compose, il n’y a pas de concept d’init container. Pas de startupProbe. Les services déclarent depends_on, mais sans conditions de santé, c’est juste de l’ordre de démarrage — pas de la readiness. L’entrypoint comble le vide.

Ce n’est pas un défaut de conception. C’est une adaptation raisonnable aux contraintes de Docker Compose. Le script fonctionne. Il gère les cas limites (le timeout de la base, les erreurs irrécupérables, le répertoire de migrations absent). Quelqu’un l’a testé.

Le problème, c’est l’hypothèse que le même script fonctionne aussi bien sur Kubernetes. Il tourne. L’application finit par démarrer. Mais il contourne le système de probes qui rend les déploiements Kubernetes fiables, et il place la responsabilité des migrations à un endroit où la coordination entre pods est difficile à raisonner.

Plusieurs des changements de cette série — stockage des médias , secrets dans les images , handlers de logs , dépendances de services , parité d’environnement CI , adaptateurs de cache — étaient des changements au code applicatif ou à la configuration. Celui-ci est différent. Il demande à l’infrastructure de comprendre ce que « prêt » signifie pour cette application, et il demande à l’entrypoint de céder des responsabilités qu’il détient actuellement.

C’est une conversation plus difficile. Mais la startupProbe attend.

Puis quelqu’un a remarqué que le rate limiter se comportait bizarrement. Cinq appels à l’API, accès bloqué. Cinq appels supplémentaires à la requête suivante, accès accordé. Selon quel pod répondait, on était une personne différente.

C’était le cache qui parlait. Une ligne de config, répliquée sur treize services, bloquait le scaling horizontal dans sa totalité.

Un fichier de config, treize fois

On préparait une plateforme de treize microservices Symfony pour passer sur Kubernetes. La stack était déjà en bon état : FrankenPHP pour le serveur HTTP, des Dockerfiles multi-étapes, un GitLab CI qui poussait des images taguées vers un registre cloud. Les pièces étaient là. Il fallait juste vérifier que rien ne casserait quand on commencerait à scaler les pods horizontalement.

Une bonne checklist pour ce type d’audit, c’est la méthodologie twelve-factor app — douze principes pour construire des logiciels qui tournent proprement dans des environnements cloud. La plupart des facteurs étaient déjà couverts sans qu’on y ait pensé délibérément.

Le Facteur VII (port binding) était gratuit. FrankenPHP embarque Caddy directement dans le processus PHP. Le container expose son propre endpoint HTTP, sans Apache ni Nginx à ajouter. L’image est autonome, ce que le facteur demande exactement :

HEALTHCHECK --start-period=60s CMD curl -f http://localhost:2019/metrics || exit 1

Le Facteur II (dépendances) était géré par composer.json et les extensions du Dockerfile. Le Facteur X (parité dev/prod) était suffisamment couvert pour notre périmètre : même image, mêmes backing services en local et en CI, ce qui est la partie qui compte vraiment pour l’audit.

Puis j’en suis arrivé au Facteur VI.

Le problème avec « ça marche sur un seul serveur »

Le Facteur VI dit que les processus ne doivent rien partager. Rien d’écrit sur disque entre les requêtes, rien en mémoire locale qu’une autre instance ne puisse pas voir. Si on a besoin de persister de l’état, on le met dans un backing service — une base de données, un cluster de cache, une queue. Le processus lui-même reste jetable.

J’ai ouvert authentication/config/packages/cache.yaml. Puis content/config/packages/cache.yaml. Puis media/config/packages/cache.yaml.

framework:
    cache:
        app: cache.adapter.filesystem

Treize services. Treize fois, mot pour mot.

Chaque instance de chaque service écrivait son cache sur le filesystem local. Ce qui signifiait que chaque pod avait son propre cache privé, invisible pour tous les autres pods. Quand le load balancer envoyait une requête au pod A, il obtenait la version mise en cache par le pod A. Le pod B avait construit la sienne. Elles pouvaient avoir été générées à des moments différents, depuis des données sources différentes, ou l’une d’elles pouvait ne pas encore avoir été construite du tout.

Le rate limiter était le symptôme le plus visible parce qu’il avait un compteur. Mais la même divergence affectait chaque donnée qu’on mettait en cache : métadonnées du sérialiseur, collections de routes, caches de résultats Doctrine. Deux utilisateurs envoyant des requêtes identiques pouvaient obtenir des réponses différentes selon quel nœud avait récupéré la connexion.

Redis était déjà là

C’est la partie qui pique un peu. Redis était déjà dans la stack. Chaque service l’avait configuré via SncRedisBundle :

# config/packages/snc_redis.yaml — présent sur les 13 services
snc_redis:
    clients:
        default:
            type: 'phpredis'
            alias: 'default'
            dsn: '%env(IN_MEM_STORE__URI)%'

Le Facteur IV de la twelve-factor app dit que les backing services doivent être des ressources attachées, interchangeables via la configuration. Redis était exactement ça : joignable via une variable d’environnement, prêt à être remplacé par une instance managée dans le cloud. La plomberie était faite. On ne s’en servait juste pas pour le cache applicatif.

Certains services l’avaient même juste pour des pools spécifiques. Le rate limiter dans le service d’authentification :

pools:
    rate_limiter.cache:
        adapter: cache.adapter.redis

Ce qui explique l’incohérence qu’on a vue en premier. Le compteur du rate limit allait vers Redis (partagé entre les pods). Le cache qui alimentait la vérification du rate limit allait vers le filesystem (local au pod). Deux sources de vérité, l’une invisible à l’autre.

La correction tenait en une ligne par service :

framework:
    cache:
        app: cache.adapter.redis
        default_redis_provider: snc_redis.default

Treize fichiers. Treize changements identiques. Le genre de correction qui donne l’impression qu’on aurait dû la repérer avant, sauf qu’elle est parfaitement invisible quand on tourne sur une seule instance.

Ce qui doit migrer vers Redis

Le cache filesystem violait le Facteur VI (les processus portent de l’état local qu’ils ne devraient pas) et le Facteur VIII (on ne peut pas scaler sans partager cet état). C’est le même problème vu sous deux angles : VI décrit ce qui ne va pas, VIII décrit ce qu’on ne peut pas faire à cause de ça.

Avec un backend de cache partagé, un deuxième pod est sûr. Les deux pods construisent le même cache, voient les mêmes invalidations, s’accordent sur les mêmes limites de rate. On peut ajouter un troisième pod sous charge et le retirer quand le trafic baisse. L’orchestrateur s’en occupe ; l’application n’a pas besoin de le savoir.

Sans ça, le scaling horizontal est un risque. Plus de pods, c’est plus de divergence, plus de bugs « ça marche chez moi » qu’il est impossible de reproduire en local parce qu’en local on tourne avec un seul container.

Les sessions avaient le même problème — et potentiellement pire. Douze des treize services utilisaient session.storage.factory.native — qui écrit les sessions sur le filesystem par défaut. Un utilisateur dont la requête atterrit sur le pod A obtient une session liée au pod A. Sa requête suivante va sur le pod B. Session perdue, il est déconnecté. Un seul service avait RedisSessionHandler configuré.

La mitigation partielle : la plupart de la plateforme tourne sur des APIs stateless avec des JWT, donc l’usage des sessions est limité. Mais « limité » n’est pas « zéro ». Les services qui créent des sessions — flows d’authentification, état temporaire pendant les handshakes OAuth — ont un mode de défaillance visible par l’utilisateur qui attend le deuxième pod. Soit ces sessions migrent vers Redis, soit le code qui les crée est supprimé. Les laisser en l’état est une décision qui attend le premier utilisateur dont la session disparaît sans explication.

L’autre genre d’état

Redis résout le problème cross-pod. FrankenPHP introduit un autre problème qu’il vaut la peine de connaître.

Dans le modèle PHP-FPM standard, chaque requête forke un processus frais. Tout objet en mémoire — toute valeur mise en cache, tout résultat calculé — meurt avec la réponse. Le processus est stateless par construction.

FrankenPHP a un mode worker qui ne suit pas ce modèle. En mode worker, un seul processus PHP démarre une fois, charge le kernel, câble le container, et gère plusieurs requêtes successives sans redémarrer. Le débit de requêtes s’améliore : pas de cold start de l’autoloader, pas de rebuild du container par requête, moins d’allocations. La contrepartie : le processus PHP a maintenant un cycle de vie qui enjambe les requêtes.

Pour le cache, ça ajoute une complexité. Un adaptateur array ou un pool APCu accumule des entrées à travers les requêtes sur le même worker. Une invalidation de cache poussée vers Redis atteint immédiatement les autres pods — mais ne vide pas ce qui est assis dans la mémoire du worker. Deux requêtes sur le même pod peuvent voir des choses différentes : l’une touche une entrée en mémoire chaude, la suivante déclenche un fetch Redis après expiration de l’entrée in-process.

La plateforme garde le mode worker désactivé (APP__WORKER_MODE__ENABLED=false). Il est disponible — l’infrastructure est là, le flag est câblé — mais pas actif. Le gain de performance ne justifiait pas l’audit. Chaque pool de cache aurait besoin d’être vérifié contre la sémantique du mode worker ; chaque endroit où de l’état fuit entre les requêtes deviendrait un bug potentiel.

La position conservatrice : garder PHP stateless au niveau du processus même quand le runtime ne l’exige pas. Le principe shared-nothing du Facteur VI s’applique non seulement au filesystem — il s’applique au processus lui-même.

Ce qui fonctionnait déjà

Pour être juste envers la codebase : le Scheduler Symfony utilisait déjà Redis pour les locks distribués :

$schedule->lock($this->lockFactory->createLock('schedule_purge'));

Dans un environnement multi-pod, on ne veut pas cinq instances lancer le même job de purge simultanément. Le lock l’empêche. Redis rend le lock visible entre les pods. Celui qui a écrit le scheduler savait exactement ce qu’il faisait.

Le même raisonnement ne s’était juste pas propagé à la configuration du cache — probablement parce qu’en tournant sur une seule instance, cache.adapter.filesystem est invisible. Ça fonctionne, c’est rapide, ça ne demande aucune configuration. Le problème n’apparaît qu’à deux.

Les quatre questions

Le Facteur VI prend la plupart des applications par surprise lors d’une migration cloud. Pas parce que les développeurs ne connaissent pas les processus stateless — ils le savent généralement — mais parce que le filesystem est toujours là, et le problème reste caché jusqu’à ce qu’on essaie de lancer une deuxième instance.

Avant de scaler un service Symfony horizontalement, quatre questions méritent une réponse :

• Où va le cache applicatif ? (cache.adapter.filesystem doit devenir cache.adapter.redis)
• Où vont les sessions ? (session.storage.factory.native a besoin de Redis — ou supprimer les sessions entièrement si on est full JWT)
• Est-ce que quelque chose écrit dans var/ à l’exécution qu’un autre pod aurait besoin de lire ?
• Est-ce qu’il y a quelque chose dans le chemin de code qui doit être mutuellement exclusif entre pods ? (si oui, c’est un job pour le composant Lock de Symfony adossé à Redis, pas un mutex local)

Si toutes les réponses pointent vers des backing services partagés, on est prêt. Si l’une d’elles pointe vers le filesystem local, la production finira par trouver le pod qui a construit son cache il y a trois heures et le servira à l’utilisateur qui s’y attend le moins.

stages:
  - build
  - provision
  - phpunit
  - phpmetrics
  - behat
  - deprovision
  - deploy

Avant que la première assertion s’exécute, quinze minutes s’étaient écoulées. Terraform avait cloné un dépôt d’infrastructure, s’était authentifié sur Azure, avait appliqué une configuration de VM. Ansible s’était connecté à la nouvelle VM, avait installé PHP, configuré l’application, câblé une base de données et une instance Redis. Ensuite les tests tournaient. Ensuite Terraform détruisait ce qu’Ansible avait construit.

Pour chaque pipeline. Depuis chaque branche. Pour chaque pull request, de l’ouverture au merge.

Ce que ces quinze minutes ne contenaient pas

Le stage provision mettait en place deux services : PostgreSQL et Redis. Trois services dont l’application dépendait en production étaient absents : RabbitMQ, MinIO et Varnish.

RabbitMQ traitait tout le travail asynchrone — 56 consumers sur 14 microservices. MinIO gérait le stockage de médias. Varnish était devant le cache HTTP. En CI, aucun d’eux n’existait. Les tests qui couvraient les files de messages ou le stockage de fichiers avaient deux options : ignorer ces chemins, ou les laisser non testés jusqu’au staging. Varnish est un cas à part : les tests tapent directement dans l’application et contournent intentionnellement la couche de cache, son absence en CI est donc un choix délibéré plutôt qu’un manque.

C’est le problème que le Facteur X décrit comme l’écart d’environnement. L’écart ici n’était pas une question de configuration — il était structurel. La VM était construite par Ansible depuis un script dans un dépôt séparé. Ce n’était pas une image de container. Elle n’était pas versionnée aux côtés de l’application. Si une branche modifiait la topologie de messages RabbitMQ, il n’y avait aucun moyen de tester cette modification en CI. Le changement de topologie et le code qui en dépendait ne se rencontreraient qu’en staging.

Le script de provisioning Ansible lui-même fait partie du problème :

launch_vm:
  stage: provision
  script:
    - git clone git@gitlab.internal/infra/ci-vm.git
    - cd ci-vm
    - az login --service-principal -u $ARM_CLIENT_ID ...
    - terraform apply -var "prefix=${CI_PIPELINE_ID}-vm" ...
    - sleep 45
    - ansible-playbook behat/test-env.yml ...

Le sleep 45 est là parce qu’Ansible a besoin que la VM finisse de booter avant de pouvoir s’y connecter. Ce n’est pas un oubli — c’est le délai minimum qu’une VM fraîchement provisionnée nécessite avant que SSH fonctionne. C’est inscrit dans le processus.

Ce qui l’a remplacé

Le nouveau pipeline n’a pas de stage provision. Il n’a pas de stage deprovision. L’environnement, ce sont les images, et les images existent avant que les tests commencent.

Chaque job de test déclare ses dépendances comme des services Docker :

services:
  - name: $REGISTRY_URL/platform/rabbitmq:$CI_COMMIT_REF_SLUG
    alias: rabbitmq
  - name: $REGISTRY_URL/platform/minio:$CI_COMMIT_REF_SLUG
    alias: minio
  - name: redis:7.4.1
    alias: redis
  - name: $ARTIFACTORY_URL/postgresql:13
    alias: postgresql

Les services démarrent en parallèle quand le job commence. Avant que le script de test tourne, un before_script attend qu’ils soient tous prêts :

before_script:
  - $CI_PROJECT_DIR/dockerize
      -wait tcp://postgresql:5432
      -wait tcp://rabbitmq:5672
      -wait tcp://minio:9000
      -wait tcp://redis:6379
      -timeout 120s

Du démarrage du pipeline à la première assertion : quatre-vingt-dix secondes — en supposant que les images sont déjà dans le cache du runner ; un cold pull rallonge les choses, mais devient négligeable une fois que le pipeline a tourné une fois sur une branche donnée.

Ce que signifie $CI_COMMIT_REF_SLUG

Le timing est le résultat visible. Ce qui le produit est plus intéressant encore : les noms des images.

$REGISTRY_URL/platform/rabbitmq:$CI_COMMIT_REF_SLUG n’est pas l’image officielle RabbitMQ de Docker Hub. C’est une image construite par le même pipeline, depuis la même branche, au même commit que le code testé. L’image RabbitMQ embarque la topologie : un definitions.json avec chaque exchange, chaque queue, chaque binding, chaque configuration de dead-letter — versionné dans git aux côtés de l’application qui en dépend.

Si une branche modifie la topologie de messages, le pipeline CI construit une nouvelle image RabbitMQ qui inclut ces modifications, puis exécute les tests contre elle. Le changement de topologie et le code qui en dépend sont testés ensemble, au même commit, avant que quoi que ce soit n’atteigne le staging.

La même logique s’applique à MinIO, décrite dans le premier article de cette série : l’image MinIO embarque des fixtures de test préchargées. L’environnement CI n’a pas besoin d’une étape de setup pour peupler le stockage. L’état est intégré à l’artefact.

Le runner de tests lui-même suit le même pattern. Chaque job utilise une variante debug de l’image applicative — construite depuis la même branche, au même commit — avec les dépendances de test incluses :

image: $REGISTRY_URL/platform/$service:$CI_COMMIT_REF_SLUG-debug

Tout l’environnement s’assemble depuis des artefacts construits au même point de l’historique git.

Ce que ça a demandé d’abandonner

Behat et la VM provisionnée étaient couplés. La suite de tests Behat tournait contre un serveur HTTP sur la VM ; supprimer la VM signifiait supprimer Behat.

Ça s’est révélé moins bloquant que ça n’en avait l’air. La suite Behat vivait dans un dépôt séparé, nécessitait la VM pour tourner, et avait accumulé une charge de maintenance significative. PHPUnit, tournant dans le container applicatif avec les services Docker, couvrait les mêmes scénarios par un chemin plus direct : tests fonctionnels qui exercent la couche HTTP, tests unitaires pour les composants individuels, suites organisées par domaine fonctionnel et générées dynamiquement en jobs CI parallèles.

La couche BDD a disparu. La couverture de tests est restée — et pouvait désormais tourner contre les vrais services.

Le Facteur X, appliqué

Le Facteur X se lit souvent comme “utilise la même base de données en local qu’en production.” C’est la version la plus simple. La version plus profonde concerne l’écart entre ce qu’on teste et ce qu’on livre.

L’écart dans l’ancien pipeline était large : une VM configurée manuellement, privée de services clés, reconstruite de zéro à chaque run. L’écart dans le nouveau pipeline est étroit : le CI assemble l’environnement depuis les mêmes images que la production, construites au même commit que le code sous test.

Les quinze minutes de Terraform et Ansible n’étaient pas seulement lentes. Elles construisaient quelque chose qui n’était pas ce que la production faisait tourner, à chaque fois, avant que le moindre test puisse commencer. Les quatre-vingt-dix secondes de docker pull construisent exactement ce que la production fait tourner — et les tests qui suivent testent ça, pas une approximation.

APP__GATEWAY__PRIVATE__HOST="platform.internal"
APP__GATEWAY__PRIVATE__PORT=80
APP__GATEWAY__PRIVATE__SCHEME="http"
APP__GATEWAY__PUBLIC__HOST="platform.internal"
APP__GATEWAY__PUBLIC__PORT=80
APP__GATEWAY__PUBLIC__SCHEME="http"

Treize services, six variables chacun, une seule valeur. En lisant la config d’un service quelconque, l’architecture semblait plate. Tout parlait au même hôte. C’était tout le tableau.

Ce ne l’était pas.

Comment fonctionnait la gateway

La gateway se trouvait devant chaque service et gérait tout le trafic inter-services. Un service appelant l’API content construisait une requête vers http://platform.internal/content/api/ — la gateway la recevait, identifiait la cible depuis le chemin de l’URL, et la transmettait au bon backend. Chaque client HTTP inter-service dans framework.yaml suivait le même schéma :

content.client:
    base_uri: "%http_client.gateway.base_uri%/content/api/"
    headers:
        Host: "%env(APP__GATEWAY__PRIVATE__HOST)%"

Le paramètre http_client.gateway.base_uri était assemblé depuis les variables GATEWAY. La gateway savait où tournait chaque service. Les services n’avaient pas besoin de le savoir. De leur point de vue, tout était platform.internal.

Ça fonctionnait. Pendant des années, ça fonctionnait bien. Ajouter un service signifiait ajouter un alias DNS dans la config de la gateway, pas toucher treize fichiers .env. La gateway abstraisait la topologie. Les services restaient découplés du détail d’infrastructure de qui tournait où.

Ce que la gateway absorbait

L’abstraction avait un coût qui n’apparaissait pas tant qu’on n’essayait pas de lire le système.

En regardant le fichier env de content, on voyait six variables de gateway et rien d’autre sur la communication inter-services. Pour découvrir que content appelait conversion, shorty et media, il fallait lire framework.yaml. Pour découvrir que pilot appelait dix services externes, il fallait tracer les clients HTTP un par un et compter.

Le chiffre était dix. Authentication, bam, config, content, conversion, media, product, shorty, sitemap, social. Dix des treize services de la plateforme dont pilot dépendait à l’exécution, aucun d’eux visible depuis sa configuration. Six variables disaient : parle à la gateway. Elles ne disaient rien de la forme de ce qui se trouvait derrière.

Cette information existait — dans le code, dans la config framework, dans les têtes des gens qui avaient construit ces intégrations. Elle ne vivait juste nulle part où on pouvait la lire d’un coup d’œil.

Ce que Kubernetes a rendu explicite

On-premise, la gateway était un seul hostname résolvable. Un enregistrement DNS, un jeu de variables, un seul endroit à mettre à jour. Kubernetes ne fonctionne pas comme ça. Chaque service obtient son propre nom DNS à l’intérieur du cluster — content.namespace.svc.cluster.local, conversion.namespace.svc.cluster.local. Le trafic inter-services passe directement, service à service, sans gateway partagée.

Passer à Kubernetes signifiait que l’abstraction de la gateway devait céder la place. Chaque service devait savoir, concrètement, où vivait chacune de ses dépendances. Les six variables génériques ne pouvaient pas exprimer ça.

Le refacto les a remplacées par des variables HOST par cible — une par dépendance de service, nommée d’après la cible :

# content/.env — content appelle ces quatre services
APP__CONFIG__HOST="platform.internal"
APP__CONVERSION__HOST="platform.internal"
APP__MEDIA__HOST="platform.internal"
APP__SHORTY__HOST="platform.internal"

# pilot/.env — dix dépendances de service
APP__AUTHENTICATION__HOST="platform.internal"
APP__BAM__HOST="platform.internal"
APP__CONFIG__HOST="platform.internal"
APP__CONTENT__HOST="platform.internal"
APP__CONVERSION__HOST="platform.internal"
APP__MEDIA__HOST="platform.internal"
APP__PRODUCT__HOST="platform.internal"
APP__SHORTY__HOST="platform.internal"
APP__SITEMAP__HOST="platform.internal"
APP__SOCIAL__HOST="platform.internal"

Chaque client HTTP dans framework.yaml a reçu sa propre base_uri construite depuis la variable HOST de sa cible, et le header Host a cédé la place à un User-Agent qui identifie l’appelant :

content.client:
    base_uri: "%env(APP__HTTP__SCHEME)%://%env(APP__CONTENT__HOST)%:%env(APP__HTTP__PORT)%/content/api/"
    headers:
        User-Agent: "Platform Content - %semver%"

Le changement n’est pas cosmétique. Dans l’ancienne configuration, le header Host explicite garantissait que les requêtes atteignaient le bon virtual host de la gateway quelle que soit la résolution DNS. Dans la nouvelle, chaque client pointe directement vers le nom DNS de sa cible — le Host correct est dérivé automatiquement de la base_uri. L’emplacement du header ne reste pas vide : le User-Agent identifie désormais le service appelant, ce qui remonte dans les logs et le traçage distribué sans instrumentation supplémentaire.

L’inconfort de la lisibilité

Le fichier env de pilot est passé de neuf variables de gateway à dix variables HOST spécifiques par service. Le fichier est devenu plus long. L’architecture n’est pas devenue plus simple — les dix dépendances étaient là avant et elles sont toujours là. Ce qui a changé, c’est qu’elles sont lisibles.

Le Facteur III dit de stocker la config dans l’environnement. L’ancienne approche satisfaisait ça à la lettre : six variables, toutes dans des fichiers env, aucune en dur dans le code. Mais des variables qui effondrent le graphe de dépendances entier dans un seul hostname opaque ne sont pas vraiment de la configuration — elles sont un raccourci qui échange la lisibilité contre la commodité. Le Facteur III ne demande pas seulement que la config soit externalisée — il suppose implicitement qu’elle reste informative une fois externalisée.

Le refacto n’a rien simplifié. Il a rendu la complexité visible. Les dix variables HOST de pilot documentent, dans le fichier .env lui-même, les dix services dont il dépend. Un nouveau membre d’équipe qui lit ce fichier apprend quelque chose de réel sur l’architecture. L’ancien fichier lui apprenait qu’il y avait une gateway.

Il y a une version de cette histoire où on lit l’état final et on conclut que l’équipe a fait un travail inutile — elle a remplacé six variables par dix, toutes pointant vers le même hôte de toute façon. En développement local, platform.internal résout toujours au même endroit. Le comportement fonctionnel n’a pas changé.

Le changement est dans ce que la config communique. Dans Kubernetes, les valeurs HOST divergent : chaque cible obtient son propre nom DNS interne au cluster, différent par environnement. Les variables portent maintenant une vraie information. Le refacto a préparé la config à être honnête sur une topologie qu’elle simplifiait silencieusement depuis des années.

Ce qu’on n’avait pas, c’était les logs des cinq minutes précédant le crash.

Promtail tournait. Il était healthy. Il collectait les logs de tous les autres services sans problème. Mais pour celui-ci, dans la fenêtre qui comptait, il n’y avait rien. Le service s’était crashé sans laisser de trace.

Le setup qui semblait correct

La stack de logging était raisonnable. Chaque service écrivait du JSON structuré vers stdout avec le formatter logstash de Monolog :

stdout:
    type: stream
    path: "php://stdout"
    level: "%env(MONOLOG_LEVEL__DEFAULT)%"
    formatter: 'monolog.formatter.logstash'

Promtail collectait la sortie des containers via la socket Docker, parsait le JSON, extrayait des labels, poussait vers Loki :

scrape_configs:
    -
        job_name: docker
        docker_sd_configs:
            -
                host: unix:///var/run/docker.sock
                refresh_interval: 5s
        pipeline_stages:
            -
                drop:
                    older_than: 168h
            -
                json:
                    expressions:
                        level: level
                        msg: message
                        service: service
            -
                labels:
                    level:
                    service:
        relabel_configs:
            -
                source_labels: [ '__meta_docker_container_log_stream' ]
                target_label: stream

Deux stages font plus de travail que les autres. Le stage json extrait level et service de chaque ligne de log ; le stage labels qui suit immédiatement les promeut en labels d’index Loki, ce qui fait de {service="content", level="error"} une lookup directe plutôt qu’un scan plein texte sur les lignes stockées. Le relabeling stream conserve si une ligne venait de stdout ou stderr — une distinction requêtable dès que Monolog envoie les erreurs vers stderr et le reste vers stdout. Le stage drop older_than: 168h est une soupape de sécurité : si Promtail redémarre après une longue interruption et rejoue des lignes bufferisées, tout ce qui est plus vieux de sept jours est écarté avant d’atteindre Loki.

En théorie : les logs vont vers stdout, Promtail lit stdout, les logs apparaissent dans Loki. La méthodologie twelve-factor décrit exactement ce modèle pour le Facteur XI — traiter les logs comme des flux d’événements, écrire vers stdout, laisser l’environnement gérer la collecte et le routage.

L’application avait stdout. Promtail lisait stdout. Qu’est-ce qui pouvait mal tourner.

Ce que fingers_crossed emporte avec lui

En production, le bloc when@prod remplaçait le simple handler stream par quelque chose de plus sophistiqué :

when@prod:
    monolog:
        handlers:
            main:
                type: fingers_crossed
                action_level: error
                handler: main_group
                excluded_http_codes: [404]

La ligne excluded_http_codes: [404] est elle-même révélatrice : sans elle, chaque 404 d’un scanner ou d’un crawler déclenche un flush complet du buffer, déversant des mégaoctets de logs debug pour des URLs malformées. Quelqu’un avait déjà appris ça à ses dépens.

fingers_crossed est un pattern Monolog bien connu. L’idée est élégante : ne pas noyer les logs de production dans le bruit debug, mais si quelque chose tourne mal, retrouver rétrospectivement ce qui s’est passé avant l’erreur. Le handler bufferise chaque entrée de log en mémoire. Au moment où il voit une error, il flush le buffer entier vers le handler imbriqué — en donnant le contexte complet qui a précédé la défaillance.

Le problème, c’est ce qui se passe quand la défaillance n’est pas une erreur loguée. C’est un OOM kill. Un SIGKILL de l’orchestrateur. Un segfault. Un process qui arrête de répondre et est tué de force.

Dans ces cas, fingers_crossed n’atteint jamais son action_level. Le buffer existe, plein des cinq dernières minutes d’activité, et il disparaît avec le process. Les logs étaient là. Ils étaient en mémoire. Ils sont morts avant d’atteindre stdout.

Le Facteur IX du twelve-factor parle de disposabilité : les processus doivent démarrer vite et s’arrêter proprement. Sur un arrêt normal (SIGTERM), un processus bien élevé finit son travail en cours et quitte. Mais les crashes ne sont pas des arrêts propres, et les buffers mémoire ne sont pas résistants aux crashes. Le service était disposable au sens où on pouvait le redémarrer ; il ne l’était pas au sens où sa sortie était transparente.

Les fichiers que personne ne lisait

Il y avait un deuxième problème, plus silencieux mais tout aussi persistant.

Chaque service avait un handler main_group qui routait les logs vers deux destinations en parallèle :

main_group:
    type: group
    members: [main_file, stdout]

main_file:
    type: stream
    path: "%kernel.logs_dir%/%kernel.environment%.log"
    formatter: "monolog.formatter.logstash"

var/log/prod.log était écrit sur chaque service, dans chaque environnement, y compris en production. Le même contenu qui allait vers stdout allait aussi vers un fichier à l’intérieur du container. Le fichier grossissait sans rotation. Le fichier n’était pas accessible à Promtail (qui lisait depuis la socket Docker, pas depuis le filesystem du container). Le fichier consommait de l’espace disque. Personne ne le lisait.

Le channel audit était pire :

audit_file:
    type: stream
    path: "%kernel.logs_dir%/audit.log"
    formatter: 'monolog.formatter.line'

audit:
    type: group
    members: [audit_file, stderr]
    channels: ['audit']

Les logs d’audit allaient vers stderr (visible par Promtail) et vers audit.log (invisible à Promtail). Le format dans le fichier était une ligne brute, pas le JSON structuré qu’attendait Promtail. En pratique, la piste d’audit existait à deux endroits : l’une requêtable, l’autre enfouie dans un répertoire de container qui ne survivait que le temps du container.

Ce que le Facteur XI demande vraiment

Le onzième facteur est direct là-dessus : une application ne doit pas se soucier du routage ou du stockage de son flux de sortie. Elle écrit vers stdout. Tout le reste est le job de l’environnement.

Ça veut dire pas de handlers de fichiers en production. Pas en backup. Pas pour les pistes d’audit. Pas “au cas où”. Du moment qu’une application se met à gérer des fichiers, elle prend en charge la rotation, la rétention, l’espace disque, et l’accessibilité — rien de tout ça n’appartient à l’intérieur d’un container.

La correction pour les handlers de fichiers est directe. Dans when@prod, supprimer chaque handler *_file et chaque group qui en inclut un. Le channel audit reçoit le même traitement : stderr uniquement, JSON structuré, pas de fichier :

when@prod:
    monolog:
        handlers:
            stdout:
                type: stream
                path: "php://stdout"
                # défaut "warning" — configurable par déploiement via variable d'env pour du debug ciblé
                level: "%env(default:default_log_level:MONOLOG_LEVEL__DEFAULT)%"
                formatter: 'monolog.formatter.logstash'

            stderr:
                type: stream
                path: "php://stderr"
                level: error
                formatter: 'monolog.formatter.logstash'

            main:
                type: group
                members: [stdout]
                channels: ['!event', '!http_client', '!doctrine', '!deprecation', '!audit']

            audit:
                type: stream
                path: "php://stderr"
                level: debug
                formatter: 'monolog.formatter.logstash'
                channels: ['audit']

stdout pour le channel principal. stderr pour les erreurs et l’audit. Rien d’autre. Promtail récupère les deux via la socket Docker. Le container n’écrit rien sur disque. Et les logs d’audit sont maintenant du JSON structuré, requêtable dans Loki avec tout le reste.

La question plus dure sur fingers_crossed

Les handlers de fichiers, c’était simple. fingers_crossed est plus nuancé.

Le pattern résout un vrai problème : dans un service de production actif, tout logger en debug crée du bruit et des coûts. fingers_crossed permet de capturer le contexte sans le payer sauf si quelque chose tourne vraiment mal. C’est un compromis raisonnable quand le mode de défaillance contre lequel on protège est une erreur applicative (une exception, une 500, une requête lente).

Ce n’est pas un compromis raisonnable quand le mode de défaillance est un crash de process. Et dans un environnement Kubernetes, les crashes de process arrivent : évictions OOM, échecs de liveness probe, pression sur les nodes. Exactement les cas où on a le plus besoin des logs.

Une approche : garder fingers_crossed mais réduire la taille du buffer. Par défaut il garde tout depuis le dernier reset. Mettre buffer_size: 50 plafonne l’usage mémoire, ce qui limite aussi ce qui se perd lors d’un crash. On n’aura pas le contexte complet, mais on aura les cinquante dernières entrées. Cette voie réduit le périmètre de perte sans supprimer la cause : l’opacité dépend toujours d’un seuil d’erreur qui peut ne jamais se déclencher.

Une autre approche : accepter que les logs debug soient coûteux et monter le niveau par défaut en production. Alors on n’a plus besoin de fingers_crossed du tout — si info et au-dessus vont directement vers stdout, rien n’est jamais bufferisé.

L’approche retenue : supprimer fingers_crossed, monter le niveau par défaut à warning, garder un override debug disponible via variable d’env pour les investigations ciblées. Les logs qui comptent apparaissent immédiatement. Ceux qui ne comptent pas ne sont jamais écrits. Rien n’est bufferisé.

Les crashes ne flushent pas

Le Facteur XI et le Facteur IX se rejoignent au même point : un process qui meurt en plein milieu d’une requête. un autre article de cette série décrivait l’illusion d’un service qui fonctionnait parfaitement sur un pod mais se comportait silencieusement mal sur deux. C’est la même illusion, un niveau au-dessus : un service qui semblait logger correctement, jusqu’au moment où il en avait le plus besoin.

La règle pour Monolog en production est sans appel : si ça n’atteint pas stdout ou stderr avant que le process quitte, ça n’existe pas. Un handler de fichier à l’intérieur d’un container est invisible pour le collecteur de logs et meurt avec le pod. Un buffer fingers_crossed est invisible pour le collecteur de logs et meurt avec le process.

La production tend à créer les conditions où on a le plus besoin des logs — pression OOM, défaillances en cascade, mauvais déploiements — et c’est exactement les conditions où ces deux patterns échouent simultanément. Écrire vers stdout, adopter un niveau par défaut qui ne nécessite pas de bufferisation, et rendre l’override disponible pour quand on en a vraiment besoin. Les logs seront là. Ils n’attendront pas un seuil d’erreur qui ne se déclenche jamais.

docker run --rm <image> php -r "var_dump(require '.env.local.php');"

La sortie montrait tout ce que composer dump-env prod avait compilé dans l’image au moment du build. Ce qui voulait dire tout ce qui se trouvait dans le fichier .env quand l’image avait été construite. Ce qui voulait dire, entre autres, ça :

INFLUXDB_INIT_ADMIN_TOKEN=<influxdb-admin-token>
GF_SECURITY_ADMIN_USER=admin
GF_SECURITY_ADMIN_PASSWORD=admin123
BLACKFIRE_CLIENT_ID=<blackfire-client-id>
BLACKFIRE_CLIENT_TOKEN=<blackfire-client-token>
BLACKFIRE_SERVER_ID=<blackfire-server-id>
BLACKFIRE_SERVER_TOKEN=<blackfire-server-token>
NGROK_AUTHTOKEN=replace-me-optionnal

Vingt-cinq variables au total. Chaque credential accumulé dans le .env racine sur trois ans, désormais permanent dans un layer d’image.

Comment dump-env fonctionne

composer dump-env prod est une optimisation Symfony légitime. Au lieu de parser les fichiers .env à chaque requête, le runtime charge un tableau PHP pré-compilé depuis .env.local.php. Plus rapide et plus simple.

Le problème, c’est ce qu’il lit. Le Dockerfile copie le dépôt dans l’image avec COPY . ./, .env inclus. Ensuite dump-env prod lit ce fichier et compile chaque variable dans .env.local.php. L’image est livrée avec une capture figée des credentials qui se trouvaient dans .env au moment du build.

Les layers Docker sont des archives immuables. Même si une étape ultérieure supprimait .env du système de fichiers du container, le layer qui le contient existerait toujours dans l’image. docker save <image> produit une archive tar de chaque layer ; extraire un fichier spécifique de n’importe quel point de l’historique de build est une opération simple. Les credentials sont invisibles à l’exécution. Ils ne sont pas partis.

Le Facteur V est explicite là-dessus : un artefact de build doit être agnostique à l’environnement, la config arrivant à l’étape de release depuis l’extérieur. Dès que des credentials sont compilés dedans, l’image n’est plus portable. On ne peut plus la promouvoir entre environnements. On builde deux fois en espérant que le deuxième se comporte comme le premier.

Comment vingt-cinq variables s’accumulent

Avant de voir comment on a réparé ça, il vaut la peine de comprendre comment on en est arrivé là.

Les tokens BLACKFIRE_* sont le cas facile à comprendre. Un membre de l’équipe configure le profiling, a besoin de partager la configuration, et le dépôt est déjà ouvert à tout le monde. Une ligne dans .env est la voie de moindre résistance. Les credentials InfluxDB et Grafana suivent la même logique — outillage partagé, dépôt partagé, un commit.

Puis il y a les variables qui révèlent une autre dérive. Dans certains .env de services :

APP__RATINGS__SERIALS='{"marque1":{"fr":"12345"},...}'  # ~40 lignes de JSON
APP__YOUTUBE__CREDENTIALS='{"marque1":{"client_id":"xxx","refresh_token":"yyy"},...}'

Des numéros de série pour la mesure d’audience. Des refresh tokens YouTube par marque. Ce ne sont pas des secrets au sens des tokens Blackfire. Ce sont des données métier — le genre de valeurs qui varient entre marques et environnements, que quelqu’un a décidé de versionner dans .env parce qu’elles se comportaient comme de la configuration et que .env était l’endroit où vivait la configuration.

Vingt-cinq variables, c’est la somme de décisions incrémentales, dont aucune ne semblait fausse isolément. Le problème est structurel : quand .env est la seule réponse disponible, tout finit par y ressembler.

Où les choses appartiennent vraiment

Vider le fichier exigeait de répondre à une question pour chaque variable : où est-ce que ça appartient vraiment ?

Les réponses ont révélé trois catégories que l’équipe n’avait jamais explicitement nommées :

La config statique vit dans le code. Règles métier, logique de routing, fichiers de paramètres Symfony — tout ce qui ne varie pas entre les déploiements. Un changement exige un rebuild. Les blocs JSON de numéros de série se sont révélés ne pas être de la config statique du tout : ils étaient interrogés depuis un service Config dédié à l’exécution. Ils n’avaient rien à faire dans un fichier.

La config environnementale varie entre les déploiements : hostnames, chaînes de connexion, credentials de services tiers. C’est ce que le Facteur III désigne par “config dans les variables d’environnement” — de vraies variables au niveau OS, injectées à l’exécution, jamais des fichiers qui voyagent avec le code. Dans Kubernetes, c’est un ConfigMap pour les valeurs non sensibles et un Kubernetes Secret pour les credentials. Le choix retenu pour les secrets a été SOPS — les credentials sont chiffrés et committés dans git, plutôt que stockés dans un coffre-fort externe comme Azure Key Vault ou HashiCorp Vault. Un coffre-fort échange la simplicité contre l’auditabilité : rotation automatique, logs d’audit centralisés, accès via workload identity sans clé à protéger. SOPS échange ces capacités contre un modèle opérationnel plus simple — pas de service externe à interroger au déploiement, les secrets transitent par le processus de review normal du code, l’historique git fait office de piste d’audit. Les contreparties acceptées sont la rotation manuelle et la responsabilité de protéger la clé de déchiffrement elle-même. Pour la taille de l’équipe, le compromis était délibéré.

La config dynamique change sans déploiement : paramètres éditoriaux, seuils par marque, configuration de modération de contenu. Elle appartient à une base de données, gérée via le service Config de l’application. Une partie de ce qui s’était accumulé dans les .env de services était cette catégorie depuis le début, passant pour des valeurs par défaut statiques parce qu’elle changeait assez rarement pour que personne ne le remarque.

Une fois les catégories nommées, les variables se sont triées. Le .env racine est arrivé à quatre lignes :

DOMAIN=platform.127.0.0.1.sslip.io
XDEBUG_MODE=off
SERVER_NAME=:80
APP_ENV=dev

Des valeurs par défaut sûres. Rien de sensible. dump-env prod compile maintenant des chaînes vides ; les vraies valeurs arrivent à l’exécution depuis Kubernetes.

L’image PostgreSQL

L’image PostgreSQL utilisée en CI a un mot de passe codé en dur :

FROM postgres:15
ENV POSTGRES_PASSWORD=admin123

Ça ressemble au même problème. Ce n’en est pas un, parce que le modèle de menace est différent. La base CI est éphémère — elle existe le temps d’un run de pipeline, ne contient pas de vraies données, tourne dans un réseau isolé. Un mot de passe codé en dur sur une base de test jetable est un risque acceptable, pas une entorse à la règle.

En production, la question ne se pose pas : la plateforme utilise Azure Flexible Server, un service PostgreSQL managé. Il n’y a pas d’image Docker. Les credentials arrivent via injection dans les charts Helm, sans jamais toucher un layer.

Ce qui survit au build maintenant

L’image qui part en production contient maintenant une garantie : var_dump(require '.env.local.php') ne retourne que des chaînes vides et des valeurs par défaut sûres. Les credentials ne sont pas là parce qu’ils n’y ont jamais été mis — ils arrivent à l’exécution, depuis l’extérieur.

C’est la frontière de responsabilité que dump-env avait silencieusement effacée : l’image est l’application, le runtime est l’environnement. Ils ne devraient pas connaître les secrets de l’autre.

Ces lignes se trouvaient dans le .env de production du service media. Pas le staging. Pas un override local. La production, committée dans le dépôt, lue à chaque démarrage.

Les chemins se terminent là où on s’y attendrait : /media, /share_storage. Ils commencent ailleurs : /home/jenkins-slave, le répertoire home d’un runner CI issu d’une ancienne installation Jenkins.

Comment le home d’un runner atterrit dans la config de production

La plateforme avait grandi depuis une seule machine. Un serveur faisait tout tourner — l’application, le runner CI, la base de données, le stockage de fichiers. Les fichiers transitaient entre l’app et le système CI via NFS : un répertoire monté sur le même hôte, accessible aux containers comme au runner.

Le chemin /home/jenkins-slave/share_media était là où le partage NFS atterrissait sur cette machine. Quand l’équipe a migré vers Docker Compose, les containers ont hérité du montage NFS. Le chemin est entré dans le .env parce que l’application devait savoir où trouver les fichiers. Personne ne l’a changé parce que ça marchait. Le montage était toujours là. Le chemin était valide. L’application démarrait. Les fichiers apparaissaient où ils devaient.

Trois ans plus tard, personne n’y pensait plus du tout. C’était juste comme ça que le chemin media était configuré.

Ce que kubectl apply a trouvé

Le premier kubectl apply du service media s’est terminé avec un pod bloqué en CrashLoopBackOff. Le container démarrait. L’entrypoint tournait. L’application essayait d’accéder à /home/jenkins-slave/share_media/media. Fichier ou répertoire inexistant. Pas de montage NFS. Pas de runner.

Le chemin ne documentait pas une décision de design. Il documentait la machine qui tournait par hasard au moment où le .env avait été écrit.

C’est exactement le problème que le Facteur IV de l’application twelve-factor décrit. Les backing services — stockage, files, bases de données — doivent être des ressources attachées, configurées via URL ou chaîne de connexion, interchangeables entre environnements sans toucher au code. Un chemin de fichier sur un hôte partagé n’est pas un backing service. C’est une hypothèse physique sur la machine. Quand la machine change, l’hypothèse lâche.

Le chemin était le symptôme

La première étape évidente était de supprimer la référence au runner :

APP__COLD_STORAGE__FILESYSTEM_PATH="/share_media/media"
APP__SHARE_STORAGE__FILESYSTEM_PATH="/share_storage"

Plus propre. Plus de références CI dans une config de production. Toujours incorrect. L’application supposait encore un système de fichiers POSIX — soit un volume monté, soit un répertoire sur le nœud. Dans Kubernetes, un volume partagé entre plusieurs pods nécessite un PersistentVolumeClaim en mode ReadWriteMany. La plupart des fournisseurs de stockage ne le supportent pas. Ceux qui le font ont tendance à être lents et coûteux. Et même là où ça fonctionne, on a juste remplacé une hypothèse sur le système de fichiers par une autre.

Renommer le chemin gagnait du temps. Ça ne réglait pas le problème.

Le problème, c’est qu’environ douze téraoctets d’images — originaux et déclinaisons pré-générées dans différents formats — pour plusieurs marques éditoriales — étaient traités comme un répertoire. Un répertoire ne se monte pas proprement sur plusieurs pods. Un backing service, si.

Flysystem comme forme de la solution

Le service media avait déjà Flysystem de configuré. Trois adaptateurs concrets — système de fichiers local, AWS S3, Azure Blob — et un adaptateur lazy par-dessus :

# config/packages/flysystem.yaml
flysystem:
    storages:
        media.storage.local:
            adapter: 'local'
            options:
                directory: "/"

        media.storage.aws:
            adapter: 'aws'
            options:
                client: 'aws_client_service'
                bucket: 'media'
                streamReads: true

        media.storage:
            adapter: 'lazy'
            options:
                source: '%env(APP__FLYSYSTEM_MEDIA_STORAGE)%'

Tout le code de l’application dépend de media.storage. Il ne sait pas si les fichiers vivent sur le système de fichiers ou dans un bucket cloud. Une variable d’environnement détermine quel backend est actif :

APP__FLYSYSTEM_MEDIA_STORAGE=media.storage.aws   # production
APP__FLYSYSTEM_MEDIA_STORAGE=media.storage.local  # fallback local toujours disponible

Le chemin est parti. L’hypothèse sur le système de fichiers est partie. Ce qui reste, c’est un nom de service — une ressource attachée au sens twelve-factor, configurable sans rebuilder l’image.

Le même pattern s’étend au cache de vignettes. LiipImagine génère des images redimensionnées à la demande ; les originaux et le cache généré passent par des adaptateurs Flysystem séparés :

liip_imagine:
    loaders:
        default:
            flysystem:
                filesystem_service: 'media.storage'
        default_cache:
            flysystem:
                filesystem_service: 'media.cache.storage'

Deux variables d’environnement, deux buckets. Toute la chaîne — recevoir l’upload, stocker l’original, générer la vignette, la mettre en cache — est portable vers le cloud sans toucher une ligne de PHP.

Ce que l’article ne couvre pas, c’est le déplacement des données. Le lazy adapter change une variable d’environnement. Faire passer douze téraoctets d’un montage NFS vers un bucket S3, c’est un autre projet — une fenêtre de migration, une double-écriture pendant le cutover, une vérification qu’il ne manque rien.

Ce que Minio rend possible en CI

La production utilise S3. Le développement local utilise Minio , un stockage objet compatible S3 qui tourne dans un container Docker. L’adaptateur AWS parle à Minio en local et à S3 en production. L’application ne voit pas la différence :

# local/CI
APP__FLYSYSTEM_MEDIA_STORAGE=media.storage.aws
APP__MINIO_ENDPOINT=http://minio:9000
APP__MINIO_ACCESS_KEY=minioadmin
APP__MINIO_SECRET_KEY=minioadmin

Le même code, le même adaptateur, un endpoint différent. Pas de mock, pas de chemins de test spéciaux, pas de branches conditionnelles par environnement.

Mais la configuration CI va un cran plus loin. L’image Minio utilisée dans le pipeline n’est pas l’image officielle upstream — c’est une image custom buildée avec des fixtures de test préchargées :

FROM minio/minio:latest
COPY tests/fixtures/ /fixtures_media/

Chaque run CI démarre avec une instance Minio qui contient déjà les données attendues par la suite de tests. Pas de script de setup, pas de commande de seed, pas d’étape “attendre le chargement des fixtures” avant que les tests commencent. L’état initial de l’environnement de test fait partie de l’artefact de build.

Le Facteur V appliqué à l’infrastructure de test : l’état de l’environnement est buildé, versionné, immuable. Le pipeline CI construit l’image Minio depuis la même source et au même commit que l’image applicative. Les fixtures de test et le code qui les exploite sont toujours synchronisés.

Le compromis S3, honnêtement

S3 introduit un coût de latence que le stockage local n’a pas. Les premières données d’un fichier prennent 10 à 30 millisecondes à arriver depuis S3 — c’est la latence first-byte documentée du service, pas une mesure sur ce trafic spécifique.

À 300 requêtes par seconde, le raisonnement pour accepter ce compromis était le suivant : la majorité des lectures touche des vignettes déjà générées dans le cache S3, pas les fichiers originaux. Une image fraîchement uploadée paie la pénalité du cold miss une fois, à la première demande de vignette. Tout ce qui suit est un cache hit. Savoir si la latence de queue sous charge réelle confirmait ce raisonnement nécessitait des tests de charge suivis séparément — la décision d’architecture et la validation étaient découplées.

Le compromis a été accepté : comportement prévisible sur plusieurs pods, pas de problèmes d’état partagé, une couche de stockage qui scale sans coordination. L’histoire complète des mesures appartient au rapport de tests de performance, pas ici.

Le fantôme s’en va

Le chemin /home/jenkins-slave n’apparaît plus dans la configuration. Mais ce à quoi il pointait était un couplage qui précédait Docker, précédait les microservices, précédait n’importe quelle conversation sur la migration cloud. Le runner CI et l’application de production partageaient un système de fichiers parce qu’ils vivaient sur la même machine. Personne ne l’avait conçu comme ça. Ça s’était accumulé.

Une erreur kubectl apply sur un chemin qui n’aurait pas dû exister a forcé la question : pourquoi cette application suppose-t-elle qu’un runner CI spécifique est présent sur l’hôte ? La réponse était “parce que ça a toujours été comme ça.” Ce n’est pas une raison. C’est une histoire.

Renommer le chemin était un correctif en carton. L’adaptateur lazy de Flysystem était la vraie réponse — pas parce qu’il est plus élégant, mais parce qu’il fait du backend de stockage une décision qui appartient à l’environnement, pas à l’application. Le container démarre, lit une variable, se connecte à ce qui est à l’autre bout. Il ne sait pas si c’est un bucket dans un datacenter ou un container sur un laptop.

Le répertoire home du runner a disparu de la config. Ce qui l’a remplacé, c’est un nom de service. C’est la différence.