adam/tripoli.cloud
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
No description
7 commits 1 branch 0 tags 336 KiB
Find a file
Adam Belkacemi 7802c59931 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
ansible Phase 2 : tripoli-edge, service Rust interne derrière Caddy 2026-09-16 22:31:58 +02:00
app Import Tripoli Cloud frontend prototype 2026-09-16 21:21:43 +02:00
bird-lab Phase 6 (bonus) : bird-lab, BGP+BFD entre namespaces (rtnetlink/Bird) 2026-09-17 01:17:15 +02:00
monitoring Phase 5 : observabilité (réutilise le Prometheus/Grafana partagé) 2026-09-16 23:09:32 +02:00
tofu Phase 1 : socle & sécurité (WireGuard, Ansible, OpenTofu) 2026-09-16 22:11:31 +02:00
tripoli-api Phase 3 : tripoli-api (auth, fichiers, PostgreSQL) 2026-09-16 22:43:02 +02:00
tripoli-edge Phase 2 : tripoli-edge, service Rust interne derrière Caddy 2026-09-16 22:31:58 +02:00
tripoli-netctl Phase 4 : tripoli-netctl, labo network namespaces + veth (rtnetlink) 2026-09-16 22:58:53 +02:00
.gitignore Phase 1 : socle & sécurité (WireGuard, Ansible, OpenTofu) 2026-09-16 22:11:31 +02:00
Cargo.lock Phase 4 : tripoli-netctl, labo network namespaces + veth (rtnetlink) 2026-09-16 22:58:53 +02:00
Cargo.toml Phase 4 : tripoli-netctl, labo network namespaces + veth (rtnetlink) 2026-09-16 22:58:53 +02:00
HANDOFF.md Import Tripoli Cloud frontend prototype 2026-09-16 21:21:43 +02:00
README.md Phase 6 (bonus) : bird-lab, BGP+BFD entre namespaces (rtnetlink/Bird) 2026-09-17 01:17:15 +02:00

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

É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é

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