2026-09-16 22:11:31 +02:00
# 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é.
2026-09-17 13:37:37 +02:00
## Architecture
```
Internet
|
DNS (OVH) : tripoli.cloud
|
v
+-------------------------+
| edge-caddy | < - partagé avec 6 autres
| TLS Let's Encrypt | domaines (Forgejo,
| routage par Host | lecheminvert, etc.)
+-------------------------+
Frontend et backend entièrement réels : plus aucune donnée simulée
À la demande explicite de l'utilisateur après avoir constaté que
tripoli.cloud affichait un 404 vide (le frontend n'avait jamais été
déployé) : déploiement du frontend, puis remplacement complet des
mocks par de vraies données, des deux côtés.
Backend (tripoli-api) :
- users.name, files.category (file/photo/backup), table notifications
(migration 0002).
- POST /api/auth/guest : compte invité réel et réutilisé
(invite@tripoli.local), pas une identité simulée côté frontend.
- GET /api/files?category=... , GET /api/notifications (+ read-all/
{id}/read), GET /api/storage (used_bytes réel, available_bytes via
statvfs - jamais un quota inventé).
- Notifications émises réellement sur upload/suppression.
Frontend (app/) :
- src/api/*.ts appellent réellement tripoli-api (plus de mockFetch).
- Upload réel (XHR, vraie progression), suppression avec bouton dédié,
vraies miniatures photo (<img src="/api/files/:id">).
- Session restaurée au chargement (GET /api/auth/me), logout réel.
- Retiré plutôt que simulé : 2FA, clé de récupération, accès partagés,
albums, dossiers, "4 appareils sauvegardés", chiffres marketing et
claim AES-256 côté client sur la page de connexion (jamais vrai -
remplacé par le vrai : HTTPS + Argon2).
Déploiement :
- Frontend construit et déployé sur le serveur (le build local échouait
spécifiquement sur cette machine - rolldown/esbuild natif ne répondait
plus, cause non résolue ; contourné en buildant sur le serveur, comme
déjà fait pour les crates Rust).
- Caddy : /var/www/tripoli-cloud servi en statique pour tripoli.cloud,
/api/*, /healthz, /metrics toujours proxyés vers tripoli-edge.
- Pipeline CI étendu : le job deploy construit et déploie maintenant
aussi le frontend, via un script sudo dédié supplémentaire
(tripoli-deploy-frontend.sh) sur le compte deploy sans privilège.
- Vérifié en navigateur réel (Chrome) : inscription, connexion, invité,
upload avec progression, photos, sauvegardes, notifications,
suppression, déconnexion - tous testés en conditions réelles.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-17 18:19:51 +02:00
/api/*, /healthz, /metrics tout le reste
| |
172.17.0.1:9000 (docker0) /var/www/tripoli-cloud
v (fichiers statiques,
+-------------------------+ file_server de Caddy)
| tripoli-edge |
| /healthz /metrics | Rust (hyper/tokio), systemd,
| reverse-proxy | utilisateur système sans
+-------------------------+ privilège
2026-09-17 13:37:37 +02:00
|
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.
Frontend et backend entièrement réels : plus aucune donnée simulée
À la demande explicite de l'utilisateur après avoir constaté que
tripoli.cloud affichait un 404 vide (le frontend n'avait jamais été
déployé) : déploiement du frontend, puis remplacement complet des
mocks par de vraies données, des deux côtés.
Backend (tripoli-api) :
- users.name, files.category (file/photo/backup), table notifications
(migration 0002).
- POST /api/auth/guest : compte invité réel et réutilisé
(invite@tripoli.local), pas une identité simulée côté frontend.
- GET /api/files?category=... , GET /api/notifications (+ read-all/
{id}/read), GET /api/storage (used_bytes réel, available_bytes via
statvfs - jamais un quota inventé).
- Notifications émises réellement sur upload/suppression.
Frontend (app/) :
- src/api/*.ts appellent réellement tripoli-api (plus de mockFetch).
- Upload réel (XHR, vraie progression), suppression avec bouton dédié,
vraies miniatures photo (<img src="/api/files/:id">).
- Session restaurée au chargement (GET /api/auth/me), logout réel.
- Retiré plutôt que simulé : 2FA, clé de récupération, accès partagés,
albums, dossiers, "4 appareils sauvegardés", chiffres marketing et
claim AES-256 côté client sur la page de connexion (jamais vrai -
remplacé par le vrai : HTTPS + Argon2).
Déploiement :
- Frontend construit et déployé sur le serveur (le build local échouait
spécifiquement sur cette machine - rolldown/esbuild natif ne répondait
plus, cause non résolue ; contourné en buildant sur le serveur, comme
déjà fait pour les crates Rust).
- Caddy : /var/www/tripoli-cloud servi en statique pour tripoli.cloud,
/api/*, /healthz, /metrics toujours proxyés vers tripoli-edge.
- Pipeline CI étendu : le job deploy construit et déploie maintenant
aussi le frontend, via un script sudo dédié supplémentaire
(tripoli-deploy-frontend.sh) sur le compte deploy sans privilège.
- Vérifié en navigateur réel (Chrome) : inscription, connexion, invité,
upload avec progression, photos, sauvegardes, notifications,
suppression, déconnexion - tous testés en conditions réelles.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-17 18:19:51 +02:00
- **Frontend, fonctionnalités volontairement absentes** : pas de
dossiers (stockage à plat), pas de suivi multi-appareils pour les
sauvegardes (aucun agent client), pas de partage/accès multi-
utilisateurs, préférences de notification stockées dans le navigateur
(pas synchronisées entre appareils). Rien de tout ça n'est simulé -
simplement pas construit dans cette passe.
2026-09-17 13:37:37 +02:00
2026-09-16 22:11:31 +02:00
## État réel
| Composant | État |
|---|---|
Frontend et backend entièrement réels : plus aucune donnée simulée
À la demande explicite de l'utilisateur après avoir constaté que
tripoli.cloud affichait un 404 vide (le frontend n'avait jamais été
déployé) : déploiement du frontend, puis remplacement complet des
mocks par de vraies données, des deux côtés.
Backend (tripoli-api) :
- users.name, files.category (file/photo/backup), table notifications
(migration 0002).
- POST /api/auth/guest : compte invité réel et réutilisé
(invite@tripoli.local), pas une identité simulée côté frontend.
- GET /api/files?category=... , GET /api/notifications (+ read-all/
{id}/read), GET /api/storage (used_bytes réel, available_bytes via
statvfs - jamais un quota inventé).
- Notifications émises réellement sur upload/suppression.
Frontend (app/) :
- src/api/*.ts appellent réellement tripoli-api (plus de mockFetch).
- Upload réel (XHR, vraie progression), suppression avec bouton dédié,
vraies miniatures photo (<img src="/api/files/:id">).
- Session restaurée au chargement (GET /api/auth/me), logout réel.
- Retiré plutôt que simulé : 2FA, clé de récupération, accès partagés,
albums, dossiers, "4 appareils sauvegardés", chiffres marketing et
claim AES-256 côté client sur la page de connexion (jamais vrai -
remplacé par le vrai : HTTPS + Argon2).
Déploiement :
- Frontend construit et déployé sur le serveur (le build local échouait
spécifiquement sur cette machine - rolldown/esbuild natif ne répondait
plus, cause non résolue ; contourné en buildant sur le serveur, comme
déjà fait pour les crates Rust).
- Caddy : /var/www/tripoli-cloud servi en statique pour tripoli.cloud,
/api/*, /healthz, /metrics toujours proxyés vers tripoli-edge.
- Pipeline CI étendu : le job deploy construit et déploie maintenant
aussi le frontend, via un script sudo dédié supplémentaire
(tripoli-deploy-frontend.sh) sur le compte deploy sans privilège.
- Vérifié en navigateur réel (Chrome) : inscription, connexion, invité,
upload avec progression, photos, sauvegardes, notifications,
suppression, déconnexion - tous testés en conditions réelles.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-17 18:19:51 +02:00
| Frontend (`app/` ) | Fait et déployé en prod — React/TS/Vite/Tailwind, servi en statique par Caddy (`/var/www/tripoli-cloud` ), **branché sur les vraies données de tripoli-api** (plus aucun mock) : auth, upload réel avec progression, photos/sauvegardes/notifications/espace disque réels. Éléments sans fonctionnalité réelle possible (2FA, albums, "4 appareils sauvegardés"...) retirés plutôt que simulés — détail dans `app/README.md` |
2026-09-16 22:11:31 +02:00
| 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) |
Phase 2 : tripoli-edge, service Rust interne derrière Caddy
- 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>
2026-09-16 22:31:58 +02:00
| `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` |
Frontend et backend entièrement réels : plus aucune donnée simulée
À la demande explicite de l'utilisateur après avoir constaté que
tripoli.cloud affichait un 404 vide (le frontend n'avait jamais été
déployé) : déploiement du frontend, puis remplacement complet des
mocks par de vraies données, des deux côtés.
Backend (tripoli-api) :
- users.name, files.category (file/photo/backup), table notifications
(migration 0002).
- POST /api/auth/guest : compte invité réel et réutilisé
(invite@tripoli.local), pas une identité simulée côté frontend.
- GET /api/files?category=... , GET /api/notifications (+ read-all/
{id}/read), GET /api/storage (used_bytes réel, available_bytes via
statvfs - jamais un quota inventé).
- Notifications émises réellement sur upload/suppression.
Frontend (app/) :
- src/api/*.ts appellent réellement tripoli-api (plus de mockFetch).
- Upload réel (XHR, vraie progression), suppression avec bouton dédié,
vraies miniatures photo (<img src="/api/files/:id">).
- Session restaurée au chargement (GET /api/auth/me), logout réel.
- Retiré plutôt que simulé : 2FA, clé de récupération, accès partagés,
albums, dossiers, "4 appareils sauvegardés", chiffres marketing et
claim AES-256 côté client sur la page de connexion (jamais vrai -
remplacé par le vrai : HTTPS + Argon2).
Déploiement :
- Frontend construit et déployé sur le serveur (le build local échouait
spécifiquement sur cette machine - rolldown/esbuild natif ne répondait
plus, cause non résolue ; contourné en buildant sur le serveur, comme
déjà fait pour les crates Rust).
- Caddy : /var/www/tripoli-cloud servi en statique pour tripoli.cloud,
/api/*, /healthz, /metrics toujours proxyés vers tripoli-edge.
- Pipeline CI étendu : le job deploy construit et déploie maintenant
aussi le frontend, via un script sudo dédié supplémentaire
(tripoli-deploy-frontend.sh) sur le compte deploy sans privilège.
- Vérifié en navigateur réel (Chrome) : inscription, connexion, invité,
upload avec progression, photos, sauvegardes, notifications,
suppression, déconnexion - tous testés en conditions réelles.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-17 18:19:51 +02:00
| `tripoli-api` (Rust, Phase 3) | Fait et déployé en prod — `tripoli-api/` , auth par session (Argon2, compte invité réel), fichiers par catégorie (file/photo/backup), notifications réelles, espace disque réel (`statvfs` ), PostgreSQL dédié (Docker), vérifié via `https://tripoli.cloud/api/...` et en navigateur réel |
Phase 4 : tripoli-netctl, labo network namespaces + veth (rtnetlink)
- CLI (clap) : create/destroy/list. Network namespace créé via
rtnetlink::NetworkNamespace (fork + unshare(CLONE_NEWNET) + bind-mount,
équivalent de `ip netns add`), paire veth créée dans la racine, un
bout déplacé dans le namespace (setns_by_fd) et adressé depuis un
thread OS dédié qui fait setns() - jamais un thread du pool
spawn_blocking de tokio, qui serait réutilisé pour d'autres tâches et
resterait coincé dans le namespace.
- Journal d'audit JSON (stderr + /var/log/tripoli-netctl/audit.log) à
chaque opération.
- Documenté explicitement comme labo pédagogique un-seul-poste :
tripoli-edge et tripoli-api restent nativement sur l'hôte, ce projet
ne pilote aucun trafic de production.
- Testé en conditions réelles sur le serveur : création, adressage des
deux côtés (dont lo, down par défaut dans un netns neuf), ping
traversant effectivement la veth, puis destruction propre (veth +
namespace) vérifiée par absence des interfaces et du namespace.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-16 22:58:53 +02:00
| `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** |
Phase 5 : observabilité (réutilise le Prometheus/Grafana partagé)
- Pas de stack dédiée : une instance Prometheus/Grafana existe déjà sur
ce serveur pour les 5 autres projets. En déployer une seconde aurait
dupliqué de la RAM sur une machine à 3.7 Go partagée, sans bénéfice -
même raisonnement que pour Caddy en Phase 2.
- Scrape job tripoli_edge (172.17.0.1:9000, même passerelle docker0 que
Caddy) ajouté à la config Prometheus existante.
- Règles d'alerte : TripoliEdgeDown (up == 0), HostDiskAlmostFull
(< 10% d'espace libre sur / - au niveau de la machine, pas seulement
de ce projet, puisqu'il n'y a qu'un disque pour tout le monde).
- Sonde blackbox externe ajoutée pour https://tripoli.cloud/healthz.
- Dashboard Grafana versionné (uid tripoli-cloud-edge), importé via
l'API (POST /api/dashboards/db) pour rester reproductible, pas
construit à la main dans l'UI.
- Vérifié : tous les targets Prometheus up (dont tripoli_edge et la
sonde tripoli.cloud), les deux règles d'alerte chargées et évaluées,
les requêtes du dashboard retournent de vraies valeurs.
- Limite assumée : les alertes se déclenchent dans Prometheus mais ne
sont pas encore routées par email (pas d'Alertmanager, pas de policy
de notification Grafana dédiée) - documenté comme prochain pas, pas
fait pour éviter de modifier la politique de notification globale de
l'instance partagée sans plus de tests.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-16 23:09:32 +02:00
| 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 |
Phase 6 (bonus) : bird-lab, BGP+BFD entre namespaces (rtnetlink/Bird)
- Topologie en étoile : racine (AS 65000) en transit entre bird-a
(AS 65010) et bird-b (AS 65011), namespaces créés par tripoli-netctl
(Phase 4). Chaque feuille origine une route factice, jamais
installée dans la table de routage réelle (export none partout) -
labo pédagogique, ne pilote aucun trafic de production.
- Vérifié en conditions réelles : sessions BGP Established dans les
deux sens, route de bird-b vue par bird-a avec next-hop = racine
(transit confirmé, pas un peering direct), sessions BFD Up
(200ms/200ms), coupure de lien détectée en < 5ms.
- Découverte : les namespaces n'ont aucun pare-feu propre, mais ufw
côté racine bloquait le retour des paquets BFD (chaque bout envoie
indépendamment, conntrack ne le reconnaît pas comme un flux BGP/TCP
existant) - même schéma que Caddy -> tripoli-edge en Phase 2. Règle
ufw ajoutée par run.sh, retirée par teardown.sh : rien de permanent.
- Pas de service systemd : labo lancé, vérifié, puis proprement démonté
(processus Bird, namespaces et règle ufw temporaire tous supprimés).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-17 01:17:15 +02:00
| 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é |
Frontend et backend entièrement réels : plus aucune donnée simulée
À la demande explicite de l'utilisateur après avoir constaté que
tripoli.cloud affichait un 404 vide (le frontend n'avait jamais été
déployé) : déploiement du frontend, puis remplacement complet des
mocks par de vraies données, des deux côtés.
Backend (tripoli-api) :
- users.name, files.category (file/photo/backup), table notifications
(migration 0002).
- POST /api/auth/guest : compte invité réel et réutilisé
(invite@tripoli.local), pas une identité simulée côté frontend.
- GET /api/files?category=... , GET /api/notifications (+ read-all/
{id}/read), GET /api/storage (used_bytes réel, available_bytes via
statvfs - jamais un quota inventé).
- Notifications émises réellement sur upload/suppression.
Frontend (app/) :
- src/api/*.ts appellent réellement tripoli-api (plus de mockFetch).
- Upload réel (XHR, vraie progression), suppression avec bouton dédié,
vraies miniatures photo (<img src="/api/files/:id">).
- Session restaurée au chargement (GET /api/auth/me), logout réel.
- Retiré plutôt que simulé : 2FA, clé de récupération, accès partagés,
albums, dossiers, "4 appareils sauvegardés", chiffres marketing et
claim AES-256 côté client sur la page de connexion (jamais vrai -
remplacé par le vrai : HTTPS + Argon2).
Déploiement :
- Frontend construit et déployé sur le serveur (le build local échouait
spécifiquement sur cette machine - rolldown/esbuild natif ne répondait
plus, cause non résolue ; contourné en buildant sur le serveur, comme
déjà fait pour les crates Rust).
- Caddy : /var/www/tripoli-cloud servi en statique pour tripoli.cloud,
/api/*, /healthz, /metrics toujours proxyés vers tripoli-edge.
- Pipeline CI étendu : le job deploy construit et déploie maintenant
aussi le frontend, via un script sudo dédié supplémentaire
(tripoli-deploy-frontend.sh) sur le compte deploy sans privilège.
- Vérifié en navigateur réel (Chrome) : inscription, connexion, invité,
upload avec progression, photos, sauvegardes, notifications,
suppression, déconnexion - tous testés en conditions réelles.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-17 18:19:51 +02:00
| 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éploie binaires Rust **et** frontend, via un compte `deploy` sans privilège (`ci/README.md` ) |
2026-09-16 22:11:31 +02:00
## 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).
