Bienvenue sur le Wiki Hexenis.
Ce wiki est la source de vérité vivante du projet Hexenis : un homelab personnel, pensé comme une plateforme d’apprentissage long terme et un lab auto-hébergé en conditions quasi-production.
Il ne s’agit ni d’une documentation marketing, ni d’un manuel académique exhaustif.
C’est un espace de raisonnement technique assumé, destiné avant tout à être relu, compris et questionné dans 6 à 12 mois — voire plus.
Ce wiki existe pour :
- documenter l’infrastructure Hexenis
- formaliser les conventions techniques et organisationnelles
- expliquer les choix d’architecture (et leurs compromis)
- servir de référence lors du développement, du déploiement ou du dépannage
- éviter la redécouverte répétée des mêmes décisions
La priorité est donnée à la compréhension plutôt qu’à la conformité ou à l’exhaustivité.
Hexenis repose sur quelques principes directeurs :
- Clarté avant sophistication
- Expliciter le pourquoi, pas seulement le comment
- Assumer les compromis (simplicité, dette, contraintes perso)
- Éviter le dogmatisme : plusieurs solutions peuvent coexister
- Évolutivité raisonnée : tout n’est pas figé, mais rien n’est implicite
Ce wiki documente donc autant :
- ce qui est en place aujourd’hui
- que ce qui a été envisagé, rejeté ou remis à plus tard
Hexenis s’appuie actuellement sur les briques suivantes :
- OS : Ubuntu Server 24.04
- Déploiement : Docker Compose
- Reverse proxy : Traefik + Let’s Encrypt
- Réseau : WireGuard (topologie hub-and-spoke)
- CI/CD : GitHub Actions avec runner on-prem
- Architecture applicative : Clean Architecture privilégiée
Ces choix ne sont pas neutres et sont documentés dans les pages dédiées.
Le wiki est organisé autour de plusieurs types de contenus :
- infrastructure globale
- réseau et sécurité
- organisation des services
- flux inter-composants
- structure des repositories
- conventions de nommage
- scripts (
deploy.yml, deploy.sh, main.sh)
- gestion des environnements
dev / prod
- bonnes pratiques Bash (mode strict, idempotence)
- déployer un service
- redémarrer proprement
- diagnostiquer un problème
- rollback / recovery
- décisions structurantes
- contexte
- options envisagées
- impacts et limites
- ajouter un nouveau service
- créer un nouveau repo
- intégrer un composant transverse
- réflexions techniques non finalisées
- Commencer par les pages d’architecture globale
- Lire les conventions avant d’ajouter ou modifier quoi que ce soit
- Utiliser les runbooks comme des checklists, pas comme des recettes magiques
- Considérer les ADR comme des instantanés de raisonnement, pas des vérités éternelles
Si une page semble incomplète ou discutable, c’est probablement volontaire.
Hexenis est un projet vivant.
Le wiki aussi.
À terme, ce wiki pourra intégrer :
- des schémas d’architecture plus visuels
- des timelines de décisions
- des checklists de mise en production
- des rétrospectives techniques
- des liens croisés vers incidents réels
Ces évolutions seront intégrées au fil des besoins, pas par anticipation excessive.
Règle implicite du Wiki Hexenis
Si quelque chose est important, il doit être écrit quelque part.
S’il n’est écrit nulle part, il est considéré comme non fiable.