Aller au contenu
NVSD HOMELAB
Docker · Fondations · Tutoriels6 août 2026

Préparer Fedora et organiser mon Homelab local

Introduction : avant les services, l’organisation

Dans mon premier article, j’ai présenté l’idée générale de mon Homelab : développer en local, tester mes services sur mon poste Fedora, puis déployer les versions validées sur un VPS Ubuntu.

Cette architecture peut sembler simple sur un schéma. Dans la pratique, elle ne devient fiable qu’à partir du moment où la machine locale est organisée. Si chaque projet est placé dans un dossier différent, si les données sont mélangées avec le code et si les ports sont choisis au hasard, les problèmes arrivent rapidement.

J’ai donc commencé par poser une fondation claire :

  • un système Fedora maintenu à jour ;
  • Docker Engine et Docker Compose ;
  • une arborescence commune sous /srv/homelab ;
  • une séparation entre les stacks, les projets et les données persistantes ;
  • une méthode pour tenir compte de SELinux ;
  • une règle simple pour éviter les conflits de ports.

Cette étape est moins spectaculaire que le lancement d’une interface web, mais elle m’a fait gagner beaucoup de temps ensuite.

Mon environnement Fedora a évolué

Les premières étapes de mon Homelab ont été réalisées sous Fedora Silverblue. Cette distribution m’a obligé à réfléchir davantage à la séparation entre le système, les outils de développement et les conteneurs.

Au fil du projet, j’ai aussi réinstallé ma machine sur Fedora 44 KDE. Le changement d’installation n’a pas modifié l’architecture de mes projets, mais il m’a rappelé une règle importante : un projet Docker doit rester suffisamment autonome pour pouvoir être reconstruit sur une nouvelle machine.

Je ne veux donc pas que la réussite d’une stack dépende d’un réglage oublié dans mon ancien système. Les éléments importants doivent être visibles dans le projet lui-même :

  • le fichier compose.yaml ;
  • le Dockerfile, lorsqu’une image est construite ;
  • les variables d’environnement documentées dans un fichier .env.example ;
  • les dossiers de données nécessaires ;
  • les ports utilisés ;
  • les réseaux Docker ;
  • les instructions de sauvegarde et de restauration.

Les versions de Fedora et de Docker changeront avec le temps. L’objectif de cette série n’est donc pas de figer une commande pour toujours, mais de montrer comment je construis une installation que je peux comprendre et reconstruire.

Mettre Fedora à jour avant de travailler

Je commence par mettre le système à jour et par installer quelques outils qui me servent régulièrement :

sudo dnf upgrade --refresh
sudo dnf install -y git curl wget unzip tar htop

Je vérifie ensuite la version du système :

cat /etc/fedora-release
uname -a

Cette vérification peut sembler basique, mais elle devient utile lorsqu’une commande fonctionne sur une machine et pas sur une autre. Dans mon Homelab, je garde plusieurs environnements : mon poste local, le VPS de production et parfois des machines de test. Connaître le système sur lequel je travaille évite de chercher une erreur Docker alors que le problème vient simplement de la distribution ou de ses permissions.

Installer Docker Engine et vérifier Compose

J’utilise Docker Engine, et non Docker Desktop, pour rester proche de l’environnement du VPS. L’installation officielle pour Fedora passe par le dépôt Docker. Les paquets principaux sont Docker Engine, son client, containerd, Buildx et le plugin Docker Compose.

Sur une installation Fedora destinée à cet usage, la procédure officielle ressemble à ceci :

sudo dnf config-manager addrepo \
  --from-repofile https://download.docker.com/linux/fedora/docker-ce.repo

sudo dnf install -y \
  docker-ce \
  docker-ce-cli \
  containerd.io \
  docker-buildx-plugin \
  docker-compose-plugin

sudo systemctl enable --now docker

Je contrôle immédiatement que le moteur et Compose répondent :

docker --version
docker compose version
sudo systemctl is-active docker

Le test le plus simple consiste à lancer l’image officielle de démonstration :

sudo docker run --rm hello-world

Si je veux utiliser Docker sans écrire sudo devant chaque commande, j’ajoute mon compte au groupe docker :

