- tripoli-edge (hyper/tokio bas niveau, pas de framework type axum) :
/healthz, /metrics (Prometheus, compteurs à la main), reverse-proxy
vers tripoli-api avec vrais 502 tant que ce service n'existe pas
(Phase 3), logs JSON structurés par requête.
- Écoute sur 127.0.0.1 + 172.17.0.1 (passerelle docker0), jamais sur
l'interface publique - même pattern que le Nginx de VoltVision déjà
sur ce serveur.
- Déployé en prod : systemd (utilisateur système dédié, sans privilège),
bloc Caddy ajouté pour tripoli.cloud/www.tripoli.cloud, règle ufw
ajoutée (Ansible) pour que Caddy puisse joindre le port 9000 - sans
quoi le chemin INPUT de l'hôte bloque le trafic inter-bridges même
vers 172.17.0.1.
- Vérifié bout-en-bout via https://tripoli.cloud, sans régression sur
les 6 autres domaines déjà servis par ce Caddy.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Reconnaissance : le serveur héberge déjà 6 autres projets derrière un
Caddy partagé (80/443) ; tripoli-edge sera un service interne (décision
prise avec l'utilisateur), pas un second frontal.
- WireGuard : canal admin Mac <-> serveur (10.100.0.0/24, port 58212/udp
après avoir découvert que 51820 était filtré par le pare-feu Hetzner
Cloud, distinct de ufw).
- Ansible : rôle base (confirme fail2ban/unattended-upgrades/ufw déjà en
place, sans toucher aux règles des autres projets) + rôle wireguard
(clé privée générée sur la cible, jamais stockée dans ce dépôt).
- OpenTofu : serveur Hetzner référencé en data source lecture seule
(jamais recréé/détruit - serveur partagé et déjà en prod) ; DNS
tripoli.cloud géré via le provider OVH.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
