Docker

Le composer.json de chaque service avait ça dans sa section post-install-cmd : "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. ...

Le rolling deploy avait l’air propre. Un nouveau pod démarrait. Kubernetes voyait le healthcheck passer — php -v renvoyait zéro — et commençait à router du trafic vers le nouveau container. 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 pipeline avait deux stages qui n’avaient rien à voir avec le code : provision et deprovision. Entre eux, dans l’ordre : phpunit, phpmetrics, behat. 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. ...

À un moment de l’audit de migration cloud, quelqu’un a lancé ça : 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. ...

Ça fait des années que j’avais envie d’un homelab à la maison. Un endroit à moi pour héberger mes outils de développement, surveiller mes machines, faire tourner de la domotique, tester des trucs sans risquer de casser quoi que ce soit d’important. L’idée est simple. La mise en place un peu moins. À l’époque, Kubernetes n’existait pas encore. Les options pour faire tourner plusieurs services sur une machine se résumaient à du scripting bash, des configurations Nginx écrites à la main, et beaucoup de café. Les tutoriels “homelab pour les humains” brillaient par leur absence. ...

La configuration semblait parfaite. Pointer *.traefik.me sur 127.0.0.1, télécharger un certificat wildcard depuis le même domaine, le déposer dans Traefik, et chaque service local obtient une URL HTTPS propre sans IP dans la barre d’adresse. Pas de limites de débit Let’s Encrypt, pas de mkcert à expliquer aux collègues, pas d’avertissements de certificat auto-signé à contourner. Juste https://myapp.traefik.me et un cadenas vert. Puis en mars 2025, Let’s Encrypt a révoqué le certificat. Le wildcard cert pour traefik.me est parti et il ne reviendra pas. ...

J’ai utilisé Vagrant pendant des années. Un Vagrantfile par projet, une box de base partagée, un script de provision qui marchait le mardi mais pas le jeudi. La promesse était simple : des environnements reproductibles pour tout le monde dans l’équipe. La réalité était plus compliquée. Les années Vagrant Le setup avait du sens à l’époque. Une VM par projet, provisionnée avec des scripts shell ou Ansible, partagée via un Vagrantfile versionné. L’onboarding était théoriquement vagrant up et c’est terminé. ...

La règle était simple : celui qui casse le build CI offre le café à l’équipe. Ça a marché un moment. Puis quelqu’un a proposé qu’on ait un retour plus immédiat. Quelque chose de physique. Quelque chose qui tire. Un Dream Cheeky Thunder a atterri sur un bureau peu après. Quatre missiles en mousse, un câble USB, et un consensus d’équipe très clair : le brancher au cluster, le câbler au pipeline de build, et laisser le CI décider qui mérite une volée. ...