# 🏡 Cher Voisin ### Un mini cloud distribué, fédéré entre amis, entièrement autofinancé --- ## ✨ Le pitch en une phrase **Cher Voisin**, c'est un cloud privé qu'on construit ensemble, chez nous, en mutualisant nos machines pour créer un terrain de jeu technique partagé où chacun peut déployer des VMs réparties sur plusieurs sites physiques, expérimenter des architectures distribuées réelles, héberger ses projets et apprendre au passage. Zéro abonnement cloud. Zéro dépendance à AWS, GCP ou Azure. Juste nos machines, la fibre de nos box, et quelques outils open source bien choisis. --- ## 🎬 Le teaser Imagine. Tu veux monter un cluster Kafka sur 3 machines physiquement séparées pour comprendre comment la réplication gère les partitions réseau. Normalement, tu dois : - Louer 3 VMs chez DigitalOcean → ~30€/mois pour rien - Ou bricoler tout sur ton seul Proxmox local → pas vraiment distribué - Ou passer 3h à configurer WireGuard, des ACLs, des règles de firewall Avec **Cher Voisin** : ``` $ curl -X POST https://api.chervoisin.local/vms \ -d '{"count": 3, "cpu": 1, "ram": 1024, "spread": true}' → VM-1 créée à Lyon (chez Pierre) → VM-2 créée à Paris (chez Jacques) → VM-3 créée à Nantes (chez Jean) → Réseau mesh établi entre les 3 → SSH prêt en 45 secondes ``` Tu te connectes, tu installes Kafka, tu débranches la box de Jacques pour simuler une panne, tu observes ce qui se passe. Tu apprends pour de vrai. Quand tu as fini, les VMs sont automatiquement supprimées. Aucune trace, aucun coût. --- ## 🎯 La vision Cher Voisin, c'est **quatre ambitions** qui s'articulent : ### 1. Un vrai terrain de jeu pour les systèmes distribués Comprendre la théorie, c'est bien. Mais rien ne remplace la confrontation au réel. Tester Kubernetes sur un seul hôte Docker, ce n'est pas tester Kubernetes. Un cluster Cassandra qui ne subit jamais de partition réseau ne t'apprend rien sur les vrais problèmes distribués. Avec Cher Voisin, nos VMs sont **physiquement séparées, chacune derrière une box différente**. Les latences sont réelles, les pannes sont réelles, les partitions réseau se produisent naturellement. C'est le labo qu'on ne peut pas reproduire sur un seul laptop. ### 2. Un support pédagogique concret Pour ceux d'entre nous qui enseignent, animent des workshops ou forment des apprenants, Cher Voisin devient **l'infrastructure de démonstration idéale**. On peut faire vivre à des étudiants la création d'un vrai cluster multi-sites, leur montrer un NAT traversal en action, leur faire déboguer une défaillance réseau authentique. Difficile de faire plus parlant. ### 3. Un hébergement partagé pour nos projets perso Une API Express, un bot Discord, un site personnel, un Nextcloud, un serveur Git privé, un dashboard Grafana… chacun peut faire tourner ses projets sur sa part des ressources. On arrête de payer des VPS inutiles chez OVH ou Hetzner pour héberger deux apps qui tournent 1% du temps. ### 4. Une communauté d'entraide tech Enfin, et c'est peut-être le plus important : **partager, s'entraider, apprendre à plusieurs**. On se débloque entre nous, on partage nos découvertes, on monte ensemble en compétence sur des sujets souvent opaques (réseau, systèmes distribués, infra). Un groupe WhatsApp, des sessions de pair programming, des démos informelles. La techno n'est qu'un prétexte. --- ## 🏗️ Comment ça marche : l'architecture ### Vue d'ensemble ``` ┌────────────────────────────────┐ │ Serveur central (gratuit) │ │ sur Oracle Cloud Free Tier │ │ │ │ • Headscale (coordination) │ │ • Orchestrateur (API) │ │ • Dashboard web │ │ • Monitoring │ └────────────────┬───────────────┘ │ (coordination légère seulement, pas de données) │ ┌───────────────────────┼───────────────────────┐ │ │ │ ┌────▼────┐ ┌────▼────┐ ┌────▼────┐ │ Lyon │ │ Paris │ │ Nantes │ │ (Pierre)│ │(Jacques)│ │ (Jean) │ │ │ │ │ │ │ │ Proxmox │◄─── mesh ──►│ Proxmox │◄─── mesh ──►│ Proxmox │ │ + VMs │ WireGuard │ + VMs │ WireGuard │ + VMs │ │ │ P2P │ │ P2P │ │ └─────────┘ └─────────┘ └─────────┘ ▲ ▲ ▲ │ │ │ └───────────────────────┼───────────────────────┘ │ ┌──────────┴──────────┐ │ Utilisateurs │ │ (laptops, mobiles) │ └─────────────────────┘ ═══════════════════════════════════════════════════════ TOUT LE TRAFIC DE DONNÉES passe directement en P2P entre les sites et les utilisateurs, jamais par le serveur central. Chiffré de bout en bout. ═══════════════════════════════════════════════════════ ``` ### Les 3 couches à comprendre #### Couche 1 : Les sites physiques Chaque partenaire héberge **chez lui** : - Un hyperviseur **Proxmox VE** (le logiciel qui permet de créer des VMs) - Une machine physique modeste (typiquement un laptop recyclé) - Sa connexion fibre habituelle - Une petite **LXC** qui expose une **API locale** pour créer/détruire des VMs > **💡 C'est quoi une LXC ?** > > Une LXC (Linux Container) est un "mini-conteneur système" supporté nativement par Proxmox. C'est comme une VM, mais beaucoup plus léger : partage du noyau Linux avec l'hôte, démarrage en quelques secondes, consommation mémoire très faible (typiquement 50-200 Mo). > > On l'utilise ici pour héberger notre petite API locale qui communique avec Proxmox. Pas besoin d'une VM complète pour faire tourner un petit service Node.js/Express. Pense-la comme un "Docker plus proche du système", intégré à Proxmox. > > En pratique : on crée une LXC Debian minimaliste, on installe Node.js dedans, on y lance notre API Express, et c'est fini. Chaque site est **100% autonome**. Si le site de Jacques tombe, les sites de Jean et de Pierre continuent à fonctionner normalement. Pas de dépendance croisée au niveau matériel. #### Couche 2 : Le réseau mesh C'est la partie la plus importante à comprendre du projet. On y consacre une section entière plus bas : **"La partie réseau expliquée simplement"**. Prends quelques minutes pour la lire, c'est fondamental. #### Couche 3 : L'orchestrateur Un petit cerveau central (API en **Express** + petite base Postgres) qui : 1. Authentifie les utilisateurs (login via GitHub ou Google OAuth) 2. Reçoit les demandes de création de VMs 3. Choisit sur quels sites les créer (en fonction des ressources disponibles) 4. Appelle les APIs locales de chaque site 5. Enregistre les VMs créées avec leur TTL (durée de vie) 6. Supprime automatiquement les VMs expirées **L'orchestrateur est volontairement mince**. Il ne stocke pas d'état critique. Si on doit le redémarrer, les VMs existantes continuent de fonctionner. --- ## 🌐 La partie réseau expliquée simplement Cette section est **essentielle** pour comprendre comment Cher Voisin est à la fois distribué et sécurisé. On va y aller pas à pas. ### Le problème à résoudre On a 3 machines, chez Pierre, Jacques et Jean. Chacune est derrière une box internet (Freebox). Sur chaque machine, des VMs tournent. On veut que : 1. ✅ Toutes les VMs puissent se parler **comme si elles étaient sur le même réseau local** 2. ✅ Nous-mêmes (depuis nos laptops) puissions accéder à ces VMs **sans configurer quoi que ce soit** 3. ✅ **Personne d'autre sur internet** ne puisse voir ou accéder à nos machines 4. ✅ Ne **rien ouvrir** sur nos box (aucun port exposé) ### Qu'est-ce qu'un réseau "mesh" ? Un réseau mesh, c'est un réseau où **chaque machine est connectée directement à chaque autre machine**, sans passer par un point central. #### Comparaison avec un réseau classique **Réseau centralisé classique** (ce que tu connais peut-être) : ``` ┌────────┐ │ Serveur│ │ central│ └───┬────┘ ┌────┼────┬────┐ │ │ │ │ ┌───▼┐ ┌─▼─┐ ┌▼─┐ ┌▼─┐ │ PC1│ │PC2│ │PC3│ │PC4│ └────┘ └───┘ └───┘ └───┘ Tout le trafic passe par le serveur central. Si le serveur tombe → tout casse. Le serveur voit tout. ``` **Réseau mesh** : ``` ┌────┐ ┌────┐ │ PC1│──────────│ PC2│ └─┬──┘ └──┬─┘ │ \ / │ │ \ / │ │ \ / │ │ / \ │ │ / \ │ │ / \ │ ┌─▼──┐ ┌──▼─┐ │ PC3│──────────│ PC4│ └────┘ └────┘ Chaque machine parle directement aux autres. Si une tombe → les autres continuent. Pas de serveur qui "voit" le trafic. ``` C'est un peu comme la différence entre **appeler un ami via un standardiste** (centralisé) et **appeler en direct sur son portable** (mesh). ### Pourquoi un mesh pour nous ? Parce qu'on veut que : - Le trafic entre nos VMs soit **rapide** (pas de détour par un serveur central) - Notre projet **continue à fonctionner** même si un membre est déconnecté - **Aucune entreprise tierce** ne puisse voir nos données ### Le problème des box internet Sauf qu'établir une connexion mesh entre machines situées chez des gens différents, c'est compliqué : - Chaque machine est **derrière une box** (la Freebox) - La box fait du **NAT** (elle masque les machines internes derrière une seule IP publique) - Par défaut, deux machines derrière deux box différentes **ne peuvent pas se voir directement** C'est comme deux personnes dans deux immeubles : sans le numéro d'appartement et sans interphone qui fonctionne, elles ne peuvent pas se joindre. ### La solution : un "serveur de coordination" Pour que les machines se trouvent et s'authentifient mutuellement, il faut un **annuaire central**. C'est là qu'intervient **Headscale**. ``` ┌─────────────────────────────┐ │ Headscale (l'annuaire) │ │ = serveur de coordination │ │ │ │ "Je connais Pierre, Jacques│ │ et Jean. Voici leurs │ │ coordonnées et clés." │ └──────────────┬──────────────┘ │ │ Chaque machine se │ connecte ici pour : │ - s'authentifier │ - obtenir la liste │ des autres │ - recevoir les │ règles d'accès │ ┌───────────────────┼───────────────────┐ │ │ │ ┌──▼──┐ ┌──▼──┐ ┌──▼──┐ │Lyon │ │Paris│ │Nantes│ └──┬──┘ └──┬──┘ └──┬──┘ │ │ │ └───────────────────┼───────────────────┘ │ Une fois qu'elles se connaissent, les machines communiquent DIRECTEMENT entre elles : │ ┌───────────────────┼───────────────────┐ │ │ │ ┌──▼──┐◄─── mesh ────►┌──▼──┐◄─── mesh ──►┌──▼──┐ │Lyon │ P2P direct │Paris│ P2P direct│Nantes│ └─────┘ └─────┘ └─────┘ 🔒 Tout ce trafic est chiffré de bout en bout 🔒 Personne (pas même Headscale) ne peut le lire ``` ### Le rôle exact de Headscale (à bien comprendre) Headscale fait **uniquement** : - ✅ **Authentification** : "Est-ce bien Pierre qui se connecte ?" - ✅ **Annuaire** : "Voici la liste des autres membres et comment les joindre" - ✅ **Règles d'accès** : "Pierre a le droit de parler à telle VM, pas à telle autre" Headscale ne fait **jamais** : - ❌ Voir le contenu du trafic - ❌ Faire transiter les données (fichiers, messages, requêtes HTTP) - ❌ Stocker quoi que ce soit de ce qui circule entre les VMs **Analogie** : Headscale, c'est comme **l'accueil d'un hôtel**. L'accueil sait qui est dans quelle chambre et peut confirmer ton identité quand tu rentres. Mais l'accueil n'écoute pas ce que tu dis dans ta chambre et ne lit pas tes messages. ### Le trafic en direct : WireGuard Une fois que Headscale a présenté les machines entre elles, elles établissent des **tunnels chiffrés directs** en utilisant une technologie appelée **WireGuard**. > **💡 C'est quoi WireGuard ?** > > WireGuard est un protocole de VPN moderne, simple, et extrêmement rapide. Il a été intégré au noyau Linux officiel en 2020. Il chiffre tout le trafic entre deux machines, et rien ne peut le lire en chemin. > > Concrètement, quand ton laptop veut parler à une VM chez Jean, WireGuard crée un "tunnel" chiffré directement entre les deux, à travers internet. Personne en chemin (ni Free, ni ton FAI, ni Jean, ni Pierre, ni Headscale, ni même la NSA 😉) ne peut voir ce qui transite dans ce tunnel. > > C'est l'équivalent d'un tuyau privé et chiffré posé par-dessus internet, entre chaque paire de machines du réseau. ### Distinction importante : Headscale (le serveur) vs Tailscale (les clients) C'est le point qui prête souvent à confusion. Prenons le temps d'éclaircir ça avec un schéma dédié : ``` ┌─────────────────────────────────────────────────────────┐ │ │ │ Côté serveur (chez nous, sur Oracle Cloud Free) : │ │ │ │ ┌──────────────────────────────────────┐ │ │ │ HEADSCALE │ │ │ │ = le serveur de coordination │ │ │ │ = l'annuaire qui connaît tout le │ │ │ │ monde et authentifie │ │ │ │ (open source, self-hosted par nous) │ │ │ └──────────────────────────────────────┘ │ │ ▲ │ │ │ (chaque client se connecte ici) │ │ │ │ │ Côté clients (sur chaque machine) : │ │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ CLIENT │ │ CLIENT │ │ CLIENT │ │ │ │ TAILSCALE│ │ TAILSCALE│ │ TAILSCALE│ │ │ │ │ │ │ │ │ │ │ │ (Proxmox │ │ (Proxmox │ │ (laptop │ │ │ │ Lyon) │ │ Paris) │ │ Jean) │ │ │ └──────────┘ └──────────┘ └──────────┘ │ │ │ └─────────────────────────────────────────────────────────┘ ``` **Deux composants, deux rôles distincts :** | | Headscale | Tailscale (les clients) | |---|---|---| | **Où ça tourne** | Sur notre VPS Oracle | Sur chaque machine (Proxmox, VM, laptop) | | **Rôle** | Annuaire + authentification | Agent qui gère les tunnels WireGuard | | **Open source** | Oui | Oui | | **Hébergé par** | Nous (Cher Voisin) | Installé par chaque utilisateur | **Le point clé** : Tailscale est une entreprise qui propose à la fois (1) un serveur de coordination commercial (qu'on n'utilise pas) et (2) d'excellents clients open source (qu'on utilise). Headscale est une réimplémentation open source du serveur, compatible avec ces mêmes clients. **Notre combo** : les clients officiels Tailscale (qualité excellente) + notre propre Headscale (contrôle total). ### Et depuis l'extérieur ? Personne ne voit rien C'est le point crucial pour la sécurité. Imagine un scanner d'internet qui essaie de voir ce qui tourne chez Pierre : ``` Internet (script kiddie / robot de scan) │ │ ping 82.45.xx.xx (IP publique de la box de Pierre) │ essaie port 22, 80, 443, 8006, 3306, 6379... ▼ ┌──────────────────────────────┐ │ Box de Pierre │ │ ❌ Aucun port ouvert │ │ 🔒 Refus total │ └──────────────────────────────┘ │ ▼ ⛔ RIEN. Mur. Silence radio. Même temps, à l'intérieur du mesh : Laptop de Jean (dans le mesh) │ │ ping vm-pierre-042 (nom privé du mesh) ▼ ┌──────────────────────────────┐ │ VM de Pierre │ │ ✅ accessible, chiffré │ │ via WireGuard │ └──────────────────────────────┘ │ ▼ ✅ Communication fluide et sécurisée ``` **Pourquoi c'est possible ?** Les tunnels WireGuard ne sont pas établis "en attente" comme un port ouvert classique. Ils sont établis **à la demande**, à partir d'une connexion sortante initiée par la machine elle-même. C'est comme si : - La box d'un membre gardait toutes ses portes **fermées de l'extérieur** - Mais que les machines à l'intérieur pouvaient **sortir** pour se connecter à Headscale - Puis **revenir** via le tunnel qu'elles ont elles-mêmes créé Aucune porte n'est ouverte de l'extérieur. Aucune porte n'est scannable. Le réseau mesh est **littéralement invisible depuis internet**. ### Récap simple 1. **Le mesh** = un réseau privé chiffré, où chaque machine parle directement aux autres 2. **Headscale** = l'annuaire + douanier qui dit qui a le droit d'entrer 3. **Clients Tailscale** = les agents sur chaque machine qui créent les tunnels 4. **WireGuard** = la technologie de chiffrement des tunnels (un "super-VPN" moderne) 5. **Résultat** = un réseau privé invisible depuis internet, sans rien ouvrir sur nos box --- ## 🔧 Les outils choisis, et pourquoi ### Proxmox VE — l'hyperviseur **Pourquoi** : gratuit, open source, mature, excellente API REST. Interface web propre. Supporte nativement les templates cloud-init (pour injecter config et clés SSH dans les VMs à leur création). C'est le standard de facto du homelab en 2026. **Alternative envisagée** : ESXi (propriétaire, licences) ou KVM brut (pas d'interface, plus de boulot). Proxmox gagne sur tous les tableaux. ### Headscale + clients Tailscale — le réseau mesh Voir la section précédente "La partie réseau expliquée simplement". **En un mot** : les clients Tailscale officiels (open source, qualité excellente), pointés vers notre propre Headscale (hébergé sur Oracle Cloud). Gratuit, illimité, contrôle total. ### Express + Node.js — pour l'orchestrateur et les APIs locales **Pourquoi** : framework backend Node.js de référence, écosystème énorme, familier pour quiconque a déjà fait du web backend en JavaScript. Surface d'attaque minimale, middleware bien connus (helmet, cors, express-rate-limit). Correspond aux compétences des membres du projet. **Alternatives envisagées** : Python/FastAPI, Go, Fastify. Pertinentes mais Node.js/Express est ce qu'on connaît le mieux, et pour un projet pédagogique, la familiarité prime. ### Postgres — la base de données **Pourquoi** : pour stocker les users, les quotas, les VMs actives, les historiques. Quelques tables, simple mais robuste. SQLite pourrait suffire au début mais Postgres nous donne de la marge pour évoluer. ### Oracle Cloud Free Tier — l'hébergement du serveur central **Pourquoi** : **gratuit à vie**, pas juste pendant 12 mois comme AWS. Offre généreuse (une instance ARM avec 2 CPU + 8 Go RAM suffit largement). 10 To de trafic mensuel inclus. **Alternative envisagée** : un VPS chez Hetzner à ~4€/mois en backup si Oracle pose problème. ### GitHub OAuth + Google OAuth — l'authentification **Pourquoi deux providers ?** Pour laisser à chacun le choix. Certains préfèrent leur compte pro Google, d'autres leur identité de développeur GitHub. Tous les membres ont au moins l'un des deux, donc on couvre tout le monde sans friction. **Avantages** : - Aucun mot de passe à gérer côté Cher Voisin - Aucune base utilisateurs à protéger - Un clic pour s'inscrire, un clic pour se connecter - Révocation possible côté Google/GitHub si besoin **Implémentation technique** : `passport-github2` et `passport-google-oauth20` côté Express. Au moment de la connexion, l'utilisateur choisit son provider. Le compte interne Cher Voisin est lié à son identifiant GitHub ou Google. ### DNS local du mesh (MagicDNS) — manipuler des noms, pas des IPs C'est une **fonctionnalité clé** du client Tailscale qu'on active : **MagicDNS**. **Principe** : chaque machine du mesh reçoit un nom DNS automatique, résolvable **uniquement à l'intérieur du mesh**. ``` Sans DNS local : Avec MagicDNS : ─────────────── ────────────── $ ssh 100.64.0.42 $ ssh vm-pierre-api $ curl http://100.64.0.47:3000 $ curl http://vm-jean-db:3000 $ ping 100.64.0.31 $ ping proxmox-lyon ``` **Pourquoi c'est utile** : - **Lisibilité** : plus facile de retenir `redis-cluster` que `100.64.0.44` - **Flexibilité** : si on recrée une VM, elle peut garder le même nom (même si l'IP change) - **Configuration applicative** : dans ton code, tu mets `DB_HOST=postgres-prod` au lieu de coder en dur une IP - **Invisible depuis internet** : ces noms ne résolvent **qu'à travers le mesh**. De l'extérieur, `vm-pierre-api.chervoisin` n'existe pas **Exemple concret** : ```js // Dans ton app Express déployée sur une VM const pg = new Client({ host: 'postgres-jean', // résolu via MagicDNS port: 5432, user: 'app' }); ``` Pas besoin de connaître l'IP réelle. Si Jean réinstalle sa VM Postgres, tant que le nom reste `postgres-jean`, tes apps continuent de fonctionner. **Ajout optionnel** : pour aller plus loin, on peut déployer un Pi-hole ou un CoreDNS dans le mesh pour avoir du DNS avancé (enregistrements personnalisés, alias, etc.). C'est pour plus tard. --- ## 💡 Cas d'usage concrets ### Exemple 1 : Expérimenter un cluster Kafka multi-datacenters **Scénario** : tu veux comprendre comment Kafka gère la réplication inter-datacenters, le `min.insync.replicas`, les élections de leader quand un broker tombe. **Avec Cher Voisin** : ```bash # Créer 3 brokers Kafka, un par site $ chervoisin vms create --count 3 --cpu 2 --ram 4096 --spread --ttl 48h # Les VMs apparaissent : → broker-1 (100.64.0.21) à Lyon (chez Pierre) → broker-2 (100.64.0.22) à Paris (chez Jacques) → broker-3 (100.64.0.23) à Nantes (chez Jean) # Installer Kafka en cluster $ for i in 1 2 3; do ssh broker-$i ./setup-kafka.sh $i; done # Produire un flux de messages depuis ton laptop $ kcat -b broker-1:9092 -P -t events # Éteindre physiquement la box de Paris pour simuler une panne # (appeler Jacques : "débranche ta box pour 2 minutes") → Observer : élection de nouveau leader, production continue → Rebrancher : observer la resynchronisation ``` **Ce que tu apprends pour de vrai** : les timeouts réels, les logs d'élection, le comportement face à une vraie partition réseau. Impossible à vivre sur un Docker Compose local. ### Exemple 2 : Déployer un cluster Kubernetes distribué (K3s) **Scénario** : tu veux monter un cluster K8s multi-noeuds et tester la résilience des pods. ```bash # 1 control plane + 2 workers, chacun sur un site différent $ chervoisin vms create --role control --site lyon --cpu 2 --ram 2048 $ chervoisin vms create --role worker --site paris --cpu 2 --ram 2048 $ chervoisin vms create --role worker --site nantes --cpu 2 --ram 2048 # Installer K3s $ ssh cp-1 "curl -sfL https://get.k3s.io | sh -" $ ssh worker-1 "curl -sfL ... K3S_URL=https://cp-1:6443 ..." $ ssh worker-2 "curl -sfL ... K3S_URL=https://cp-1:6443 ..." # Déployer une app distribuée (par exemple, un petit service Node.js) $ kubectl apply -f my-app.yaml --replicas=6 → Pods répartis entre les 3 sites automatiquement par K8s # Tester la tolérance aux pannes $ chervoisin vms stop worker-1 → K8s replanifie les pods sur les autres workers ``` ### Exemple 3 : Pédagogie en workshop (étudiants) **Scénario** : tu animes un workshop de 2 jours sur les systèmes distribués pour 10 étudiants. ```bash # Au début du workshop, provisionner 10 environnements identiques $ for student in amelie benoit chloe ...; do chervoisin vms create --user $student --count 3 --ttl 2d done → Chaque étudiant reçoit 3 VMs, isolées des autres (ACLs strictes) → Chacun a son identifiant, son accès SSH via Tailscale SSH → Chacun fait les exercices sur son environnement personnel ``` **Les étudiants manipulent du réel**, pas une simulation. À la fin du workshop, tout est supprimé automatiquement. ### Exemple 4 : Héberger ses projets perso **Scénario** : Jean développe un bot Discord + une petite API pour son projet associatif. Au lieu de payer un VPS, il utilise Cher Voisin. ```bash $ chervoisin vms create --name bot-discord --cpu 1 --ram 512 --persistent → VM persistante, accessible via le mesh par son nom MagicDNS → Jean déploie son bot dessus ``` Pour rendre le bot/API accessible depuis internet, voir la section **"Exposer des services publiquement"** plus bas. ### Exemple 5 : Labs de test "qu'est-ce qui se passe si…" **Scénario** : tu lis un article sur le CAP theorem et tu veux vraiment voir ce qui se passe pendant une partition réseau. ```bash # Créer une petite base MongoDB en cluster $ chervoisin vms create --count 3 --spread # Simuler une partition réseau en bloquant le trafic entre deux sites $ chervoisin net block --from lyon --to paris → Observer : le primary passe en secondary → Lire et écrire dans chaque "moitié" du cluster → Restaurer le réseau : observer la résolution du split-brain $ chervoisin net restore ``` Cette capacité à **injecter des pannes réseau contrôlées** est particulièrement difficile à reproduire sur un cloud public. Ici, on contrôle tout. ### Exemple 6 : Bac à sable pour essais hebdo Besoin de tester rapidement une nouvelle techno (RabbitMQ, TimescaleDB, ClickHouse…) sans polluer ton Proxmox perso ? ```bash $ chervoisin vms create --name test-clickhouse --ttl 4h # ... tests ... # 4h plus tard, la VM est automatiquement détruite ``` --- ## 🌍 Exposer des services publiquement (phase ultérieure) Par défaut, les services déployés dans Cher Voisin ne sont accessibles **que depuis le mesh** (c'est voulu pour la sécurité). Mais un des objectifs du projet est de pouvoir aussi **héberger des services accessibles au public** : sites web, APIs, bots, etc. Cette partie fera l'objet d'une **réflexion dédiée dans une phase ultérieure**. Voici simplement les options qu'on envisage, à débattre collectivement : ### Option A : Cloudflare Tunnels Un tunnel sortant de la VM vers Cloudflare, qui sert d'entrée publique avec HTTPS automatique. - ✅ Gratuit - ✅ Aucun port ouvert sur les box - ✅ HTTPS + DDoS inclus - ⚠️ Adapté surtout à HTTP/HTTPS ### Option B : Reverse proxy centralisé sur le VPS Oracle Utiliser notre VPS Oracle comme point d'entrée public, avec Caddy ou Nginx qui route vers les VMs via le mesh. - ✅ Contrôle total - ✅ Supporte TCP/UDP (Redis, BDD, etc.) - ⚠️ Goulot d'étranglement unique ### Option C : Port forwarding sur une box Ouvrir des ports sur la box d'un membre. Rapide mais fragile. - ⚠️ Sécurité réduite, IP dynamique, CGNAT partiel chez Free **Pour le MVP, on se concentre sur le mesh privé**. L'exposition publique viendra dans une phase dédiée avec sa propre discussion et mise en place. --- ## 👥 Rejoindre le projet : ce que chacun apporte ### 1. Du matériel qui tourne 24/7 #### Configuration idéale recommandée ``` ┌──────────────────────────────────────┐ │ Spécifications recommandées │ ├──────────────────────────────────────┤ │ Processeur : Intel Core i5 ou │ │ équivalent (Ryzen 5+) │ │ RAM : 16 Go minimum │ │ Stockage : 256 Go SSD minimum │ │ Réseau : Ethernet gigabit │ └──────────────────────────────────────┘ ``` Cette config permet de faire tourner confortablement Proxmox + 3-4 VMs simultanées avec une bonne réactivité. #### Profils matériels ##### ✅ Profil recommandé : Laptop recyclé **Exemples** : ThinkPad T480/T490 récupéré, Dell Latitude, MacBook Pro 2018+, ordinateur portable pro qui dort dans un placard. - La batterie fait office d'onduleur gratuit en cas de coupure EDF ⚡ - Écran fermé, juste branché en Ethernet - Consommation : **15-30 W** selon le modèle - Coût d'acquisition : **idéalement 0€** (recyclage) 👉 C'est **le profil qu'on privilégie** pour Cher Voisin. Écologique, économique, cohérent avec l'esprit "zéro coût" du projet. **Pourquoi ?** Parce qu'on veut prouver qu'on peut monter un cloud distribué avec du matériel qu'on a **déjà** sous la main. Pas besoin d'acheter du neuf pour expérimenter. **Astuce** : si tu n'as rien sous la main, tente ta chance en demandant autour de toi (famille, ex-employeur, asso) — il y a souvent des laptops pros de 3-5 ans qui dorment. ##### ⚠️ Profil optionnel : Mini PC neuf (si vraiment rien à recycler) **Exemples** : Beelink SER5 (~280€), Minisforum UM690 (~380€), NiPoGi AM06 (~250€) - CPU Ryzen 5/7 ou équivalent - RAM : 16-32 Go - Stockage : SSD 512 Go - Consommation électrique : **10-20 W** 👉 Excellent ratio perf/consommation/bruit. Silencieux, compact, fiable. **À considérer seulement si** : tu n'as vraiment rien à recycler et que tu es prêt à investir. On part sur du recyclage autant que possible. ### 2. Plusieurs machines chez un même membre **Question importante** : qu'est-ce qui se passe si Pierre a deux laptops qu'il veut intégrer au réseau ? Ou si Jacques a à la fois un mini PC et un vieux desktop ? **C'est parfaitement supportable**, voire encouragé. Cela renforce la capacité totale du réseau. #### Scénario privilégié : plusieurs Proxmox indépendants sur le même site Pierre a deux laptops, tous deux installés avec Proxmox, tous deux reliés à sa box par Ethernet. On les considère comme **deux noeuds Cher Voisin séparés** : ``` Site "Lyon" (chez Pierre) ┌─────────────────────────────┐ │ │ │ ┌──────────┐ ┌──────────┐ │ │ │ Proxmox │ │ Proxmox │ │ │ │ lyon-1 │ │ lyon-2 │ │ │ │ (laptop1)│ │ (laptop2)│ │ │ └────┬─────┘ └─────┬────┘ │ │ │ │ │ │ └──────┬───────┘ │ │ │ │ │ ┌─────▼──────┐ │ │ │ Freebox │ │ │ │ Pierre │ │ │ └─────┬──────┘ │ └──────────────┼──────────────┘ │ Internet ``` Chaque machine : - A son propre agent Tailscale installé (chaque machine = un nœud du mesh) - A sa propre IP du mesh (ex : `100.64.0.10` et `100.64.0.11`) - Est visible dans le dashboard comme un site physique distinct (`lyon-1`, `lyon-2`) - Contribue indépendamment en CPU/RAM au pool total de ressources **Avantage** : si un laptop tombe, l'autre continue à servir. Plus de résilience même au sein d'un seul site physique. **Cas typique** : Pierre met un vieux ThinkPad en ligne, puis 3 mois plus tard récupère un deuxième laptop pro. Il l'ajoute simplement au réseau comme nouveau nœud, et sa capacité de contribution double. Rien à reconfigurer pour les autres membres. #### Option avancée : Cluster Proxmox (pour plus tard) Proxmox supporte nativement le **clustering** : plusieurs machines physiques regroupées en un seul cluster, avec migration live des VMs entre elles. C'est plus avancé mais très puissant. On y reviendra dans une phase ultérieure. **Pour commencer**, on préconise deux Proxmox indépendants, c'est plus simple. ### 3. Une connexion fibre **C'est un prérequis.** Avec la fibre française standard (Free, Orange, Sosh, SFR…), on a : - Du débit symétrique ou presque (important pour l'upload inter-sites) - Un NAT permissif qui permet aux connexions P2P de s'établir directement - Une latence faible entre les villes (typiquement 5-30ms) L'ADSL ou le 4G ne fonctionneraient pas bien : trop de latence, upload faible, NAT souvent plus restrictif. ### 4. Un peu de temps pour le setup initial - Installation de Proxmox : **1-2 heures** - Configuration réseau de base + template Ubuntu + cloud-init : **1-2 heures** - Tests : **1 heure** **Total : une demi-journée en moyenne.** Un guide détaillé sera fourni en temps voulu. Une fois le site opérationnel, la maintenance est quasi nulle. ### 5. Compétences techniques - Savoir lire une doc technique en anglais - Être à l'aise avec une ligne de commande Linux - Comprendre les bases du réseau (IP, DNS, ports) **Pas besoin d'être expert réseau ou admin système.** Le projet est précisément conçu pour que chacun monte en compétence au passage. --- ## 👤 Dashboard utilisateur et quotas ### Création de compte Chaque membre crée un compte sur le dashboard Cher Voisin via **GitHub OAuth ou Google OAuth** (au choix). À l'inscription, un compte individuel est créé, avec : - Son identifiant - Son avatar (récupéré de GitHub/Google) - Ses **quotas** par défaut - Sa clé publique SSH optionnelle (pour l'injection cloud-init) ### Les quotas : pour que personne ne monopolise les ressources Pour éviter qu'un membre surconsomme et pénalise les autres, chaque compte a des **limites strictes sur les ressources simultanées** qu'il peut consommer : | Ressource | Quota par défaut | Remarques | |---|---|---| | CPUs / threads simultanés | 8 threads max | Suffit pour 4 VMs de 2 vCPUs | | RAM simultanée | 16 Go max | Suffit pour plusieurs VMs moyennes | | Stockage total | 100 Go max | Somme des disques de ses VMs | | Nombre de VMs simultanées | 10 max | Évite la prolifération | | Durée de vie max par VM | 30 jours | Forçage du renouvellement/cleanup | Ces quotas sont **paramétrables par l'admin**. Ils peuvent être ajustés : - Temporairement (pendant un workshop, un user a besoin de plus) - Durablement (un membre contribue un gros serveur, il récupère plus de droits) **Règle simple et équitable** : **chaque membre qui apporte du matériel** a automatiquement un quota proportionnel à ce qu'il met dans le pot commun. Plus tu contribues, plus tu peux consommer. Si tu mets un seul laptop, tu as le quota de base. Si tu en mets deux, tu as le double. ### Dashboard personnel Chaque membre accède à son tableau de bord perso, où il voit : ``` ┌─────────────────────────────────────────────────────┐ │ 🏡 Cher Voisin — Dashboard de Pierre │ ├─────────────────────────────────────────────────────┤ │ │ │ 📊 Ma consommation actuelle │ │ CPUs : 4/8 threads (50%) [████░░░░] │ │ RAM : 6/16 Go (37%) [███░░░░░] │ │ Stockage : 42/100 Go (42%) [████░░░░] │ │ VMs actives : 3/10 │ │ │ │ 🖥️ Mes VMs │ │ ┌──────────────────────────────────────────┐ │ │ │ nom site CPU RAM TTL │ │ │ │ api-prod lyon 2 2G persistent │ │ │ │ redis-test paris 1 1G 3j │ │ │ │ kafka-node-1 nantes 2 2G 5j │ │ │ └──────────────────────────────────────────┘ │ │ │ │ 📈 Métriques temps réel (CPU/RAM/réseau par VM) │ │ [graphiques Grafana intégrés] │ │ │ │ ⚙️ Actions │ │ [+ Créer une VM] [Documentation] [WhatsApp] │ └─────────────────────────────────────────────────────┘ ``` L'admin, quant à lui, voit en plus : - La vue globale sur tous les sites - Les métriques agrégées (usage total, capacité restante) - La liste de tous les membres et leurs quotas - Les logs d'audit (qui a fait quoi, quand) --- ## ⚡ Coûts et consommation électrique ### La facture électrique Prix moyen du kWh en France en 2026 : **~0,25€/kWh** (tarif réglementé EDF Bleu). Calcul : **Coût annuel = Watts × 24h × 365j × 0.25€ / 1000** | Matériel | Conso moyenne | Coût annuel EDF | Coût mensuel | |---|---|---|---| | Laptop recyclé (ThinkPad T480) ⭐ | 20 W | **~44€/an** | ~3,6€/mois | | Mini PC moderne (Beelink, NiPoGi) | 15 W | **~33€/an** | ~2,8€/mois | | Mini PC puissant (Minisforum UM690) | 25 W | **~55€/an** | ~4,6€/mois | | Vieux desktop tour | 60 W | **~131€/an** | ~11€/mois | 👉 **En clair** : pour un laptop recyclé (profil recommandé), on parle de **~3,6€/mois d'électricité**. C'est moins qu'un café. ### Les autres coûts | Poste | Coût | |---|---| | Serveur central (Oracle Cloud Free) | **0€/mois** | | Headscale (auto-hébergé sur Oracle) | **0€** | | Clients Tailscale (open source) | **0€** | | Serveurs DERP relais (utilise ceux de Tailscale, gratuits) | **0€** | | Nom de domaine (optionnel, `chervoisin.cloud` par exemple) | ~20€/an si souhaité plus tard | | Certificat HTTPS (Let's Encrypt) | **0€** | **Total pour le collectif : 0€/mois au démarrage.** ### Comparaison avec une alternative cloud Si on voulait faire la même chose chez AWS/GCP/DigitalOcean : - 3 VMs 1 CPU / 1 Go / 24h / 24 = ~15€/VM/mois = **~45€/mois** - Bande passante inter-régions : ~5-20€/mois supplémentaires - Stockage persistant : ~10€/mois **Soit 60-80€/mois** pour une infra comparable. Sur un an, **720-960€**. Avec Cher Voisin : **0€ direct**, quelques euros d'électricité chacun, et on garde le contrôle total. --- ## 🔐 Les problématiques techniques, et comment on les résout ### Problématique 1 : Sécurité — "on n'expose pas nos maisons sur internet" Résolue par le mesh Headscale/Tailscale : **aucun port ouvert sur nos box**. Tout le trafic sort vers Headscale et revient via des tunnels chiffrés WireGuard. Voir section "La partie réseau expliquée simplement". ### Problématique 2 : Réseau — "comment les VMs de sites différents se parlent-elles ?" Chaque VM rejoint automatiquement le mesh via cloud-init : ```bash # Au premier boot de la VM curl -fsSL https://tailscale.com/install.sh | sh tailscale up --login-server=https://headscale.chervoisin \ --authkey={{PRE_AUTH_KEY}} \ --hostname=vm-pierre-042 ``` En 30 secondes, la VM est joignable par son nom MagicDNS (`vm-pierre-042`) depuis toutes les autres machines du mesh. ### Problématique 3 : Isolation — "Jacques ne doit pas voir les VMs de Pierre" Grâce aux **ACLs** Headscale : ```json { "acls": [ { "action": "accept", "src": ["pierre@github"], "dst": ["tag:user-pierre:*"] }, { "action": "accept", "src": ["jacques@github"], "dst": ["tag:user-jacques:*"] }, // Les VMs d'un user peuvent se parler entre elles { "action": "accept", "src": ["tag:user-pierre"], "dst": ["tag:user-pierre:*"] }, // Les VMs de Pierre ne peuvent pas voir celles de Jacques (refus implicite) ] } ``` ### Problématique 4 : Accès des utilisateurs — "comment gérer les comptes proprement ?" **GitHub OAuth + Google OAuth** pour l'authentification. Pas de mot de passe à gérer, révocation en un clic, chaque membre utilise son identité existante. ### Problématique 5 : Monitoring — "comment savoir ce qui tourne ?" **Prometheus + Grafana** sur le VPS central, qui scrape les métriques des Proxmox via le mesh (pas de ports exposés). Dashboards : usage par site, nombre de VMs, santé du réseau, métriques par utilisateur, accessibles depuis le dashboard perso de chacun. ### Problématique 6 : Gestion du cycle de vie — "pas envie de gérer des zombies" **TTL automatique** sur chaque VM. L'orchestrateur fait un cron toutes les 10 minutes pour supprimer les VMs expirées. ### Problématique 7 : Résilience — "et si un site tombe ?" Chaque site est **autonome**. Si celui de Jacques tombe, les sites de Pierre et Jean continuent. Les VMs sur les sites opérationnels restent accessibles. ### Problématique 8 : Équité — "qu'un membre n'accapare pas tout" Résolue par le système de **quotas** (CPU, RAM, stockage, nombre de VMs) par utilisateur. Voir section "Dashboard utilisateur et quotas". --- ## ⚠️ Risques et limites — soyons honnêtes ### Risque 1 : Oracle Cloud peut changer sa politique de Free Tier **Probabilité** : faible. Le Free Tier existe depuis 2019 et est renforcé avec le temps. **Mitigation** : migration vers Hetzner (~4€/mois) en 30 min grâce à Docker Compose + infra as code. ### Risque 2 : Dépendance aux DERP relays Tailscale **Probabilité** : très faible (engagement public). **Mitigation** : on peut héberger nos propres DERP si besoin (~50 Mo RAM, 30 min de setup). ### Risque 3 : Le serveur central est un SPOF pour les créations de VMs **Impact** : pendant une panne, les VMs existantes continuent de fonctionner. Seules les nouvelles créations sont bloquées. **Mitigation** : backups auto de la base + config Headscale. V2 possible avec redondance. ### Risque 4 : Performance limitée par le maillon faible Si un membre a une fibre très lente en upload, il peut devenir un goulot d'étranglement. **Mitigation** : fibre prérequise, monitoring pour détecter les sites sous-performants. ### Risque 5 : Responsabilité légale **Mitigation** : charte commune signée par tous, logs d'audit, cercle de confiance limité. ### Risque 6 : Courbe d'apprentissage **Mitigation** : guide détaillé, sessions d'onboarding en visio, WhatsApp pour l'entraide. ### Limite 1 : On n'est pas un cloud public Cher Voisin ne remplace pas AWS. Pas de services managés (load balancers, BDD managées, CDN). ### Limite 2 : Pas pour de la production critique Pannes EDF, redémarrages de box… on reste sur du **home cloud pédagogique et perso**. ### Limite 3 : Capacité finie Avec 3 laptops de 16 Go, on a 48 Go RAM total. Suffit pour apprendre, pas pour héberger un SaaS grand public. --- ## 🗺️ La roadmap ### Phase 0 : Préparation individuelle (chacun de son côté) **Prérequis avant tout démarrage collectif.** Chaque partenaire : 1. Choisit/recycle son matériel (idéalement i5, 16 Go RAM, 256 Go SSD minimum) 2. Installe Proxmox VE sur sa machine 3. Configure sa box (IP fixe interne pour Proxmox) 4. Crée un template Ubuntu minimal avec cloud-init activé 5. Teste la création manuelle d'une VM 6. Confirme au groupe que son Proxmox est opérationnel **Durée estimée** : une demi-journée par personne. Un **guide détaillé** sera fourni. On ne passe à la phase 1 que quand **tout le monde a son site prêt**. ### Phase 1 : MVP techniquement fonctionnel - Déploiement de Headscale sur Oracle Cloud - Installation des clients Tailscale sur les 3 Proxmox - Vérification du mesh (ping inter-sites, MagicDNS) - Développement de l'API locale (Express) sur chaque site - Développement de l'orchestrateur central (Express) - Test : création d'une VM via API, accès SSH via le mesh ### Phase 2 : Expérience utilisateur - Dashboard web (Next.js ou Express + HTML) - Auth GitHub + Google OAuth - Gestion des quotas par utilisateur, TTL automatique - ACLs par utilisateur (isolation) - Monitoring basique (Prometheus + Grafana) ### Phase 3 : Ouverture et réflexion sur l'exposition publique - Documentation pour les nouveaux membres - Templates pré-configurés (Kafka, K8s, etc.) - **Étude des options d'exposition publique** (Cloudflare Tunnels, reverse proxy partagé) avec discussion collective - Séances de démonstration pour nos entourages tech ### Phase 4 : Évolution Selon les besoins qui émergent : - Scale à 6-10 sites - Reverse proxy partagé en production - Self-hosted DERP si besoin - Intégration CI/CD - Marketplace de "stacks" partagées **Pas de dates fixées.** On avance au rythme qui nous convient. --- ## ❓ FAQ **Q: Et si je n'ai pas assez de compétences réseau ?** R: C'est précisément l'objectif du projet : apprendre en faisant. Tu n'as pas besoin de maîtriser le réseau au départ. Tu vas progresser naturellement, entouré des autres membres. **Q: Combien de temps ça me prendra par semaine une fois lancé ?** R: En régime de croisière, quasi zéro. Proxmox est stable, le mesh s'auto-maintient. **Q: Qu'est-ce qui se passe si je pars du projet ?** R: Tu récupères ta machine, on retire ton site du mesh, fin. Pas d'engagement. **Q: Est-ce que mes voisins ou mon conjoint verront une différence ?** R: Le Wi-Fi ne sera pas ralenti (trafic séparé). Un laptop/mini PC moderne est silencieux. Conso électrique marginale. **Q: Mes données sont-elles en sécurité ?** R: VMs chez toi, mesh chiffré de bout en bout, serveur central ne voit rien. **Pas de données critiques sur Cher Voisin** cela dit — on reste pédagogique. **Q: On peut vraiment faire tourner ça avec 0€ ?** R: Oui au démarrage. Oracle Free, Headscale open source, Tailscale open source, DERP publics gratuits. Reste juste l'électricité (~3-4€/mois). **Q: J'ai plusieurs machines, je peux toutes les intégrer ?** R: Oui, chaque machine devient un nœud indépendant du mesh, avec ses propres ressources. Ça renforce la capacité totale. Ton quota personnel est augmenté en conséquence. **Q: Et si je veux exposer un site web au public ?** R: Possible, mais pas pour le MVP. On y consacrera une phase dédiée (Cloudflare Tunnels, reverse proxy partagé, etc.). Voir section "Exposer des services publiquement". **Q: Qu'est-ce que je gagne à rejoindre ?** R: (1) Labo distribué réel, (2) Hébergement gratuit projets perso, (3) Communauté d'entraide, (4) Montée en compétences infra/réseau. --- ## 🚀 Et maintenant ? 1. **Lis ce document** (✅ tu y es) 2. **Pose tes questions** sur le groupe WhatsApp qu'on va créer 3. **Décide** si tu veux en être 4. **Prépare ton matériel** (recyclage prioritaire) 5. **Rendez-vous pour la phase 0** : chacun monte son Proxmox local Le projet n'attend pas : on peut démarrer dès que 3 d'entre nous sommes prêts matériellement. --- *Cher Voisin — parce que le meilleur cloud, c'est celui qu'on construit ensemble, chez nous, pour apprendre et créer.*