sudo usermod -aG docker "$USER"

Je dois ensuite fermer puis rouvrir ma session, ou redémarrer la machine. Je vérifie alors :

docker ps

Cette possibilité est pratique, mais elle doit être comprise : l’accès au socket Docker donne des privilèges importants sur la machine. Je ne l’active donc que pour un compte local de confiance et je ne rends jamais le socket Docker accessible publiquement.

Pourquoi j’ai choisi /srv/homelab

J’aurais pu placer mes projets dans mon dossier personnel. J’ai pourtant choisi /srv/homelab, parce que ce chemin décrit clairement la fonction de l’ensemble : ce sont des données et des services destinés à être servis par la machine.

Cette séparation m’aide également lorsque je dois sauvegarder, déplacer ou restaurer le Homelab. Je sais où chercher les stacks, où se trouvent les données et quels dossiers doivent être inclus dans une archive.

Je crée la structure de base ainsi :

sudo mkdir -p /srv/homelab/{backups,configs,data,projects,stacks}
sudo chown -R "$USER":"$USER" /srv/homelab

Mon organisation générale ressemble à ceci :

/srv/homelab/
├── backups/
├── configs/
├── data/
│   ├── dockge/
│   ├── npm/
│   ├── ollama/
│   ├── open-webui/
│   └── prometheus/
├── projects/
│   └── nvsd/
│       └── html/
└── stacks/
    ├── ai/
    │   └── ollama/
    ├── dockge/
    ├── nginx-proxy-manager/
    ├── nvsd/
    ├── nvsd-homelab/
    ├── nvsd-web/
    ├── nombre/
    └── partition-generator/

Cette arborescence n’est pas une obligation Docker. C’est une convention que je me suis donnée pour ne pas perdre le fil lorsque le nombre de projets augmente.

Séparer le code, la configuration et les données

J’essaie de ne pas mélanger trois types de fichiers.

Les stacks

Une stack correspond à un projet ou à un groupe de services décrits par un compose.yaml. Elle contient la définition de l’environnement : images, variables, ports, réseaux et volumes.

Les données persistantes

Les bases de données, les modèles d’IA, les fichiers générés et les médias doivent survivre à la recréation d’un conteneur. Je les place donc dans data/ ou dans un volume Docker explicitement nommé.

Les projets et les sources

Le code de mes sites et de mes applications reste dans projects/ ou dans le dossier de la stack lorsqu’il fait partie du build. Cette distinction est particulièrement utile pour mes applications Python, mes sites statiques et mes interfaces Next.js.

Un conteneur peut être supprimé et reconstruit. Les données importantes, elles, doivent rester sur l’hôte et être sauvegardées.

Fedora et SELinux : ne pas contourner le problème

Fedora utilise SELinux pour limiter ce que les processus peuvent lire ou modifier. Lorsque Docker monte un dossier local dans un conteneur, les permissions Unix ne suffisent pas toujours.

J’ai rencontré ce problème avec des dossiers de données et des sites statiques : le conteneur semblait avoir les bons droits, mais l’application retournait quand même une erreur Permission denied ou une page 403.

La solution habituelle consiste à ajouter l’option SELinux au volume. Par exemple :

services:
  web:
    image: nginx:alpine
    volumes:
      - ./html:/usr/share/nginx/html:ro,Z

L’option Z indique que le contenu monté reçoit un contexte privé pour le conteneur. Lorsque le même dossier doit être partagé par plusieurs conteneurs, l’option z peut être appropriée.

Je préfère corriger le volume et les droits plutôt que désactiver SELinux. Désactiver une protection du système pour faire disparaître une erreur rend le Homelab plus difficile à sécuriser et masque la vraie cause du problème.

Pour diagnostiquer un dossier, je peux regarder ses droits classiques et son contexte SELinux :

ls -ld /srv/homelab
ls -Zd /srv/homelab

Je vérifie aussi que l’utilisateur du conteneur peut réellement écrire dans le dossier prévu. Selon l’image utilisée, il peut être nécessaire d’adapter le propriétaire ou les permissions du sous-dossier, plutôt que de modifier toute l’arborescence.

Tester une première stack isolée

