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.

Mais dans la pratique, quand on bidouille Home Assistant, on touche souvent plein de fichiers YAML. Une automation par ici, un script par-là, un template capteur, un package custom… et parfois on casse quelque chose.

Le backup complet est utile en cas de gros incident, mais pour “annuler juste cette modif de fichier”, c’est un peu l’équivalent de sortir un char d’assaut. C’est exactement là où Git devient très pratique : versionner finement la configuration, commit par commit, et revenir en arrière sans avoir à rollback la totalité de la VM via un backup.

Backup VM et versionning fichier : ce n’est pas le même besoin

Le backup Proxmox protège bien l’infrastructure : panne, corruption, catastrophe, migration. D’ailleurs, je parle du backup de Proxmox, mais ce serait la même chose pour quelqu’un qui ferait ses backups via Home Assistant directement.

Git, lui, protège le quotidien :

• “J’ai modifié sensors.yaml, maintenant plus rien ne se déclenche.”
• “Mon nouveau template Jinja passe, mais le résultat est faux.”
• “J’ai testé une config vite fait, je veux revenir à l’état d’hier.”

Dans ces cas-là, restaurer une sauvegarde complète est disproportionné. Avec Git, on peut juste comparer, annuler ou restaurer les fichiers concernés.

Les deux se complètent très bien : backup global + historique précis des changements.

Quoi versionner dans Home Assistant (et quoi ignorer)

De mon côté, je versionne surtout les fichiers de configuration “métier” :

• configuration.yaml
• automations.yaml
• scripts.yaml
• scenes.yaml
• le dossier packages customs
• le dossier templates customs

Et j’exclus le reste quand ce n’est pas utile à versionner :

• secrets
• bases de données
• logs
• fichiers temporaires/cache

C’est le moment où il faut être un peu plus rigoureux pour éviter des problèmes futurs. L’idée est simple : garder un repo propre, lisible, utile pour revenir en arrière rapidement.

Deux règles simples :

1. Ne jamais versionner les secrets (secrets.yaml, tokens, credentials, etc.).
2. Exclure les fichiers volumineux ou très verbeux (DB, logs, temporaires).

De toute manière, avant chaque commit, je vérifie les fichiers qui vont être versionnés. S’il y en a un nouveau qui passe au travers de mon gitignore, je modifie mes règles pour l’exclure.

Mise en place : workflow simple et efficace

Je reste volontairement sur un setup simple, sans sur-ingénierie.

Ajouter l’addon Studio Code Server

Sur Home Assistant, j’installe l’addon Studio Code Server. Il apporte un environnement pratique pour éditer les fichiers de config (c’est mieux que File Editor), et en plus, il permet d’avoir accès à Git et au terminal.

Générer une clé SSH depuis Home Assistant

Depuis le terminal de l’addon, je génère une clé SSH dédiée à ce besoin. L’objectif : permettre à Home Assistant de pull et push vers GitHub sans mot de passe.

Créer le repository GitHub

Je crée un repo, a priori privé. Ensuite, dans les settings du repo, j’ajoute la clé publique de Home Assistant dans Deploy keys.

Pourquoi une deploy key plutôt qu’une clé perso classique ? Parce que ça limite l’accès à ce seul repo. C’est plus propre et plus sécurisé que d’ouvrir l’accès à tout mon compte. Technique du moindre privilège !

Initialiser Git dans le dossier de configuration

Dans le dossier de config Home Assistant (souvent /config), j’initialise le repo et je lie le remote :

git init
git remote add origin git@github.com:UTILISATEUR/NOM_DU_REPO.git
git fetch origin
git checkout -b main origin/main || git checkout -b main
git add .
git commit -m "Add: initial configuration"
git push -u origin main

Le checkout avec fallback permet de gérer les deux cas :

• repo déjà initialisé avec un commit (README, .gitignore, etc.)
• repo vide

Utilisation au quotidien

Maintenant que tout ça est en place, mon flux est très simple :

1. Je modifie une automation ou un script.
2. Je teste dans Home Assistant.
3. Si c’est bon : git add, git commit, git push.
4. Si ça casse : je regarde le diff, je corrige, je discard.

Je passe d’un mode “je croise les doigts” à un mode “je peux expérimenter sans peur”. Et c’est souvent là que ça change tout : on ose mieux itérer, parce qu’on sait revenir proprement.

Bref

Si tu as déjà des backups Proxmox, tu as une très bonne base. Mais pour le quotidien Home Assistant, Git apporte une finesse que le backup VM ne donne pas. Pas besoin d’une grosse usine : un repo, une clé SSH, un .gitignore et des commits réguliers.

La vraie question devient ensuite “comment faire évoluer sereinement sa maison dans le temps ?” plutôt que de perdre du temps à retrouver des configurations qui marchaient avant :)