tripoli.cloud/README.md

Tripoli Cloud

Cloud personnel (photos, sauvegardes, partage de fichiers) construit pour démontrer des compétences SRE proches de la stack de Clever Cloud (Rust, netlink, WireGuard, CI/CD). Un seul serveur, pas un cluster — ce README reste honnête sur ce qui est réellement en place vs prévu.

Serveur

Hetzner CPX22 (2 vCPU, 3.7 Go RAM, 75 Go disque), Ubuntu 26.04, 65.109.142.188 / tripoli.cloud. Ce serveur héberge déjà six autres projets en production (Forgejo, lecheminvert.tech, check-my-irve, iot-alarm-system, voltvision, monitoring Prometheus/Grafana) derrière un Caddy partagé qui tient les ports 80/443. Décision assumée : le futur tripoli-edge (Rust) sera un service interne, derrière ce Caddy — pas un second frontal en concurrence sur 80/443. Reprendre ces ports casserait les sites existants.

Pas de virtualisation imbriquée (KVM/QEMU) sur ce VPS Hetzner Cloud — non tenté, non simulé.

Architecture

                              Internet
                                 |
                        DNS (OVH) : tripoli.cloud
                                 |
                                 v
                    +-------------------------+
                    |     edge-caddy          |  <- partagé avec 6 autres
                    |  TLS Let's Encrypt      |     domaines (Forgejo,
                    |  routage par Host       |     lecheminvert, etc.)
                    +-------------------------+
                                 |
                    172.17.0.1:9000 (passerelle docker0)
                                 v
                    +-------------------------+
                    |      tripoli-edge       |  Rust (hyper/tokio), systemd,
                    |  /healthz  /metrics     |  utilisateur système sans
                    |  reverse-proxy          |  privilège
                    +-------------------------+
                                 |
                    127.0.0.1:8081
                                 v
                    +-------------------------+
                    |      tripoli-api        |  Rust (axum/sqlx), systemd,
                    |  auth (Argon2, session) |  même utilisateur système
                    |  upload/download        |
                    +-----------+-------------+
                                 |
                 +---------------+----------------+
                 v                                 v
      PostgreSQL (Docker,                /var/lib/tripoli-api/blobs
      127.0.0.1:5433, dédié -            (fichiers, nommés par UUID)
      séparé de celui d'iot-alarm)

   ----------------------------------------------------------------
   En dehors du chemin de trafic (labos, jamais branchés dessus) :

   Mac admin --WireGuard(10.100.0.0/24)--> serveur (accès SSH/Ansible)
   tripoli-netctl : netns + veth à la demande (Phase 4)
   bird-lab       : BGP+BFD entre 2 netns, racine en transit (Phase 6)

   Observabilité : scrape ajouté au Prometheus/Grafana déjà en place
   sur ce serveur (pas d'instance dédiée) - dashboard + alertes
   versionnés dans monitoring/.

   CI/CD : Forgejo Actions (runner déployé en systemd) - build+test sur
   toute PR, déploiement sur main via un compte "deploy" sans privilège.

Limites assumées

• Un seul VPS, pas un cluster. Tout ce qui ressemble à de la redondance (deux namespaces dans bird-lab, par exemple) est un labo pédagogique sur une seule machine, jamais une simulation de multi-nœuds ou de multi-DC.
• Pas de virtualisation imbriquée (KVM/QEMU) - non disponible sur ce VPS Hetzner Cloud, non tenté.
• Serveur partagé, pas dédié à Tripoli Cloud : 6 autres projets personnels y tournent déjà. Plusieurs décisions d'architecture (tripoli-edge derrière Caddy plutôt qu'à sa place, pas de second Prometheus/Grafana, PostgreSQL dans un conteneur séparé plutôt que natif) découlent directement de cette contrainte, pas d'un choix gratuit.
• OpenTofu écrit mais pas appliqué : le code (tofu/) est validé syntaxiquement, mais plan/apply demandent des identifiants OVH et Hetzner Cloud qui n'ont pas été demandés ni extraits automatiquement.
• Alertes Prometheus sans notification : les règles se déclenchent et sont vérifiables, mais rien ne les route encore par email (pas d'Alertmanager, pas de policy Grafana dédiée branchée).
• SSH public toujours ouvert : choix explicite fait avec l'utilisateur, pas encore restreint au tunnel WireGuard.

État réel

Composant	État
Prototype frontend (app/)	Fait — React/TS/Vite/Tailwind, maquette
Reconnaissance serveur (Phase 0)	Fait
WireGuard (canal admin Mac ↔ serveur)	Fait — 10.100.0.0/24, port 58212/udp (51820 filtré par le pare-feu Hetzner Cloud, voir ansible/group_vars/all.yml)
Pare-feu / fail2ban / unattended-upgrades	Déjà en place avant ce projet ; confirmés/complétés par Ansible
SSH public	Toujours ouvert (choix explicite, pas encore restreint au VPN)
Ansible (rôle de base)	Fait — ansible/
OpenTofu (serveur + DNS)	Code écrit — tofu/ ; serveur en donnée en lecture seule (jamais recréé/détruit), DNS géré via le provider OVH. plan/apply pas encore exécutés (nécessitent des identifiants OVH/Hetzner non fournis)
tripoli-edge (Rust, Phase 2)	Fait et déployé en prod — tripoli-edge/, service systemd, derrière Caddy, vérifié via https://tripoli.cloud/healthz et /metrics
tripoli-api (Rust, Phase 3)	Fait et déployé en prod — tripoli-api/, auth par session (Argon2), upload/download, PostgreSQL dédié (Docker), vérifié via https://tripoli.cloud/api/...
tripoli-netctl (Rust, Phase 4)	Fait — tripoli-netctl/, labo pédagogique (netns + veth via rtnetlink), testé sur le serveur (création, ping traversant la veth, destruction propre), volontairement pas branché sur le trafic de prod
Observabilité (Phase 5)	Fait — pas de stack dédiée (réutilise le Prometheus/Grafana partagé existant), scrape tripoli-edge + alertes (down, disque) + dashboard versionné (monitoring/), vérifié via l'API Prometheus/Grafana
Bird/BGP (Phase 6, bonus)	Fait — bird-lab/, BGP+BFD entre 2 namespaces via la racine en transit (AS 65000/65010/65011), vérifié (sessions Established, BFD Up, propagation de route, détection de panne sur coupure de lien), puis proprement démonté
CI/CD	Fait — .forgejo/workflows/ci.yml (pas .gitlab-ci.yml : le dépôt vit sur Forgejo, pas GitLab). Runner Forgejo Actions déployé en systemd, déploiement via un compte deploy sans privilège (ci/README.md)

Dépôt

Code poussé sur forge.adam.belkacemi.me/adam/tripoli.cloud (même instance Forgejo que les autres projets hébergés sur ce serveur).