Avant de lancer un projet important, je préfère valider le chemin complet avec une petite stack. Le principe est toujours le même : un dossier dédié, un fichier Compose lisible, un volume explicite et un port qui n’est pas encore utilisé.

Exemple minimal :

services:
  web:
    image: nginx:alpine
    container_name: homelab-test-web
    ports:
      - "8088:80"
    volumes:
      - ./html:/usr/share/nginx/html:ro,Z

Je peux alors construire et démarrer cette stack avec :

docker compose up -d
docker compose ps

Puis vérifier le résultat dans le navigateur sur http://localhost:8088.

Une fois le test terminé, je supprime le conteneur et le réseau de cette stack :

docker compose down

Cette petite expérience valide plusieurs choses à la fois : Docker fonctionne, Compose est disponible, le montage du volume est accepté par SELinux et le port est accessible depuis le navigateur.

Les ports : une ressource globale à surveiller

Chaque stack possède son propre dossier, mais les ports publiés appartiennent à toute la machine. Deux conteneurs différents ne peuvent pas écouter simultanément sur le même port hôte.

Je l’ai rencontré lorsque j’ai lancé mon Builder NVSD sur le port 8085, puis la stack WordPress avec le même port. WordPress n’a pas pu démarrer et Docker a retourné une erreur indiquant que 0.0.0.0:8085 était déjà utilisé.

J’ai conservé le Builder sur 8085 et déplacé WordPress sur 8086. Dans mon environnement local, quelques ports servent de repères :

ServicePort local utiliséRôle
Builder NVSD Homelab8085Référence visuelle et interface de travail
WordPress local8086Administration et prévisualisation éditoriale
Dockge5001Gestion des stacks Compose
Open WebUI3000Interface de dialogue avec l’IA locale
Ollama11434API des modèles locaux

Avant de choisir un nouveau port, je regarde ce qui est déjà publié :

docker ps --format 'table {{.Names}}\t{{.Ports}}'
ss -tlnp

Cette habitude m’évite de chercher une erreur dans le code alors que le service ne démarre simplement pas parce que le port est déjà réservé.

Dockge comme point de contrôle

Lorsque le nombre de stacks augmente, les commandes Docker restent indispensables, mais Dockge m’offre une vue plus claire de mes projets Compose.

Je garde toutefois une règle : Dockge ne remplace pas les fichiers sources. Le compose.yaml, les variables documentées et les données restent les éléments de référence. Dockge sert à démarrer, arrêter, reconstruire et consulter les logs plus confortablement.

Cette séparation est importante pour la suite. Si je dois déplacer une stack vers le VPS, je peux reprendre les fichiers du projet et les adapter à l’environnement distant. Je ne dépends pas uniquement d’une configuration enregistrée dans une interface graphique.

Ce que cette préparation m’a appris

Cette étape m’a montré qu’un Homelab est autant une question d’organisation que de puissance matérielle.

J’ai appris à :

  • donner un dossier identifiable à chaque projet ;
  • distinguer les fichiers de configuration des données persistantes ;
  • vérifier les ports avant de démarrer une nouvelle application ;
  • prendre SELinux en compte dès la création d’un volume ;
  • tester une stack minimale avant de déployer un service plus complexe ;
  • conserver des configurations reproductibles pour le passage vers le VPS.

Ces règles ont ensuite facilité l’installation de WordPress, d’Ollama, d’Open WebUI et de mes applications créatives. Elles m’ont également préparé aux problèmes que j’ai rencontrés sur le VPS : réseaux Docker, reverse proxy, permissions et sauvegardes.

Conclusion : une fondation avant les projets

Mon Homelab local n’a pas commencé par une collection d’applications. Il a commencé par une structure de fichiers, un moteur de conteneurs vérifié et quelques règles simples.

Cette fondation me permet maintenant de travailler par petites étapes. Je peux créer une stack, la tester localement, observer ses logs, corriger ses permissions, puis la déplacer vers un autre environnement sans repartir de zéro.

Dans le prochain article, je détaillerai la création de mes premières stacks Docker et l’utilisation de Dockge pour administrer le Builder NVSD, les sites web et les services du Homelab.

      Références techniques