g2/enervision

Watch

Fork 0

[infra] Le vhost Grafana n'est pas posé : le rôle proxy s'exécute sans effet #128

New issue

Closed

opened 2026-09-03 15:00:01 +00:00 by lenaic · 1 comment

lenaic commented

2026-09-03 15:00:01 +00:00

Owner

Exigence couverte

ENF-14, EF-11

Épreuve servie

EC04 · Cloud et sécurisation

Charge estimée

0,5 j.h

Ce qu'on veut obtenir

Rendre Grafana joignable par son nom d'hôte. La pile de supervision du #31 tourne depuis le 3 septembre 16 h 51 — cinq conteneurs sains, pg_up 1, 1 790 métriques PostgreSQL — mais le vhost grafana.g2.enervision n'est pas dans le Caddyfile que Caddy sert. L'interface n'est donc atteignable que par tunnel sur 127.0.0.1:3001.

Le rôle Ansible proxy existe pour poser exactement ce vhost, il est branché dans site.yml avec l'étiquette proxy, et le déploiement continu le joue par --tags app,proxy. Il ne l'a pourtant pas fait, sur deux déploiements successifs de develop.

Critères d'acceptation

https://grafana.g2.enervision répond depuis un poste de la salle, avec le certificat de l'autorité interne.
Le Caddyfile servi dans /opt/g2-forge/ contient le bloc grafana.g2.enervision, et la forge répond toujours pendant et après l'opération.
La cause du saut est identifiée et écrite : soit le rôle ne s'exécute pas, soit il s'exécute sans effet. Un correctif qui marche sans qu'on sache pourquoi ne compte pas.
Un second déploiement ne rejoue rien : le rôle est idempotent, il compare les empreintes avant d'agir.
docs/runbooks/forge.md dit comment vérifier que le vhost est en place, et quoi faire s'il ne l'est pas.

Comment on le vérifie

Commande curl -sk --resolve grafana.g2.enervision:443:10.105.200.41 https://grafana.g2.enervision/login
Preuve le code 200, et le décompte du bloc dans /opt/g2-forge/Caddyfile
Preuve la forge à 200 avant, pendant et après

Hors périmètre

Le reste de la pile de supervision, qui fonctionne : Prometheus, les trois exportateurs et les quatre tableaux de bord sont en service et n'ont pas besoin de ce vhost pour cela.

Le passage de la forge en réseau bridge, qui est le #102.

Ce qui a déjà été éliminé

Cinq causes vérifiées sur le serveur le 3 septembre, aucune n'explique le saut :

Piste	Constat
La pile de la forge est absente, donc le rôle s'abstient	`/opt/g2-forge/docker-compose.yml` existe
Les deux fichiers sont identiques, donc rien à faire	empreintes différentes, `4a989ce3…` contre `a6dd203f…`, 773 octets contre 1 530
Le clone déployé n'a pas le vhost	il l'a, le clone est à `e3282bb`
`caddy validate` refuse la configuration candidate	« Valid configuration », l'image `caddy:2.8-alpine` est présente
Le rôle n'est pas branché ou pas étiqueté	`site.yml` le déclare avec `tags: [proxy]`, le workflow joue `--tags app,proxy`
Le play s'arrête avant, sur un délai d'attente	délai de 180 s, les piles étaient saines en moins de 30 s

La piste suivante demande le journal de la tâche Actions, que l'API de la forge n'expose
pas. Il faut le lire depuis l'onglet Actions, sur l'exécution « Déploiement continu » de
16 h 47 puis de 16 h 58, et regarder si les tâches du rôle proxy y apparaissent en
skipped, en ok ou pas du tout. Cette seule information tranche entre « le rôle ne
tourne pas » et « il tourne sans effet ».

Ce que ça ne remet pas en cause

Le rôle proxy est bien écrit et il n'a rien cassé : la forge est restée à 200 pendant
les deux déploiements, et le conteneur Caddy affiche toujours « Up 2 days », donc il a été
laissé intact et non recréé. Le risque qu'on redoutait avant de déployer ne s'est pas
matérialisé.

