adam/tripoli.cloud
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
tripoli.cloud/README.md
Adam Belkacemi a639b705a6
All checks were successful
CI / build-and-test (push) Successful in 2m14s
Details
CI / deploy (push) Successful in 3m17s
Details
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

7.8 KiB
Raw Permalink Blame History

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).