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>

ansible/roles/supervision/tasks/main.yml

@@ -80,17 +80,39 @@
     state: started
     enabled: true
 
+# Réseau de l'hôte, écoute forcée sur 127.0.0.1 : Docker tourne avec
+# "bridge": "none" et "iptables": false (étape 5), donc un `ports:` sur le
+# pont par défaut n'est jamais publié (constaté le 2026-10-09 : rien sur
+# 3001). En mode hôte, rien à publier, et Kuma joint directement les
+# services locaux qu'il surveille.
 - name: déployer Uptime Kuma
   community.docker.docker_container:
     name: uptime-kuma
     image: louislam/uptime-kuma:1
     state: started
     restart_policy: unless-stopped
-    ports:
-      - "127.0.0.1:{{ supervision_port_uptime_kuma }}:3001"
+    network_mode: host
+    env:
+      UPTIME_KUMA_HOST: "127.0.0.1"
+      UPTIME_KUMA_PORT: "{{ supervision_port_uptime_kuma | string }}"
     volumes:
       - uptime-kuma-data:/app/data
 
+- name: vérifier qu'Uptime Kuma écoute sur 127.0.0.1 uniquement
+  ansible.builtin.wait_for:
+    host: 127.0.0.1
+    port: "{{ supervision_port_uptime_kuma }}"
+    timeout: 60
+
+- name: refuser toute écoute d'Uptime Kuma hors de 127.0.0.1
+  ansible.builtin.shell:
+    cmd: "ss -Htln 'sport = :{{ supervision_port_uptime_kuma }}' | awk '{print $4}'"
+  register: supervision_ecoute_kuma
+  changed_when: false
+  failed_when: >-
+    supervision_ecoute_kuma.stdout_lines | length == 0 or
+    supervision_ecoute_kuma.stdout_lines | reject('equalto', '127.0.0.1:' ~ supervision_port_uptime_kuma) | list | length > 0
+
 - name: afficher s'il faut relancer Kolla pour les nouvelles règles
   ansible.builtin.debug:
     msg: >

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