Homelab
Mon serveur à la maison, entièrement décrit en Ansible.
- Type
- Infrastructure
- Cadre
- Projet personnel
- Année
- 2026
- Technologies
- Ansible, Proxmox, LXC, Docker, Podman, Nginx, fail2ban, GitLab CI, Python, Bash
L’architecture du homelab : un seul point d’entrée, des services isolés
J’héberge mes propres services sur un serveur Proxmox : forge Git et intégration continue, photos, gestionnaire de mots de passe, messagerie, domotique, supervision, bases de données et serveurs de jeu. Chacun vit dans son conteneur, et tout se crée avec une seule commande, par exemple « make deploy immich ».
Concrètement, on y trouve une forge GitLab avec son registre d’images et un runner d’intégration continue, des sites statiques publiés chacun sur leur sous-domaine, MariaDB avec phpMyAdmin, Vaultwarden pour les mots de passe, Immich pour les photos et vidéos, et Stalwart, un serveur mail complet. S’y ajoutent Radiance, mon serveur d’inférence d’IA (texte, image, audio) sur une carte graphique AMD, Hermes, un agent relié à Telegram et Discord, un panneau AMP pour les serveurs de jeu et Home Assistant pour la domotique.
Un catalogue versionné décrit ce que chaque service demande : processeur, mémoire, disques, ports, secrets. La flotte, elle, n’est écrite nulle part. Chaque conteneur créé est étiqueté dans Proxmox, puis redécouvert à chaque exécution. Relancer un déploiement ne casse rien : un conteneur existant est retrouvé, jamais dupliqué, et un secret manquant arrête tout avant la moindre création.
Côté réseau, Nginx est le seul point d’entrée. Les services vivent sur un réseau interne et sont isolés les uns des autres par le pare-feu, dont les règles sont générées automatiquement. Publier un service tient en une option : le sous-domaine, le certificat TLS, les redirections et le pare-feu suivent.
Les données sont séparées du système. Ce qui est irremplaçable va sur un volume sauvegardé, ce qui se re-télécharge sur un volume qui ne l’est pas, et le disque système peut être jeté puis reconstruit. Un conteneur inutilisé s’endort tout seul et se réveille à la première requête.
Le dépôt se teste aussi : la logique côté hôte tourne contre un faux Proxmox, et chaque changement passe par yamllint et ansible-lint.
- Une vingtaine de services au catalogue, 27 rôles Ansible, 17 playbooks
- Nginx en point d’entrée unique : TLS automatique, fail2ban, filtrage par pays
- Réseau interne isolé, pare-feu généré à partir du catalogue
- Sauvegardes planifiées, restauration testée sur une copie isolée, retour arrière par snapshot
- Mise en veille automatique des conteneurs inactifs
- Serveur d’inférence d’IA sur carte graphique, modèles chargés à la demande
Ce qui tourne dessus
Entrée et surveillance
- Nginx
- Seul point d’entrée : TLS automatique, fail2ban, filtrage par pays, relais du mail
- Pare-feu Proxmox
- Règles générées depuis le catalogue, chaque service isolé des autres
- Gatus
- Sondes sur toute la flotte, alertes, état des sauvegardes
Développement
- GitLab CE
- Dépôts, registre d’images, runner CI Docker-in-Docker
- Sites statiques
- Un site par sous-domaine, publié en une commande
- MariaDB
- Bases de données partagées, avec phpMyAdmin
Au quotidien
- Vaultwarden
- Mots de passe, compatible avec les applications Bitwarden
- Immich
- Photos et vidéos, sur un volume dédié et sauvegardé
- Stalwart
- Serveur mail complet : SMTP, IMAP, filtres Sieve
- Home Assistant
- Domotique, en machine virtuelle sur le réseau local
IA et jeux
- Radiance
- Inférence de modèles (texte, image, audio) sur GPU AMD avec ROCm, chargés à la demande
- Hermes
- Agent relié à Telegram et Discord
- AMP
- Panneau de gestion des serveurs de jeu
Socle
- Debian, Docker, Podman
- Gabarits de conteneurs prêts à l’emploi pour tester ou héberger autre chose