Maintenir et réinstaller son Homelab Proxmox avec Ansible sans tout refaire à la main

Dans mon précédent article sur mon homelab Proxmox, je racontais comment j’avais installé un mini PC pour héberger quelques services à la maison. Rien de très extravagant : Proxmox comme hyperviseur, des VM et des LXC, Home Assistant, n8n, un peu de réseau, un peu de Linux, et pas mal d’expérimentations.

Depuis, j’ai avancé sur un point important : les sauvegardes. Mes VM et mes containers sont sauvegardés avec un Proxmox Backup Server (PBS) distant. C’est déjà très rassurant. Si un LXC se casse la figure, je peux le restaurer. Si une VM part en vrille après une mise à jour douteuse, pareil. Si c’est moi qui provoque une catastrophe (le plus probable, c’est souvent un problème interface-clavier :)), je peux rollback aussi.

Mais il me restait une question un peu moins confortable : et Proxmox lui-même ? Comment je restaure l’hôte ?

Parce que si le SSD de mon mini PC me lâche complètement, je peux réinstaller Proxmox, restaurer mes containers, et repartir. En théorie. Sauf qu’entre les deux, il y a tout ce que j’ai configuré sur l’hôte : le firewall, fail2ban, le durcissement SSH, les optimisations pour limiter les écritures sur le SSD, les jobs de backup, les services désactivés parce qu’ils ne me servent à rien…

Bref, tout ce que l’on fait une fois juste après l’installation de Proxmox et que l’on oublie ensuite. Jusqu’au jour où il faut le refaire. Et là, on se retrouve à lâcher un “oh merde” et plus si affinités avec les noms d’oiseaux.

Le vrai problème : reconstruire la configuration

Dans mon cas, on parle d’un homelab personnel. Je n’ai ni baie de stockage, serveurs en cluster, ou redondance des disque. J’ai un simple mini PC, un SSD, des backups, et néanmoins l’envie de dormir tranquille sans transformer mon salon en datacenter.

Le scénario qui m’intéresse est donc assez simple : si demain je dois repartir d’une installation Proxmox propre, comment je reconstruis ma configuration sans passer une soirée à cliquer partout dans l’interface web et à relire mes propres notes ? (si elles existent, et si elles sont à jour)

J’ai d’abord pensé à des solutions assez naturelles. Versionner quelques fichiers de configuration dans Git. Sauvegarder tout /etc/pve. Écrire des scripts shell pour rejouer certaines étapes. Toutes ces pistes peuvent marcher, mais elles me semblaient vite fragiles ou incomplètes.

Versionner /etc/pve, par exemple, donne une photo intéressante de l’état de l’hôte Proxmox, mais ce n’est pas forcément une recette de reconstruction. Un fichier de configuration n’explique pas toujours dans quel ordre appliquer les choses, ni quels paquets installer, ni quels services relancer. Et un script shell peut vite devenir une suite de commandes qui marche le jour où on l’écrit, puis que l’on n’ose plus toucher six mois plus tard.

En fouillant un peu, je suis retombé sur Ansible. Je connaissais de loin, sans l’avoir vraiment utilisé. Ça ressemblait exactement à ce qu’il me fallait : décrire l’état souhaité de mon serveur, versionner cette description, puis pouvoir la rejouer quand j’en ai besoin. Bon. On va commencer à joeur avec.

Ce qu’Ansible m’apporte dans un homelab

Ansible sert à automatiser la configuration et l’administration de machines. On écrit des fichiers YAML qui décrivent des tâches : installer un paquet, copier un fichier, créer un utilisateur, modifier une configuration, démarrer un service, lancer une commande, etc.

La force, ce n’est pas seulement d’automatiser. Des scripts peuvent déjà le faire. Ce qui m’intéresse surtout, c’est l’idée d'idempotence.

Dit simplement, une tâche idempotente peut être exécutée plusieurs fois sans empiler les effets de bord. Si je dis à Ansible “le paquet fail2ban doit être installé”, il ne va pas tenter de l’installer encore et encore comme si c’était la première fois. Il vérifie l’état actuel, puis agit seulement si nécessaire. Si je dis “ce fichier doit contenir cette configuration”, il peut détecter s’il y a un changement à appliquer.