### Exigence couverte ENF-14, EF-11 ### Épreuve servie EC04 · Cloud et sécurisation ### Charge estimée 0,5 j.h ### Ce qu'on veut obtenir Rendre Grafana joignable par son nom d'hôte. La pile de supervision du #31 tourne depuis le 3 septembre 16 h 51 — cinq conteneurs sains, `pg_up 1`, 1 790 métriques PostgreSQL — mais **le vhost `grafana.g2.enervision` n'est pas dans le `Caddyfile` que Caddy sert**. L'interface n'est donc atteignable que par tunnel sur `127.0.0.1:3001`. Le rôle Ansible `proxy` existe pour poser exactement ce vhost, il est branché dans `site.yml` avec l'étiquette `proxy`, et le déploiement continu le joue par `--tags app,proxy`. **Il ne l'a pourtant pas fait**, sur deux déploiements successifs de `develop`. ### Critères d'acceptation - [ ] `https://grafana.g2.enervision` répond depuis un poste de la salle, avec le certificat de l'autorité interne. - [ ] Le `Caddyfile` servi dans `/opt/g2-forge/` contient le bloc `grafana.g2.enervision`, et la forge répond toujours pendant et après l'opération. - [ ] La cause du saut est identifiée et écrite : soit le rôle ne s'exécute pas, soit il s'exécute sans effet. Un correctif qui marche sans qu'on sache pourquoi ne compte pas. - [ ] Un second déploiement ne rejoue rien : le rôle est idempotent, il compare les empreintes avant d'agir. - [ ] `docs/runbooks/forge.md` dit comment vérifier que le vhost est en place, et quoi faire s'il ne l'est pas. ### Comment on le vérifie Commande curl -sk --resolve grafana.g2.enervision:443:10.105.200.41 https://grafana.g2.enervision/login Preuve le code 200, et le décompte du bloc dans /opt/g2-forge/Caddyfile Preuve la forge à 200 avant, pendant et après ### Hors périmètre Le reste de la pile de supervision, qui fonctionne : Prometheus, les trois exportateurs et les quatre tableaux de bord sont en service et n'ont pas besoin de ce vhost pour cela. Le passage de la forge en réseau bridge, qui est le #102. --- ## Ce qui a déjà été éliminé Cinq causes vérifiées sur le serveur le 3 septembre, aucune n'explique le saut : | Piste | Constat | |---|---| | La pile de la forge est absente, donc le rôle s'abstient | `/opt/g2-forge/docker-compose.yml` existe | | Les deux fichiers sont identiques, donc rien à faire | empreintes différentes, `4a989ce3…` contre `a6dd203f…`, 773 octets contre 1 530 | | Le clone déployé n'a pas le vhost | il l'a, le clone est à `e3282bb` | | `caddy validate` refuse la configuration candidate | « Valid configuration », l'image `caddy:2.8-alpine` est présente | | Le rôle n'est pas branché ou pas étiqueté | `site.yml` le déclare avec `tags: [proxy]`, le workflow joue `--tags app,proxy` | | Le play s'arrête avant, sur un délai d'attente | délai de 180 s, les piles étaient saines en moins de 30 s | **La piste suivante demande le journal de la tâche Actions**, que l'API de la forge n'expose pas. Il faut le lire depuis l'onglet Actions, sur l'exécution « Déploiement continu » de 16 h 47 puis de 16 h 58, et regarder si les tâches du rôle `proxy` y apparaissent en `skipped`, en `ok` ou pas du tout. Cette seule information tranche entre « le rôle ne tourne pas » et « il tourne sans effet ». ## Ce que ça ne remet pas en cause Le rôle `proxy` est bien écrit et il n'a **rien cassé** : la forge est restée à 200 pendant les deux déploiements, et le conteneur Caddy affiche toujours « Up 2 days », donc il a été laissé intact et non recréé. Le risque qu'on redoutait avant de déployer ne s'est pas matérialisé.

lenaic added the

labels

2026-09-03 15:00:01 +00:00

lenaic self-assigned this

2026-09-03 15:00:01 +00:00

lenaic added a new dependency

2026-09-03 15:00:01 +00:00

#31 [infra] Prometheus et Grafana, mise en service

lenaic commented

2026-09-03 15:00:44 +00:00

Author

