a639b705a6
À 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>
123 lines
7.8 KiB
Markdown
123 lines
7.8 KiB
Markdown
# 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.)
|
|
+-------------------------+
|
|
/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
|
|
|
|
|
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, 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.
|
|
|
|
## État réel
|
|
|
|
| Composant | État |
|
|
|---|---|
|
|
| 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` |
|
|
| 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, 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 |
|
|
| `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éploie binaires Rust **et** frontend, 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).
|