corrige Uptime Kuma : réseau hôte, écoute sur 127.0.0.1 uniquement

Avec le pont Docker désactivé (bridge: none), le port demandé n'était
jamais publié. Le rôle vérifie maintenant que le port écoute, et seulement
sur 127.0.0.1.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/journal.md

@@ -450,3 +450,15 @@ Le stock chaud transforme une attente de 30 s en une attente de 4 s en faisant l
 **Suite**
 
 Étape 12 : domaine, HTTPS et sécurité. **Arrêt obligatoire avant de commencer** : Adam doit me donner le domaine (il l'achète et configure le DNS lui-même).
+
+## 2026-10-09 — Correctif : Uptime Kuma injoignable par le tunnel SSH
+
+**Symptôme** (signalé par Adam) : conteneur `uptime-kuma` « healthy », mais rien n'écoute sur `127.0.0.1:3001` ; le tunnel SSH donne « connexion refusée ».
+
+**Cause** : depuis l'étape 5, Docker tourne avec `"bridge": "none"` et `"iptables": false` pour ne jamais toucher au pare-feu. Le conteneur était rattaché au pont par défaut, qui n'existe pas : pas de réseau, et le `ports: 127.0.0.1:3001:3001` du rôle n'a jamais été publié (`docker inspect` : ports demandés présents, ports effectifs vides). Le contrôle de santé de l'image interroge le localhost du conteneur, d'où le « healthy » trompeur. Le défaut date de l'étape 7 : sa vérification avait porté sur l'état du conteneur, pas sur l'écoute côté hôte.
+
+**Correctif** (rôle `supervision`) : `network_mode: host` et écoute forcée sur `127.0.0.1` par `UPTIME_KUMA_HOST` / `UPTIME_KUMA_PORT` (noms vérifiés dans `server/config.js` de l'image). Plus de publication Docker, ni NAT ni règle de pare-feu. Le rôle vérifie désormais à chaque passage que le port écoute et uniquement sur `127.0.0.1` (échec du playbook sinon). Données conservées (volume `uptime-kuma-data`).
+
+**Vérifié** : `ss -tlnp` → `LISTEN 127.0.0.1:3001 users:(("node",...))` et rien d'autre ; `curl http://127.0.0.1:3001/` → 302 (redirection vers la page d'accueil de Kuma) ; port 3001 fermé sur l'IP publique depuis le Mac ; tables nftables inchangées ; second passage du playbook `changed=0`.
+
+**Comprendre** : « healthy » veut dire que le conteneur répond *à lui-même*, pas qu'il est joignable de l'extérieur. Le seul test qui prouve qu'un service est accessible, c'est de s'y connecter par le chemin réel (ici : écoute sur l'hôte, puis tunnel). En réseau hôte, le conteneur partage la pile réseau du serveur : l'adresse d'écoute devient la seule barrière, d'où la vérification automatique ajoutée au rôle.

docs/runbooks/supervision.md

@@ -11,7 +11,7 @@
 | openstack-exporter | `:9198` | Kolla |
 | cAdvisor, libvirt/mysqld/memcached exporters | ports divers | Kolla |
 | Relais Alertmanager → ntfy | `127.0.0.1:9099` | rôle Ansible `supervision` |
-| Uptime Kuma | `127.0.0.1:3001` | rôle Ansible `supervision` (conteneur Docker) |
+| Uptime Kuma | `127.0.0.1:3001` | rôle Ansible `supervision` (conteneur Docker en réseau hôte, écoute forcée sur 127.0.0.1 par `UPTIME_KUMA_HOST`) |
 
 Rien de tout cela n'est exposé sur `eno1` (vérifié : seuls 22/80/443 répondent
 depuis Internet). **Tant qu'il n'y a pas de domaine, l'accès se fait par
@@ -27,6 +27,12 @@ Puis dans le navigateur : `http://localhost:3000` (Grafana), `:9091`
 (Prometheus), `:9093` (Alertmanager), `:3001` (Uptime Kuma — premier accès :
 créer le compte admin toi-même, c'est une étape interactive).
 
+Piège (2026-10-09) : Docker tourne avec `"bridge": "none"` et `"iptables": false`
+(étape 5). Un conteneur sur le pont par défaut n'a donc pas de réseau, et son
+`ports:` n'est jamais publié — le conteneur reste « healthy » (son contrôle
+de santé interroge son propre localhost) mais rien n'écoute sur l'hôte.
+Vérifier avec `sudo ss -tlnp | grep 3001` : attendu `127.0.0.1:3001` seulement.
+
 Identifiants Grafana/Prometheus/Alertmanager : utilisateur `admin`, mot de
 passe dans `/etc/kolla/passwords.yml` sur le serveur (`grafana_admin_password`,
 `prometheus_password`, `prometheus_alertmanager_password`) — jamais affichés