[infra] Déploiement complet : MLflow, collecteur et migrations posés par le rôle Ansible

lenaic commented

2026-09-03 11:19:27 +00:00

Owner

Exigence couverte

ENF-09, ENF-10, EF-01

Épreuve servie

EC03 · CI/CD et qualité

Charge estimée

0,5 j.h

Ce qu'on veut obtenir

Rendre le déploiement réellement complet, pour qu'une mise en production se résume à déclencher la chaîne et à regarder le résultat.

Le constat qui motive ce ticket. Le clone du serveur date du 2 septembre à 14 h 06. Tout ce qui a été fusionné depuis — PostgreSQL sur Docker, MLflow, les sept tables de la zone or, le collecteur — n'existe que dans develop. Ce qui tourne sur la machine y a été posé à la main, service par service, et rien de cela ne se rejoue.

Le rôle app fait déjà le plus dur : il cloner le dépôt, rend les secrets depuis le coffre, produit le certificat TLS et démarre les piles. Il lui manque trois choses, et ces trois choses sont exactement ce qui empêche la chaîne de données de tourner toute seule.

Hors de ce ticket, et volontairement : conteneuriser l'API et le tableau de bord. C'est un morceau plus long, il aura le sien.

Critères d'acceptation

mlflow figure dans app_stacks et démarre par le playbook, comme postgres et minio. Il tourne aujourd'hui parce que quelqu'un l'a lancé à la main ; une réinstallation le perdrait.
Les dépendances Python du collecteur, httpx et minio, sont installées par le rôle. Elles sont absentes de la machine aujourd'hui : python3 -m collector.current échoue en ModuleNotFoundError avant même de lire sa configuration.
Les deux lignes de crontab de deploy sont posées par le rôle, la relève collecte-current.sh et les alertes collecte-alertes.sh, toutes deux à la minute. C'est le geste que l'ADR 0008 annonce comme « posé à la main aujourd'hui ».
Les lanceurs services/collector/bin/*.sh arrivent exécutables sur le serveur. Livrés en 100644, cron sort en Permission denied sans rien journaliser d'utile.
Les migrations en attente sont appliquées par le déploiement, et le playbook échoue si l'une d'elles échoue. Aujourd'hui rien ne les applique : enervision_prod ne connaît que 0007, les migrations 0001 à 0006 n'y sont jamais passées.
Le playbook est idempotent : deux exécutions de suite laissent la même machine, sans doublon de ligne de crontab ni réinstallation inutile.
Une exécution complète est jouée sur le serveur, et l'on vérifie derrière que la zone bronze grossit d'elle-même : le nombre d'objets sous endpoint=current augmente entre deux relevés espacés de trois minutes.
docs/runbooks/deploiement.md dit ce qui reste manuel après ce ticket, s'il reste quelque chose, et comment déclencher la chaîne sans passer par main.

Comment on le vérifie

Commande ansible-playbook -i inventory/hosts.ini site.yml --tags app, joué deux fois
Preuve la seconde exécution ne rapporte aucun « changed » sur le cron ni sur les paquets
Preuve sudo -u deploy crontab -l montre les deux lignes
Preuve le décompte d'objets bronze sous endpoint=current, à trois minutes d'intervalle

Hors périmètre

La conteneurisation de l'API et du tableau de bord, qui n'ont pas de pile dans infra/compose/. C'est le vrai dernier écart au « merger suffit », mais il est d'une autre taille et il aura son ticket.

Le socle système — pare-feu, durcissement SSH, moteur Docker — qui reste délibérément hors du déploiement continu, comme deploy.yml l'explique : un merge ne doit pas pouvoir le retoucher sans relecture humaine.

### Exigence couverte ENF-09, ENF-10, EF-01 ### Épreuve servie EC03 · CI/CD et qualité ### Charge estimée 0,5 j.h ### Ce qu'on veut obtenir Rendre le déploiement réellement complet, pour qu'une mise en production se résume à déclencher la chaîne et à regarder le résultat. **Le constat qui motive ce ticket.** Le clone du serveur date du 2 septembre à 14 h 06. Tout ce qui a été fusionné depuis — PostgreSQL sur Docker, MLflow, les sept tables de la zone or, le collecteur — n'existe que dans `develop`. Ce qui tourne sur la machine y a été posé à la main, service par service, et rien de cela ne se rejoue. Le rôle `app` fait déjà le plus dur : il cloner le dépôt, rend les secrets depuis le coffre, produit le certificat TLS et démarre les piles. Il lui manque trois choses, et ces trois choses sont exactement ce qui empêche la chaîne de données de tourner toute seule. Hors de ce ticket, et volontairement : conteneuriser l'API et le tableau de bord. C'est un morceau plus long, il aura le sien. ### Critères d'acceptation - [ ] `mlflow` figure dans `app_stacks` et démarre par le playbook, comme `postgres` et `minio`. Il tourne aujourd'hui parce que quelqu'un l'a lancé à la main ; une réinstallation le perdrait. - [ ] Les dépendances Python du collecteur, `httpx` et `minio`, sont installées par le rôle. Elles sont absentes de la machine aujourd'hui : `python3 -m collector.current` échoue en `ModuleNotFoundError` avant même de lire sa configuration. - [ ] Les deux lignes de crontab de `deploy` sont posées par le rôle, la relève `collecte-current.sh` et les alertes `collecte-alertes.sh`, toutes deux à la minute. C'est le geste que l'ADR 0008 annonce comme « posé à la main aujourd'hui ». - [ ] Les lanceurs `services/collector/bin/*.sh` arrivent exécutables sur le serveur. Livrés en `100644`, cron sort en `Permission denied` sans rien journaliser d'utile. - [ ] Les migrations en attente sont appliquées par le déploiement, et le playbook échoue si l'une d'elles échoue. Aujourd'hui rien ne les applique : `enervision_prod` ne connaît que `0007`, les migrations `0001` à `0006` n'y sont jamais passées. - [ ] Le playbook est **idempotent** : deux exécutions de suite laissent la même machine, sans doublon de ligne de crontab ni réinstallation inutile. - [ ] Une exécution complète est jouée sur le serveur, et l'on vérifie derrière que la zone bronze grossit d'elle-même : le nombre d'objets sous `endpoint=current` augmente entre deux relevés espacés de trois minutes. - [ ] `docs/runbooks/deploiement.md` dit ce qui reste manuel après ce ticket, s'il reste quelque chose, et comment déclencher la chaîne sans passer par `main`. ### Comment on le vérifie Commande ansible-playbook -i inventory/hosts.ini site.yml --tags app, joué deux fois Preuve la seconde exécution ne rapporte aucun « changed » sur le cron ni sur les paquets Preuve sudo -u deploy crontab -l montre les deux lignes Preuve le décompte d'objets bronze sous endpoint=current, à trois minutes d'intervalle ### Hors périmètre La conteneurisation de l'API et du tableau de bord, qui n'ont pas de pile dans `infra/compose/`. C'est le vrai dernier écart au « merger suffit », mais il est d'une autre taille et il aura son ticket. Le socle système — pare-feu, durcissement SSH, moteur Docker — qui reste délibérément hors du déploiement continu, comme `deploy.yml` l'explique : un merge ne doit pas pouvoir le retoucher sans relecture humaine.

lenaic added the

labels

2026-09-03 11:19:27 +00:00

lenaic self-assigned this

2026-09-03 11:19:27 +00:00

lenaic added a new dependency