Mon Homelab ne nécessite pas de maintenance

• Pour réduire la charge d’exploitation de mon Homelab personnel, je me suis concentré sur une configuration à serveur unique et les mises à jour automatiques, au point d’avoir éliminé la plupart des tâches de maintenance courantes
• En consolidant plusieurs serveurs en un seul, la complexité de l’environnement a diminué et la maintenance, en nombre de serveurs, a été réduite de 75 %
• Le Raspberry Pi 4 est confié à Home Assistant OS, et le réseau aux mises à jour automatiques et planifiées d’UniFi, ce qui réduit les points de gestion manuelle
• Les services Docker sont mis à jour via une crontab qui exécute une fois par semaine docker compose pull et docker compose up -d, tandis que la crontab root sert principalement aux sauvegardes
• Sauf urgence, la maintenance mensuelle prend environ 15 minutes, et reporter apt update ainsi qu’un redémarrage n’a quasiment aucun impact immédiat sur les services

---

Une infrastructure simplifiée

• Les services du Homelab ont été consolidés depuis plusieurs machines vers un serveur unique
  • Auparavant, 4 serveurs étaient utilisés ; aujourd’hui, les services sont regroupés sur un seul serveur physique
  • Plutôt qu’un cluster, un hyperviseur ou un cloud hybride, l’exploitation repose sur une seule machine physique dans le sous-sol
  • Cette simplification a réduit la charge de maintenance, en nombre de serveurs, de 75 %
• Un Raspberry Pi 4 existe séparément, mais Home Assistant OS gère ses propres mises à jour, ce qui limite la charge d’administration
  • Techniquement, il ressemble davantage à un serveur, mais à l’usage il se comporte plutôt comme un appareil IoT qui s’entretient lui-même
• Les équipements réseau sont exploités avec une configuration UniFi dans un mini-rack
  • Elle comprend une UniFi Dream Machine Pro, un switch et plusieurs AP
  • La prise en charge des mises à jour automatiques et planifiées évite aussi de devoir intervenir fréquemment à la main sur les équipements réseau

Mises à jour logicielles et sauvegardes automatisées

