Le DAG `alertes` enchaîne `app.detection.internal_alerts` puis
`app.cli generate-recommendations`, à la quinzième minute de chaque heure. Le
décalage laisse finir `ml_score`, qui écrit à l'heure pile les prédictions dont
la règle `anomaly` a besoin, sans créer de dépendance entre les deux DAGs :
quatre règles de détection sur cinq ne touchent pas au modèle, et un modèle
jamais entraîné ne doit pas priver le parc de ses alertes.
L'image Airflow porte un second environnement uv, `/opt/backend/.venv`, puisque
la logique vit dans le backend (ADR 0006) et qu'aucune route HTTP ne l'expose.
Le `UV_PROJECT_ENVIRONMENT` global hérité de l'issue #115 disparaît : il vaut
pour tous les projets, donc `uv run` depuis `/opt/ml` résolvait le venv du
backend. uv prend `<projet>/.venv` par défaut, se placer dans le dossier suffit.
La CI vérifie maintenant que les deux environnements s'importent sans réseau.
Le conteneur reçoit `DATABASE_URL` en asyncpg et une `APP_SECRET_KEY` distincte
de celle de l'API, alimentée par `AIRFLOW_APP_SECRET_KEY` : la détection ne
signe aucun jeton, et Airflow permet d'exécuter du code depuis son interface.
Table `app_user`, son dépôt, et la commande `create-admin`. Le nom évite
`user`, mot réservé de PostgreSQL, et rappelle qu'il s'agit d'un compte
applicatif, par opposition au rôle PostgreSQL qui portera le
cantonnement des accès ETL et ML.
`credentials_changed_at` couvre à elle seule le changement de mot de
passe, le changement de rôle et la désactivation : tout jeton émis avant
cet instant sera refusé, sans attendre son expiration.
La configuration refuse désormais de démarrer sur cinq erreurs
silencieuses : secret trop court ou laissé à sa valeur d'exemple, `debug`
en production, joker CORS, origines vides hors local, et cookie
`SameSite=None` sans `Secure`. Les fixtures de test et les deux
`.env.example` suivent, sans quoi rien ne démarrerait.
Le mot de passe de l'admin ne transite jamais par `argv`, visible de tout
`ps` : il est saisi par `getpass` ou tiré au sort. Une révision Alembic
qui insérerait ce compte graverait son empreinte dans Git pour toujours.
Monter le dossier ./db/init sur /docker-entrypoint-initdb.d remplacait le
dossier de l'image au lieu de s'y ajouter. Les trois scripts d'init livres
par timescaledb-ha disparaissaient sans aucun message : creation de
l'extension dans template1, reglage par timescaledb-tune, et installation de
timescaledb_toolkit. Verifie au demarrage : le dossier ne contenait que nos
deux fichiers, et timescaledb_toolkit etait absent des bases.
Monter chaque fichier separement retablit l'ordre attendu, verifie dans les
journaux : 000, 001, 010, puis 100 et 110.
TIMESCALEDB_TELEMETRY passe a off par defaut : l'image envoie sinon des
statistiques d'usage a Timescale, ce qui ne va pas pour un deploiement
on-premise.
Service `db` du docker-compose racine sur timescale/timescaledb-ha:pg17,
volume nomme et cibles Makefile db-up / db-down / db-reset / db-logs / db-psql.
- db/init/100-extensions.sql declare l'extension attendue, db/init/110 cree
la base enervision_test utilisee par la suite de tests du backend.
- Numerotation a partir de 100 : l'image depose ses propres scripts 000, 001
et 010, et un prefixe a deux chiffres se trie avant 010 en locale C.
- Volume monte sur /home/postgres/pgdata/data, PGDATA de cette image. Monte
au chemin habituel de l'image postgres, il ne retiendrait rien sans erreur.
- Port publie 5433 par defaut, 5432 etant souvent deja pris sur un poste.
Johan LEROY