auto-hébergé · 24/7
Homelab
Proxmox, conteneurs et reverse proxy
Un serveur Proxmox, une vingtaine de conteneurs LXC, un reverse proxy Caddy et des sauvegardes — dont ce site, qui tourne dans l’un d’eux.
Pourquoi
Pour apprendre l’infra en la pratiquant, et parce qu’un QA qui ne sait pas où tourne ce qu’il teste rate la moitié des bugs. Le laboratoire sert aussi de bac à sable : une régression de déploiement se voit ici avant de se voir en production.
L’architecture
Proxmox VE 9.2, un hôte unique, et un conteneur LXC par service plutôt qu’une grosse VM : mise à jour indépendante, panne isolée, sauvegarde sélective. On y trouve AdGuard (DNS), Vaultwarden, Immich, Jellyfin, Meilisearch, Miniflux, la suite *arr pour les médias, OpenCloud, et quelques outils maison.
Caddy tient le reverse proxy et les certificats : un bloc par service, TLS automatique, HSTS. Les noms de domaine pointent tous vers la même IP publique, et c’est Caddy qui décide où va la requête.
Ce site tourne dans le conteneur 217 : Node et Express sur le port 3000, Caddy devant, PM2 pour redémarrer le processus. Proxmox Backup Server pour les sauvegardes, rclone pour la copie hors site.
Ce qui a cassé
Une mise à jour de Proxmox a changé le comportement du réseau des conteneurs : plus de sortie internet, alors que tout le reste répondait. Le diagnostic a pris une heure, moins à cause du problème que parce que je cherchais au mauvais endroit — dans les conteneurs, alors que la panne était sur l’hôte.
Deuxième classique : une sauvegarde « réussie » qui ne restaurait rien. Le job tournait, le fichier existait, et la restauration échouait sur une dépendance manquante. Depuis, une sauvegarde n’est considérée comme valide que si une restauration a été testée.
Ce que j’en garde
Trois habitudes qui viennent de là et qui servent tous les jours en QA : isoler avant de réparer, lire les logs de celui qui se plaint de l’erreur — pas seulement celui qui la produit — et ne jamais croire un voyant vert sans l’avoir fait mentir une fois.