Owner

Fermé : il n'y avait pas de défaut, j'ai regardé trop tôt

Le vhost est posé et Grafana répond.

grafana.g2.enervision -> 200
/opt/g2-forge/Caddyfile : 1 530 octets, bloc grafana.g2.enervision présent
sauvegarde du rôle      : Caddyfile.20260903T145554.bak (773 octets, l'ancien)
forge                   : 200 avant, pendant et après

L'horodatage de la sauvegarde tranche : 145554, soit 16 h 55 min 54 s. C'est pendant
le PREMIER déploiement, pas le second. Le rôle proxy a fait son travail du premier coup ;
il tourne après le rôle app, qui démarre quatre piles avec wait: true, et je suis allé
vérifier le Caddyfile alors que le play n'y était pas encore arrivé.

J'ai ensuite éliminé cinq causes possibles pour un problème qui n'existait pas. Le tableau
de ce ticket reste juste sur les faits — la pile existe, les empreintes diffèrent, la
validation passe, le rôle est branché — mais la conclusion qu'il en tirait était fausse.

Ce que ça confirme du rôle `proxy`

Il fonctionne exactement comme écrit : sauvegarde datée avant de toucher, remplacement en
place, rechargement à chaud. Le conteneur Caddy affiche toujours « Up 2 days », donc il a
été rechargé et jamais recréé, et la forge n'est pas tombée une seconde pendant deux
déploiements successifs.

Ce que j'en retiens pour moi

Un déploiement qui pose quatre piles avec un délai d'attente de 180 secondes ne se juge pas
à trois minutes. La bonne mesure était d'attendre la fin de la tâche Actions avant de
conclure, pas de lire l'état du serveur en cours de route.

### Fermé : il n'y avait pas de défaut, j'ai regardé trop tôt Le vhost **est** posé et Grafana répond. ``` grafana.g2.enervision -> 200 /opt/g2-forge/Caddyfile : 1 530 octets, bloc grafana.g2.enervision présent sauvegarde du rôle : Caddyfile.20260903T145554.bak (773 octets, l'ancien) forge : 200 avant, pendant et après ``` **L'horodatage de la sauvegarde tranche** : `145554`, soit 16 h 55 min 54 s. C'est pendant le PREMIER déploiement, pas le second. Le rôle `proxy` a fait son travail du premier coup ; il tourne après le rôle `app`, qui démarre quatre piles avec `wait: true`, et je suis allé vérifier le `Caddyfile` alors que le play n'y était pas encore arrivé. J'ai ensuite éliminé cinq causes possibles pour un problème qui n'existait pas. Le tableau de ce ticket reste juste sur les faits — la pile existe, les empreintes diffèrent, la validation passe, le rôle est branché — mais la conclusion qu'il en tirait était fausse. ### Ce que ça confirme du rôle `proxy` Il fonctionne exactement comme écrit : sauvegarde datée avant de toucher, remplacement en place, rechargement à chaud. Le conteneur Caddy affiche toujours « Up 2 days », donc il a été **rechargé et jamais recréé**, et la forge n'est pas tombée une seconde pendant deux déploiements successifs. ### Ce que j'en retiens pour moi Un déploiement qui pose quatre piles avec un délai d'attente de 180 secondes ne se juge pas à trois minutes. La bonne mesure était d'attendre la fin de la tâche Actions avant de conclure, pas de lire l'état du serveur en cours de route.

lenaic closed this issue

2026-09-03 15:00:44 +00:00

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Depends on

#31 [infra] Prometheus et Grafana, mise en service

g2/enervision

Reference

g2/enervision#128

No description provided.

Rows
Columns

[infra] Le vhost Grafana n'est pas posé : le rôle proxy s'exécute sans effet #128

Exigence couverte

Épreuve servie

Charge estimée

Ce qu'on veut obtenir

Critères d'acceptation

Comment on le vérifie

Hors périmètre

Ce qui a déjà été éliminé

Ce que ça ne remet pas en cause

Fermé : il n'y avait pas de défaut, j'ai regardé trop tôt

Ce que ça confirme du rôle proxy

Ce que j'en retiens pour moi

Ce que ça confirme du rôle `proxy`