diff --git a/ansible/roles/supervision/tasks/main.yml b/ansible/roles/supervision/tasks/main.yml index 554f433..4b96249 100644 --- a/ansible/roles/supervision/tasks/main.yml +++ b/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: > diff --git a/docs/journal.md b/docs/journal.md index 990abb8..80c02ec 100644 --- a/docs/journal.md +++ b/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. diff --git a/docs/runbooks/supervision.md b/docs/runbooks/supervision.md index 036cd8a..cc83569 100644 --- a/docs/runbooks/supervision.md +++ b/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