homelab-services : Gérer son homelab avec Ansible

Comment j’automatise le déploiement, la sécurisation et la maintenance de mon infrastrcuture personnelle avec Ansible et ansible-vault
2 April 2026 617 words Reading: 3 min Authors:
  • Loïs Dutour

Ce projet est la suite de l’article sur la mise en place du homelab. Une fois l’infrastructure physique en place, la question qiu s’est posée était : Comment ne pas avoir à se souvenir de ce qu’on a fait sur chaque machine et rendre ceci reproductible ?

La réponse : tout mettre dans du code Ansible versionné sur GitHub !


Un problème à résoudre

Après plusieurs mois de lab, j’avais quatre machines dans des états légèrement différents. Certains paquets installés à la main, des configurations SSH modifées sans trace, des services Docker lancés sans pouvoir les remonter de manière rapide si une panne venait à survenir.

Une panne, une réinstallation, et c’est parti pour reconstruire tout de mémoire !

Ce projet homelab-services résout ça : une seule commande reconstruit l’état complet d’une machine, qu’il s’agisse du hardening SSH, de fail2ban ou du d"ploiement des services Docker.


Architecture cible

Quatre machines, trois rôles distincts :

MachineRôleOS
2× Lenovo M715qCluster Proxmox VE (PVE1/PVE2)Proxmox VE 9.1
Lenovo M710qServeur services DockerRocky Linux 9
Raspberry Pi 3+Monitoring · Wireguard VPN · QDeviceRaspberry Pi OS

(Schéma d’architecture HomeLab)[images/schema_architecture_infra.gif]


Ce que fait Ansible ici

Hardening sur toutes les machines

Le playbook hardening.yml applique trois rôles:

  • ssh_hardening
    • Désactivation de l’authentification par mot de passe
    • Interdiction de login root direct
    • Restriction des utilisateurs autorisés via AllowUsers
    • Redémarrage automatique du service SSH via handler
  • sysctl_config
    • Désactivation des redirections IP
    • Protection contre les attaques SYN flood
    • Désactivation des source routing
  • fail2ban_install
    • Protection brute-force SSH avec configuration de la jail et des seuils de banissement
ansible-playbook playbook/hardening.yml --ask-vault-pass

Services Docker

Le playbook docker-services.yml gère le cycle de vie des services. Ainsi il gère l’installation de Docker si absent, copie des docker-compose.yml depuis le repo et démarrage des services manquants sans toucher à ceux déjà en cours.

Services déployés :

  • Vaultwarden : gestionnaire de mots de passe compatible Bitwarden
  • Miniflux : lecteur RSS léger
  • KitchenOwl : gestion des repas et courses
  • OpenProject : gestion de projets
  • n8n : automatisation de workflows

Les secrets (tokens, mots de passe des bases de données) sont stockés dans un fichier vault.yml chiffré avec ansible-vault. Le repo ne contient jamais de valeur en clair, uniquement un vault.yml.example avec les clés vides pour que chacun puisse utiliser le projet.

ansible-playbook playbook/docker-services.yml --ask-vault-pass

Gestion des secrets

C’est le point qui fait peur quand on commence avec Ansible. Le principe est simple :

# Chiffrer le fichier de secrets
ansible-vault encrypt inventory/group_vars/services/vault.yml
 
# Éditer
ansible-vault edit inventory/group_vars/services/vault.yml
 
# Vérification qu'il est bien chiffré avant de pusher
head -1 inventory/group_vars/services/vault.yml
# Doit afficher : $ANSIBLE_VAULT;1.1;AES256

Le fichier chiffré peut être commité sans risque, seul le mot de passe de vault, qui reste local, permet de le déchiffrer.


Structure du projet

La structure est pensée pour être réutilisable et forkable :

homelab-services/
├── inventory/
│   ├── hosts.yml                  # IPs et groupes de machines
│   └── group_vars/                # Variables par groupe
├── playbook/
│   ├── hardening.yml              # SSH + sysctl + fail2ban
│   ├── docker-services.yml        # Services Docker
│   └── monitoring.yml             # Stack Grafana (en cours)
├── roles/                         # Rôles
└── services/                      # docker-compose.yml par service

Chaque rôle suit la structure standard Ansible : tasks/, handlers/, defaults/,templates/. Ils peuvent être utilisés indépendamment dans d’autres projets.


Ce qui est encore en cours

Le rôle monitoring (Grafana + Loki + Promtail + VictoriaMetrics sur le Pi) est en cours d’écriture. De même pour le rôle headscale qui gérera le VPN. La segmentation réseau en VLANs avec VyOS et le déploiement de Wazuh SIEM font partie d’un projet séparé qui est sur le feu mais pas encore complétement opérationnel.


Repo GitHub

👉 github.com/cacti-lfs/homelab-services

Le README contient les instructions de configuration complètes pour adapter le projet à une autre infrastructure.