Adam Belkacemi a639b705a6

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

7.8 KiB Raw Blame History