Mise en production : la refonte du tableau de bord, l'ETL au quart d'heure et les correctifs front #220
No reviewers
Labels
No labels
Compat/Breaking
EC01
EC02
EC03
EC04
EC05
EC06
Kind/BDD
Kind/Back
Kind/Bug
Kind/CICD
Kind/Cloud
Kind/Contenu
Kind/Data
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Front
Kind/IA
Kind/Infra
Kind/Monitoring
Kind/Security
Kind/Testing
Portée/Post-jury
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
ops/alerte
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
g2/enervision!220
Loading…
Reference in a new issue
No description provided.
Delete branch "develop"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Ce que ça change
Mise en production de tout ce qui a été fusionné dans
developdepuis le07/09 : la refonte du tableau de bord, l'ETL au quart d'heure, la supervision
des conteneurs réparée, les manuels d'exploitation, et les trois correctifs
front de la soirée. C'est le rang 1 du backlog et le critère de sortie
ajouté au jalon J2 :
main=develop.Refs #48
Preuve
Les demandes livrées :
Chacune est entrée dans
developavec ses quatre tâches de chaîne au vert etl'approbation d'un pair. Aucune n'a été forcée.
Une migration entre dans cette livraison :
0020_fraicheur_zone_or.sql.Elle vient de la #206 et doit s'appliquer au déploiement.
Ce qui change pour la démonstration
automatique. C'est ce que la démo montrait en version périmée jusqu'ici.
(#206).
comme une droite ou comme une consommation nulle (#217).
Relecture
Où regarder en priorité
1. La migration.
0020_fraicheur_zone_or.sqlest la seule opération nonréversible d'un simple retour de code. À relire avant la fusion, pas après.
2. Le déploiement n'est pas gardé par la chaîne.
deploy.ymlse déclenchesur
push: main, sansworkflow_runnineeds. Sur un exécuteur unique, ledéploiement peut donc partir avant que la chaîne ait rendu son verdict. La
barrière est une convention de fusion, pas un mécanisme. Ce constat est
antérieur à cette livraison et n'a pas de ticket ; il vaut d'être vu ici parce
que c'est la première mise en production depuis qu'il a été écrit.
3. Ce qui reste en réserve après cette livraison : #215, le panneau de
traçabilité qui contredit la courbe, et #205, le délai réel de la prévision.
Les deux sont écrits dans le PRD, aucun ne bloque la démonstration.
4. L'heure. Cette livraison part un soir de fin de sprint. Si quelque
chose casse sur le serveur, le retour arrière est
git revertdu commit defusion puis redéploiement — la migration 0020, elle, ne se défait pas toute
seule.
Panne silencieuse : la cible `cadvisor` était `up`, le conteneur `healthy`, et il publiait bien 2 500 séries — mais toutes portaient `id="/"`, le cgroup racine. Aucune ne portait de nom de conteneur, donc les requêtes en `{name!=""}` des tableaux de bord « conteneurs » et « socle » ne rendaient rien : quatre stats à zéro et « No data » partout. La cause n'est pas dans le dépôt. Le démon de ml-stagiaire-02 est passé au containerd image store (Docker 29 : `Storage Driver: overlayfs`, `io.containerd.snapshotter.v1`) : la couche d'écriture d'un conteneur n'est plus sous /var/lib/docker/image/, cAdvisor v0.52 ne la trouve pas, et il écarte chaque conteneur en entier plutôt que de publier ce qu'il en sait. Son journal le disait, une ligne par conteneur et par minute. Deux pistes essayées et écartées : monter en version — v0.52.1 est la dernière publiée — et couper les métriques de disque, qui ne change rien. Reste la lecture directe de containerd, dans le namespace `moby` où Docker range ses conteneurs. Son handler Docker doit être neutralisé au passage, sans quoi il reprend la main sur les mêmes cgroups pour les rejeter. Ce que ça coûte : containerd ne connaît pas les noms Docker, `name` devient un identifiant de 64 caractères. D'où `noms-conteneurs`, qui publie la correspondance identifiant -> nom lisible que les panneaux joignent par `on(name) group_left(nom)`. Même parti que le relais d'alertes : un fichier de bibliothèque standard monté dans l'image Python officielle, écoute bornée à la boucle locale. Il parle au démon Docker et en a donc tous les pouvoirs, mais n'appelle qu'une route, en lecture. Le banc tient désormais le remède en place : la lecture de containerd, la présence du service, le job de collecte, et le fait qu'aucun panneau ne regroupe plus par (name). Aucun contrôle n'aurait attrapé la panne à l'exécution — c'est ce que le manuel documente maintenant, avec le contrôle qui la révèle en une commande. Les panneaux réseau par conteneur restent presque vides, et c'est attendu : nos piles tournent en réseau hôte et n'ont pas de compteurs réseau propres. Leur description le dit désormais au lecteur.La page de profil était un stub : elle affichait l'identité et rien de plus, alors que le critère d'acceptation du ticket est le changement de mot de passe. Aucun endpoint d'auto-service n'existait — seul `PATCH /auth/users/{id}`, réservé aux admins et sans vérification du mot de passe actuel. API — `POST /auth/me/password` (`{current_password, new_password}`, authentifié) : vérifie le mot de passe actuel (un jeton d'accès volé ne suffit pas), le remplace, coupe toutes les sessions de l'utilisateur, puis réémet une session pour l'appelant — ses cookies remplacent les anciens dans la réponse. 403 si l'actuel est faux, 422 si le nouveau est trop court ou identique. Journalisé : `password_changed` / `password_change_ko`. Dashboard — `MotDePasseFormulaire`, monté sur la page de profil : actuel + nouveau + confirmation, la confirmation vérifiée côté client. Succès : champs vidés, « vos autres appareils ont été déconnectés ». Docs d'auth mises à jour (endpoints, codes, décisions). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EL8Yw5fQMitWWyKR4FugX3