• Les mises à jour des services Docker sont exécutées chaque semaine via une unique entrée crontab sur le serveur
  • 0 0 * * 0 docker-update
  • docker-update exécute sudo docker compose pull et sudo docker compose up -d dans chaque répertoire sous ~/docker/*/
• La crontab de l’utilisateur root sert surtout aux sauvegardes
  • Elle génère un rapport système quotidien
  • Elle génère des dumps PostgreSQL d’Immich et de Piped
  • Elle sauvegarde avec rsync Plex, le serveur web, la configuration Nginx, les répertoires Docker et les fichiers SSH vers un pool ZFS
  • La sauvegarde des répertoires Docker exclut les chemins de bases de données, de cache, de fichiers temporaires et certains journaux
• Les tâches manuelles restantes se résument à exécuter apt update, apt upgrade, apt autoremove et à redémarrer si nécessaire
  • Cette opération prend environ 60 secondes
• Sauf urgence, le temps de maintenance est d’environ 15 minutes par mois
  • Ne pas se connecter en SSH pendant un mois pour appliquer les mises à jour n’a aucun impact réel sur les services
  • Il est probable que l’ensemble ne tombe pas en panne même sans intervention pendant plus de 6 mois, mais il n’est pas prévu de le tester volontairement
• La configuration actuelle offre, malgré un emploi du temps chargé, un équilibre entre confidentialité, sécurité et confort d’utilisation

[GN⁺]

Avis sur Lobste.rs

• J’exploite un serveur domestique de façon assez similaire
  J’ai activé les mises à niveau de sécurité automatiques sur Debian, tout tourne dans des conteneurs rootless à version épinglée, et systemd les gère via Podman Quadlet
  L’auto-update de Podman s’occupe des mises à jour des conteneurs, et des timers systemd prennent en charge les tâches récurrentes comme les sauvegardes et le nettoyage des images
  Je ne me connecte pour redémarrer que lorsqu’il y a une mise à niveau du noyau ou quand je monte une version d’image, et Ansible s’en charge

  • Le passage où « version épinglée » et « Podman auto-update » sont utilisés ensemble me prête à confusion
    Je comprenais qu’épingler une version signifiait ne pas récupérer automatiquement les mises à jour, mais en pratique il semble bien y avoir des mises à jour, donc je ne vois pas très bien si ce sont des éléments différents qui sont mis à jour
  • J’utilise une configuration presque identique depuis plus de 10 ans, et je passe à la dernière stable tous les deux ans
    Le seul équipement que je gère séparément est un routeur, sous OpenBSD, que je mets à niveau environ tous les 6 mois lorsqu’une nouvelle version sort
    Les deux sont stables au point d’en être ennuyeux

• C’est similaire, mais je ne mets rien à jour tant qu’une fonctionnalité dont j’ai envie n’apparaît pas
  L’avantage des logiciels auto-hébergés, c’est de pouvoir les mettre à jour selon son propre calendrier
  Si tout fonctionne bien, que l’accès ne se fait que via Tailscale et que rien n’est exposé directement à Internet, c’est stable si on laisse tel quel, hormis les pannes matérielles

  • Je me demande pourquoi une application exposée directement à Internet et une application exposée via Tailscale seraient différentes
    Les données qui atteignent l’application sont au final les mêmes, donc les mêmes vulnérabilités ne pourraient-elles pas être exploitées ?

• Si c’est vraiment dans cet état, c’est une assez bonne situation
  J’essaie moi aussi d’y arriver, mais je n’y suis pas encore complètement
  Les mises à niveau majeures de Debian nécessitent toujours une intervention manuelle tous les 2 ans : "Issues to be aware of for trixie", "Obsolescence and deprecation", "Cleanup after the upgrade"
  Les anciennes versions d’Ansible ne savent pas gérer les systèmes Debian récents ; donc quand on met à jour le serveur Debian, il faut aussi mettre à jour Ansible, et au final adapter les playbooks au nouvel Ansible
  J’essaie maintenant de réduire cela en utilisant davantage de conteneurs Docker, mais il sera sans doute difficile de remplacer complètement Ansible
  Il y a aussi des services en ligne que je ne veux pas héberger moi-même, comme freeDNS ou dynv6.net, et eux aussi introduisent parfois des changements cassants
  Malgré tout, dans l’ensemble, c’est plutôt correct
  Honnêtement, la gestion d’un homelab « sans maintenance » revient à la confier aux développeurs open source du monde entier qui maintiennent les logiciels, paquets et images Docker que nous utilisons

• J’hésite à appeler ma configuration un « homelab », mais c’est un NAS unRAID qui fait tourner plusieurs conteneurs Docker
  L’une des raisons pour lesquelles je suis satisfait de payer pour unRAID, c’est que son support de Docker est assez bon, qu’un plugin permet les mises à jour automatiques des conteneurs, et que le reste de la maintenance reste plutôt simple

• Personnellement, le mot « lab » me fait plutôt penser à un lieu d’expérimentation, et le fait qu’on n’ait pas besoin de maintenir l’expérience elle-même me gêne un peu
  L’usage des conteneurs a des avantages et des inconvénients
  Pour certains projets, les conteneurs sont un mode de distribution de premier ordre, et on peut recevoir correctement les mises à jour de cette façon
  Mais j’ai l’impression que beaucoup de gens font tourner des conteneurs maintenus de manière ambiguë, et je pense que beaucoup de problèmes viendront de là
  L’essentiel est de comprendre quel est le canal officiel pour recevoir les mises à jour du logiciel que l’on utilise
  De mon côté, j’utilise surtout des clones de RHEL avec des mises à jour automatiques, et Nagios me prévient lorsqu’un redémarrage est nécessaire
  La plupart des services étant dans RHEL ou EPEL, la maintenance est assez limitée

• Pour la maintenance de mon homelab, pyinfra s’est révélé pile au bon niveau pour pouvoir être paresseux
  On peut décrire le processus de configuration sous forme de code, c’est particulièrement utile pour des choses comme les fichiers de configuration, et si besoin on peut appeler apt sans se demander comment nix gérerait ça
  Ce n’est pas un outil extrêmement intelligent, mais c’est mieux qu’un unique script shell, et j’aimerais le faire évoluer davantage à l’avenir
  Bonus si l’on utilise du codage agentique : on peut montrer les fichiers pyinfra à Claude et obtenir de l’aide pour déboguer la configuration

• J’utilise NixOS sur mon serveur et je le mets à jour de temps en temps, quand j’y pense
  La plupart du temps, ça se résume à nix flake update && nix run .#deploy, donc je n’ai pas trop à m’en soucier

• Je suis dans une situation très similaire, et même si je n’aime pas l’admettre, c’est en grande partie parce que ma configuration est devenue plus simple
  Avant, j’aimais avoir une pile d’observabilité complète avec rotation des logs, mais ces 2 dernières années, tous les ennuis récents venaient de petits problèmes liés à cette complexité
  Par exemple des logs et des métriques qui remplissent le disque
  C’est très facile à résoudre, mais je n’ai plus envie de m’occuper de ce genre de choses

• J’aime bien Watchtower pour garder une configuration docker-compose à jour
  https://hub.docker.com/r/nickfedor/watchtower
  Les options de configuration sont assez bonnes pour continuer à monter de version tout en tenant compte, dans une certaine mesure, des changements majeurs
  L’OS de base est Debian LTS avec seulement les mises à jour automatiques activées, et je me connecte pour redémarrer lorsqu’un nouveau noyau sort
  Il n’y a vraiment pas beaucoup de travail, et je suis d’accord avec l’estimation de moins de 15 minutes par mois