C’est bête, mais ça change beaucoup de choses. Je peux relancer mon playbook après une petite modification sans avoir peur de casser tout le reste. Je peux faire évoluer ma configuration par morceaux. Je peux relire l’historique Git pour comprendre pourquoi j’ai changé une règle de firewall ou modifié une option SSH. Et surtout, je peux relancer l’ensemble si je dois reconstruire mon serveur de zéro. Et ça, c’est génial.

Pour un homelab, c’est très confortable. On bidouille, on apprend, on teste. Mais à force de petits changements, le serveur finit par contenir beaucoup de décisions implicites. Ansible m’aide à les rendre explicites et les versionner.

Ce que j’ai commencé à versionner

Mon objectif n’était pas de faire “du Ansible pour faire du Ansible”. Je voulais d’abord couvrir les réglages que je n’avais pas envie de refaire à la main en cas de réinstallation.

J’ai donc commencé par la base Proxmox : les règles firewall, les IP sets, les security groups, la configuration des backups, le stockage PBS distant, les paquets installés sur l’hôte, les services à activer ou désactiver. J’ai aussi ajouté des réglages autour de la sécurité : fail2ban, SSH, nouvel utilisateur d’administration, certaines permissions.

Ensuite, j’ai ajouté les optimisations que j’avais déjà identifiées pour mon mini PC. Par exemple la configuration de journald et rrdcached pour réduire les écritures inutiles, la désactivation de services dont je n’ai pas besoin dans mon contexte comme la haute disponibilité, le bluetooth, le wifi, etc.

J’ai de plus en plus aimé Ansible, alors j’ai continué en m’intéressant à l’intérieur des containers LXC / VM. Oui, ils sont normalement “protégés des catastrophes” grâce aux backups sur PBS. Mais prenons un cas d’usage concret qui arrive souvent : la modification d’un fichier de conf. Qui a envie de faire un rollback de tout le container juste pour revenir en arrière sur ce fichier ? Moi, clairement pas. C’est pour cela que j’avais d’ailleurs commencé à utiliser git pour annuler rapidement une erreur Home Assistant.

Le petit bonus que j’ai trouvé en cours de route, c’est que je ne suis même pas obligé d’ouvrir le SSH sur chaque container si je ne veux pas : je peux indiquer à Ansible de passer par l’hôte Proxmox et utiliser pct pour agir dans le container. Mon petit côté parano sur la sécurité aime bien ça.

Reconstruire, maintenir, lancer des tâches

Au départ, je pensais surtout “plan post-apocalyptique” : le SSD meurt, je réinstalle Proxmox, je lance Ansible, puis je restaure mes VM et LXC depuis PBS. C’est déjà une très bonne raison de faire l’effort. Mais à l’usage, j’ai découvert des intérêts qui vont au-delà. Ansible devient aussi mon outil du quotidien.

Si je veux modifier la configuration de Caddy, je la modifie dans Ansible, je l’applique sur mon serveur et je versionne. Quand je veux ajouter une règle sur le firewall, même chose. Dans la plupart des cas, je n’agis plus directement sur le serveur ou sur l’interface.

Et puis, il y a le côté tâches que j’aime bien avec Ansible. Quand je modifie la configuration d’un service, il faut souvent le redémarrer pour que la modification soit prise en compte. Avec Ansible, c’est facile et intelligent : la configuration sera copiée puis le service sera redémarré uniquement s’il y a une différence entre la nouvelle et ancienne configuration (vous vous souvenez, l’idempotence).

Un autre cas d’usage que j’aime bien, je démarre et arrête des services via Ansible. C’est agréable. Une seule commande me suffit pour lancer un playbook Ansible plutôt que de passer par l’interface et le terminal pour démarrer un LXC, attendre qu’il soit prêt, lancer un container docker puis lancer un second container qui dépend du premier.

À quoi ça ressemble concrètement ?

Un playbook Ansible est une suite de tâches. Pour donner une idée, voici un exemple simple :

---
- name: Configurer la base de mon hote Proxmox
  hosts: proxmox
  become: true

  tasks:
    - name: Installer fail2ban
      ansible.builtin.apt:
        name: fail2ban
        state: present
        update_cache: true

    - name: Copier la configuration SSH
      ansible.builtin.copy:
        src: files/sshd_config
        dest: /etc/ssh/sshd_config
        owner: root
        group: root
        mode: "0644"
      notify: Redemarrer ssh

    - name: S'assurer que fail2ban est actif
      ansible.builtin.service:
        name: fail2ban
        state: started
        enabled: true

  handlers:
    - name: Redemarrer ssh
      ansible.builtin.service:
        name: ssh
        state: restarted

On lit ça presque comme une checklist : installer fail2ban, copier la configuration SSH, vérifier que le service tourne. Le handler permet de redémarrer SSH uniquement si le fichier de configuration a changé. C’est le genre de détail qui évite de faire des actions inutiles.

J’ai petit à petit créé des playbook pour chaque sujet. J’ai essayé de garder une logique modulaire et unitaire : règles firewall (par container), SSH, backups, optimisations, paquets, containers, services. Ça rend l’ensemble plus facile à relire et à faire évoluer. Si demain je veux modifier uniquement Caddy ou ajouter une règle firewall, je sais où aller. Si j’ai besoin d’utiliser un playbook au sein d’un autre, je peux.

Il existe aussi des collections Ansible, c’est-à-dire des ensembles de modules qui apportent de nouvelles fonctionnalités pour nos playbook. J’ai notamment regardé la collection community.proxmox, qui ajoute des possibilités orientées Proxmox. C’est pratique pour éviter de tout piloter à coup de commandes shell, en particulier sur des sujets comme le firewall où ça m’a bien aidé.

Et on peut aller plus loin. Ansible propose par exemple un système de variable glboale ou par host, des variables chiffrés grâce à Ansible Vault, l’affichage d’informations, l’exécution d’étapes conditionnés à un résultat précédant, un input de l’utilisateur, etc.

Pourquoi pas Terraform ?

Pendant mes recherches, je suis aussi retombé sur Terraform. Les deux outils sont souvent cités ensemble et ils peuvent être complémentaires. Terraform est très fort pour provisionner de l’infrastructure : déclarer des ressources, créer des machines, gérer leur cycle de vie. Ansible est plutôt orienté configuration : installer, modifier, maintenir ce qui tourne sur les machines.

Sur un setup plus ambitieux, un combo Terraform + Ansible pourrait avoir du sens. Terraform pour créer les VM/LXC, Ansible pour les configurer ensuite.

Dans mon cas, ça me semblait trop. J’ai un mini PC, quelques services, et surtout un besoin d’apprendre sans empiler les couches trop vite. Terraform aurait ajouté un outil, un état à gérer, une logique supplémentaire. Pour l’instant, Ansible couvre très bien mon besoin.

C’est aussi une décision importante dans un homelab : accepter de ne pas reproduire une infrastructure d’entreprise miniature ou d’ajouter de la complexité inutile. Sauf si l’objectif est d’apprendre Terraform, évidemment, le homelab reste un bon terrain d’expérimentation.

Bref

J’ai commencé à utiliser Ansible pour une raison très concrète : je ne voulais pas que la configuration de mon hôte Proxmox repose uniquement sur ma mémoire, quelques notes, et l’espoir que rien ne casse.

Mes VM et mes LXC sont sauvegardés avec PBS, mais ça ne suffit pas à reconstruire proprement tout le contexte autour. Le firewall, fail2ban, les optimisations, les jobs de backup, … tout ça fait partie de mon serveur. Ansible me permet de transformer cette configuration en quelque chose de versionné, rejouable et progressivement améliorable.

Pour mon usage, c’est un bon compromis : assez simple à prendre en main, assez puissant pour éviter les scripts fragiles, et suffisamment lisible pour que mon futur moi le comprenne toujours.

Et finalement, c’est peut-être ça le vrai bénéfice : préparer la panne, oui, mais surtout rendre la maintenance quotidienne plus facile. La réinstallation complète arrivera peut-être un jour. En attendant, chaque petite évolution devient une occasion de laisser une trace claire.