{"id":32,"date":"2026-08-06T16:37:22","date_gmt":"2026-08-06T14:37:22","guid":{"rendered":"http:\/\/127.0.0.1:8086\/?p=32"},"modified":"2026-08-13T14:44:47","modified_gmt":"2026-08-13T12:44:47","slug":"preparer-fedora-organiser-homelab-local","status":"publish","type":"post","link":"https:\/\/homelab.nvsd.ch\/?p=32","title":{"rendered":"Pr\u00e9parer Fedora et organiser mon Homelab local"},"content":{"rendered":"\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Introduction : avant les services, l\u2019organisation<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Dans mon premier article, j\u2019ai pr\u00e9sent\u00e9 l\u2019id\u00e9e g\u00e9n\u00e9rale de mon Homelab : d\u00e9velopper en local, tester mes services sur mon poste Fedora, puis d\u00e9ployer les versions valid\u00e9es sur un VPS Ubuntu.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Cette architecture peut sembler simple sur un sch\u00e9ma. Dans la pratique, elle ne devient fiable qu\u2019\u00e0 partir du moment o\u00f9 la machine locale est organis\u00e9e. Si chaque projet est plac\u00e9 dans un dossier diff\u00e9rent, si les donn\u00e9es sont m\u00e9lang\u00e9es avec le code et si les ports sont choisis au hasard, les probl\u00e8mes arrivent rapidement.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">J\u2019ai donc commenc\u00e9 par poser une fondation claire :<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>un syst\u00e8me Fedora maintenu \u00e0 jour ;<\/li>\n\n\n\n<li>Docker Engine et Docker Compose ;<\/li>\n\n\n\n<li>une arborescence commune sous <code>\/srv\/homelab<\/code> ;<\/li>\n\n\n\n<li>une s\u00e9paration entre les stacks, les projets et les donn\u00e9es persistantes ;<\/li>\n\n\n\n<li>une m\u00e9thode pour tenir compte de SELinux ;<\/li>\n\n\n\n<li>une r\u00e8gle simple pour \u00e9viter les conflits de ports.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Cette \u00e9tape est moins spectaculaire que le lancement d\u2019une interface web, mais elle m\u2019a fait gagner beaucoup de temps ensuite.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Mon environnement Fedora a \u00e9volu\u00e9<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Les premi\u00e8res \u00e9tapes de mon Homelab ont \u00e9t\u00e9 r\u00e9alis\u00e9es sous Fedora Silverblue. Cette distribution m\u2019a oblig\u00e9 \u00e0 r\u00e9fl\u00e9chir davantage \u00e0 la s\u00e9paration entre le syst\u00e8me, les outils de d\u00e9veloppement et les conteneurs.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Au fil du projet, j\u2019ai aussi r\u00e9install\u00e9 ma machine sur Fedora 44 KDE. Le changement d\u2019installation n\u2019a pas modifi\u00e9 l\u2019architecture de mes projets, mais il m\u2019a rappel\u00e9 une r\u00e8gle importante : un projet Docker doit rester suffisamment autonome pour pouvoir \u00eatre reconstruit sur une nouvelle machine.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Je ne veux donc pas que la r\u00e9ussite d\u2019une stack d\u00e9pende d\u2019un r\u00e9glage oubli\u00e9 dans mon ancien syst\u00e8me. Les \u00e9l\u00e9ments importants doivent \u00eatre visibles dans le projet lui-m\u00eame :<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>le fichier <code>compose.yaml<\/code> ;<\/li>\n\n\n\n<li>le <code>Dockerfile<\/code>, lorsqu\u2019une image est construite ;<\/li>\n\n\n\n<li>les variables d\u2019environnement document\u00e9es dans un fichier <code>.env.example<\/code> ;<\/li>\n\n\n\n<li>les dossiers de donn\u00e9es n\u00e9cessaires ;<\/li>\n\n\n\n<li>les ports utilis\u00e9s ;<\/li>\n\n\n\n<li>les r\u00e9seaux Docker ;<\/li>\n\n\n\n<li>les instructions de sauvegarde et de restauration.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Les versions de Fedora et de Docker changeront avec le temps. L\u2019objectif de cette s\u00e9rie n\u2019est donc pas de figer une commande pour toujours, mais de montrer comment je construis une installation que je peux comprendre et reconstruire.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Mettre Fedora \u00e0 jour avant de travailler<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Je commence par mettre le syst\u00e8me \u00e0 jour et par installer quelques outils qui me servent r\u00e9guli\u00e8rement :<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo dnf upgrade --refresh\nsudo dnf install -y git curl wget unzip tar htop<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Je v\u00e9rifie ensuite la version du syst\u00e8me :<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>cat \/etc\/fedora-release\nuname -a<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Cette v\u00e9rification peut sembler basique, mais elle devient utile lorsqu\u2019une 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\u00eetre le syst\u00e8me sur lequel je travaille \u00e9vite de chercher une erreur Docker alors que le probl\u00e8me vient simplement de la distribution ou de ses permissions.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Installer Docker Engine et v\u00e9rifier Compose<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">J\u2019utilise Docker Engine, et non Docker Desktop, pour rester proche de l\u2019environnement du VPS. L\u2019installation officielle pour Fedora passe par le d\u00e9p\u00f4t Docker. Les paquets principaux sont Docker Engine, son client, <code>containerd<\/code>, Buildx et le plugin Docker Compose.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Sur une installation Fedora destin\u00e9e \u00e0 cet usage, la proc\u00e9dure officielle ressemble \u00e0 ceci :<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo dnf config-manager addrepo \\\n  --from-repofile https:\/\/download.docker.com\/linux\/fedora\/docker-ce.repo\n\nsudo dnf install -y \\\n  docker-ce \\\n  docker-ce-cli \\\n  containerd.io \\\n  docker-buildx-plugin \\\n  docker-compose-plugin\n\nsudo systemctl enable --now docker<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Je contr\u00f4le imm\u00e9diatement que le moteur et Compose r\u00e9pondent :<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker --version\ndocker compose version\nsudo systemctl is-active docker<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Le test le plus simple consiste \u00e0 lancer l\u2019image officielle de d\u00e9monstration :<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo docker run --rm hello-world<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Si je veux utiliser Docker sans \u00e9crire <code>sudo<\/code> devant chaque commande, j\u2019ajoute mon compte au groupe <code>docker<\/code> :<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo usermod -aG docker \"$USER\"<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Je dois ensuite fermer puis rouvrir ma session, ou red\u00e9marrer la machine. Je v\u00e9rifie alors :<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker ps<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Cette possibilit\u00e9 est pratique, mais elle doit \u00eatre comprise : l\u2019acc\u00e8s au socket Docker donne des privil\u00e8ges importants sur la machine. Je ne l\u2019active donc que pour un compte local de confiance et je ne rends jamais le socket Docker accessible publiquement.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Pourquoi j\u2019ai choisi <code>\/srv\/homelab<\/code><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">J\u2019aurais pu placer mes projets dans mon dossier personnel. J\u2019ai pourtant choisi <code>\/srv\/homelab<\/code>, parce que ce chemin d\u00e9crit clairement la fonction de l\u2019ensemble : ce sont des donn\u00e9es et des services destin\u00e9s \u00e0 \u00eatre servis par la machine.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Cette s\u00e9paration m\u2019aide \u00e9galement lorsque je dois sauvegarder, d\u00e9placer ou restaurer le Homelab. Je sais o\u00f9 chercher les stacks, o\u00f9 se trouvent les donn\u00e9es et quels dossiers doivent \u00eatre inclus dans une archive.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Je cr\u00e9e la structure de base ainsi :<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo mkdir -p \/srv\/homelab\/{backups,configs,data,projects,stacks}\nsudo chown -R \"$USER\":\"$USER\" \/srv\/homelab<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Mon organisation g\u00e9n\u00e9rale ressemble \u00e0 ceci :<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>\/srv\/homelab\/\n\u251c\u2500\u2500 backups\/\n\u251c\u2500\u2500 configs\/\n\u251c\u2500\u2500 data\/\n\u2502   \u251c\u2500\u2500 dockge\/\n\u2502   \u251c\u2500\u2500 npm\/\n\u2502   \u251c\u2500\u2500 ollama\/\n\u2502   \u251c\u2500\u2500 open-webui\/\n\u2502   \u2514\u2500\u2500 prometheus\/\n\u251c\u2500\u2500 projects\/\n\u2502   \u2514\u2500\u2500 nvsd\/\n\u2502       \u2514\u2500\u2500 html\/\n\u2514\u2500\u2500 stacks\/\n    \u251c\u2500\u2500 ai\/\n    \u2502   \u2514\u2500\u2500 ollama\/\n    \u251c\u2500\u2500 dockge\/\n    \u251c\u2500\u2500 nginx-proxy-manager\/\n    \u251c\u2500\u2500 nvsd\/\n    \u251c\u2500\u2500 nvsd-homelab\/\n    \u251c\u2500\u2500 nvsd-web\/\n    \u251c\u2500\u2500 nombre\/\n    \u2514\u2500\u2500 partition-generator\/<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Cette arborescence n\u2019est pas une obligation Docker. C\u2019est une convention que je me suis donn\u00e9e pour ne pas perdre le fil lorsque le nombre de projets augmente.<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"576\" src=\"https:\/\/homelab.nvsd.ch\/wp-content\/uploads\/2026\/08\/article-02-architecture-srv-homelab-docker-1600x900-1-1024x576.png\" alt=\"\" class=\"wp-image-34\" srcset=\"https:\/\/homelab.nvsd.ch\/wp-content\/uploads\/2026\/08\/article-02-architecture-srv-homelab-docker-1600x900-1-1024x576.png 1024w, https:\/\/homelab.nvsd.ch\/wp-content\/uploads\/2026\/08\/article-02-architecture-srv-homelab-docker-1600x900-1-300x169.png 300w, https:\/\/homelab.nvsd.ch\/wp-content\/uploads\/2026\/08\/article-02-architecture-srv-homelab-docker-1600x900-1-768x432.png 768w, https:\/\/homelab.nvsd.ch\/wp-content\/uploads\/2026\/08\/article-02-architecture-srv-homelab-docker-1600x900-1-1536x864.png 1536w, https:\/\/homelab.nvsd.ch\/wp-content\/uploads\/2026\/08\/article-02-architecture-srv-homelab-docker-1600x900-1.png 1600w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">S\u00e9parer le code, la configuration et les donn\u00e9es<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">J\u2019essaie de ne pas m\u00e9langer trois types de fichiers.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Les stacks<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Une stack correspond \u00e0 un projet ou \u00e0 un groupe de services d\u00e9crits par un <code>compose.yaml<\/code>. Elle contient la d\u00e9finition de l\u2019environnement : images, variables, ports, r\u00e9seaux et volumes.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Les donn\u00e9es persistantes<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Les bases de donn\u00e9es, les mod\u00e8les d\u2019IA, les fichiers g\u00e9n\u00e9r\u00e9s et les m\u00e9dias doivent survivre \u00e0 la recr\u00e9ation d\u2019un conteneur. Je les place donc dans <code>data\/<\/code> ou dans un volume Docker explicitement nomm\u00e9.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Les projets et les sources<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Le code de mes sites et de mes applications reste dans <code>projects\/<\/code> ou dans le dossier de la stack lorsqu\u2019il fait partie du build. Cette distinction est particuli\u00e8rement utile pour mes applications Python, mes sites statiques et mes interfaces Next.js.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Un conteneur peut \u00eatre supprim\u00e9 et reconstruit. Les donn\u00e9es importantes, elles, doivent rester sur l\u2019h\u00f4te et \u00eatre sauvegard\u00e9es.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Fedora et SELinux : ne pas contourner le probl\u00e8me<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">J\u2019ai rencontr\u00e9 ce probl\u00e8me avec des dossiers de donn\u00e9es et des sites statiques : le conteneur semblait avoir les bons droits, mais l\u2019application retournait quand m\u00eame une erreur <code>Permission denied<\/code> ou une page <code>403<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La solution habituelle consiste \u00e0 ajouter l\u2019option SELinux au volume. Par exemple :<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>services:\n  web:\n    image: nginx:alpine\n    volumes:\n      - .\/html:\/usr\/share\/nginx\/html:ro,Z<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">L\u2019option <code>Z<\/code> indique que le contenu mont\u00e9 re\u00e7oit un contexte priv\u00e9 pour le conteneur. Lorsque le m\u00eame dossier doit \u00eatre partag\u00e9 par plusieurs conteneurs, l\u2019option <code>z<\/code> peut \u00eatre appropri\u00e9e.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Je pr\u00e9f\u00e8re corriger le volume et les droits plut\u00f4t que d\u00e9sactiver SELinux. D\u00e9sactiver une protection du syst\u00e8me pour faire dispara\u00eetre une erreur rend le Homelab plus difficile \u00e0 s\u00e9curiser et masque la vraie cause du probl\u00e8me.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Pour diagnostiquer un dossier, je peux regarder ses droits classiques et son contexte SELinux :<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ls -ld \/srv\/homelab\nls -Zd \/srv\/homelab<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Je v\u00e9rifie aussi que l\u2019utilisateur du conteneur peut r\u00e9ellement \u00e9crire dans le dossier pr\u00e9vu. Selon l\u2019image utilis\u00e9e, il peut \u00eatre n\u00e9cessaire d\u2019adapter le propri\u00e9taire ou les permissions du sous-dossier, plut\u00f4t que de modifier toute l\u2019arborescence.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Tester une premi\u00e8re stack isol\u00e9e<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Avant de lancer un projet important, je pr\u00e9f\u00e8re valider le chemin complet avec une petite stack. Le principe est toujours le m\u00eame : un dossier d\u00e9di\u00e9, un fichier Compose lisible, un volume explicite et un port qui n\u2019est pas encore utilis\u00e9.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Exemple minimal :<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>services:\n  web:\n    image: nginx:alpine\n    container_name: homelab-test-web\n    ports:\n      - \"8088:80\"\n    volumes:\n      - .\/html:\/usr\/share\/nginx\/html:ro,Z<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Je peux alors construire et d\u00e9marrer cette stack avec :<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker compose up -d\ndocker compose ps<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Puis v\u00e9rifier le r\u00e9sultat dans le navigateur sur <code>http:\/\/localhost:8088<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Une fois le test termin\u00e9, je supprime le conteneur et le r\u00e9seau de cette stack :<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker compose down<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Cette petite exp\u00e9rience valide plusieurs choses \u00e0 la fois : Docker fonctionne, Compose est disponible, le montage du volume est accept\u00e9 par SELinux et le port est accessible depuis le navigateur.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Les ports : une ressource globale \u00e0 surveiller<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Chaque stack poss\u00e8de son propre dossier, mais les ports publi\u00e9s appartiennent \u00e0 toute la machine. Deux conteneurs diff\u00e9rents ne peuvent pas \u00e9couter simultan\u00e9ment sur le m\u00eame port h\u00f4te.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Je l\u2019ai rencontr\u00e9 lorsque j\u2019ai lanc\u00e9 mon Builder NVSD sur le port <code>8085<\/code>, puis la stack WordPress avec le m\u00eame port. WordPress n\u2019a pas pu d\u00e9marrer et Docker a retourn\u00e9 une erreur indiquant que <code>0.0.0.0:8085<\/code> \u00e9tait d\u00e9j\u00e0 utilis\u00e9.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">J\u2019ai conserv\u00e9 le Builder sur <code>8085<\/code> et d\u00e9plac\u00e9 WordPress sur <code>8086<\/code>. Dans mon environnement local, quelques ports servent de rep\u00e8res :<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th>Service<\/th><th class=\"has-text-align-right\" data-align=\"right\">Port local utilis\u00e9<\/th><th>R\u00f4le<\/th><\/tr><\/thead><tbody><tr><td>Builder NVSD Homelab<\/td><td class=\"has-text-align-right\" data-align=\"right\"><code>8085<\/code><\/td><td>R\u00e9f\u00e9rence visuelle et interface de travail<\/td><\/tr><tr><td>WordPress local<\/td><td class=\"has-text-align-right\" data-align=\"right\"><code>8086<\/code><\/td><td>Administration et pr\u00e9visualisation \u00e9ditoriale<\/td><\/tr><tr><td>Dockge<\/td><td class=\"has-text-align-right\" data-align=\"right\"><code>5001<\/code><\/td><td>Gestion des stacks Compose<\/td><\/tr><tr><td>Open WebUI<\/td><td class=\"has-text-align-right\" data-align=\"right\"><code>3000<\/code><\/td><td>Interface de dialogue avec l\u2019IA locale<\/td><\/tr><tr><td>Ollama<\/td><td class=\"has-text-align-right\" data-align=\"right\"><code>11434<\/code><\/td><td>API des mod\u00e8les locaux<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Avant de choisir un nouveau port, je regarde ce qui est d\u00e9j\u00e0 publi\u00e9 :<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker ps --format 'table {{.Names}}\\t{{.Ports}}'\nss -tlnp<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Cette habitude m\u2019\u00e9vite de chercher une erreur dans le code alors que le service ne d\u00e9marre simplement pas parce que le port est d\u00e9j\u00e0 r\u00e9serv\u00e9.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Dockge comme point de contr\u00f4le<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Lorsque le nombre de stacks augmente, les commandes Docker restent indispensables, mais Dockge m\u2019offre une vue plus claire de mes projets Compose.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Je garde toutefois une r\u00e8gle : Dockge ne remplace pas les fichiers sources. Le <code>compose.yaml<\/code>, les variables document\u00e9es et les donn\u00e9es restent les \u00e9l\u00e9ments de r\u00e9f\u00e9rence. Dockge sert \u00e0 d\u00e9marrer, arr\u00eater, reconstruire et consulter les logs plus confortablement.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Cette s\u00e9paration est importante pour la suite. Si je dois d\u00e9placer une stack vers le VPS, je peux reprendre les fichiers du projet et les adapter \u00e0 l\u2019environnement distant. Je ne d\u00e9pends pas uniquement d\u2019une configuration enregistr\u00e9e dans une interface graphique.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Ce que cette pr\u00e9paration m\u2019a appris<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Cette \u00e9tape m\u2019a montr\u00e9 qu\u2019un Homelab est autant une question d\u2019organisation que de puissance mat\u00e9rielle.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">J\u2019ai appris \u00e0 :<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>donner un dossier identifiable \u00e0 chaque projet ;<\/li>\n\n\n\n<li>distinguer les fichiers de configuration des donn\u00e9es persistantes ;<\/li>\n\n\n\n<li>v\u00e9rifier les ports avant de d\u00e9marrer une nouvelle application ;<\/li>\n\n\n\n<li>prendre SELinux en compte d\u00e8s la cr\u00e9ation d\u2019un volume ;<\/li>\n\n\n\n<li>tester une stack minimale avant de d\u00e9ployer un service plus complexe ;<\/li>\n\n\n\n<li>conserver des configurations reproductibles pour le passage vers le VPS.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Ces r\u00e8gles ont ensuite facilit\u00e9 l\u2019installation de WordPress, d\u2019Ollama, d\u2019Open WebUI et de mes applications cr\u00e9atives. Elles m\u2019ont \u00e9galement pr\u00e9par\u00e9 aux probl\u00e8mes que j\u2019ai rencontr\u00e9s sur le VPS : r\u00e9seaux Docker, reverse proxy, permissions et sauvegardes.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Conclusion : une fondation avant les projets<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Mon Homelab local n\u2019a pas commenc\u00e9 par une collection d\u2019applications. Il a commenc\u00e9 par une structure de fichiers, un moteur de conteneurs v\u00e9rifi\u00e9 et quelques r\u00e8gles simples.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Cette fondation me permet maintenant de travailler par petites \u00e9tapes. Je peux cr\u00e9er une stack, la tester localement, observer ses logs, corriger ses permissions, puis la d\u00e9placer vers un autre environnement sans repartir de z\u00e9ro.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Dans le prochain article, je d\u00e9taillerai la cr\u00e9ation de mes premi\u00e8res stacks Docker et l\u2019utilisation de Dockge pour administrer le Builder NVSD, les sites web et les services du Homelab.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<ol class=\"wp-block-list\"><\/ol>\n\n\n\n<ol class=\"wp-block-list\"><\/ol>\n\n\n\n<ul class=\"wp-block-list\">\n<li><\/li>\n<\/ul>\n\n\n\n<ol class=\"wp-block-list\">\n<li><\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">R\u00e9f\u00e9rences techniques<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Documentation officielle : <a href=\"https:\/\/docs.docker.com\/engine\/install\/fedora\/\">Installer Docker Engine sur Fedora<\/a><\/li>\n\n\n\n<li>Documentation officielle : <a href=\"https:\/\/docs.docker.com\/engine\/storage\/bind-mounts\/\">Bind mounts et labels SELinux<\/a><\/li>\n\n\n\n<li>Documentation officielle : <a href=\"https:\/\/docs.docker.com\/reference\/compose-file\/services\/\">Options de volumes dans Compose<\/a><\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>Avant de multiplier les conteneurs, j\u2019ai commenc\u00e9 par pr\u00e9parer Fedora et cr\u00e9er une organisation stable pour mon Homelab. Voici les choix qui structurent encore mon environnement local.<\/p>\n","protected":false},"author":1,"featured_media":35,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11,10,13],"tags":[17,19,4,6,15,14,16],"class_list":["post-32","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-docker","category-fondations","category-tutoriels","tag-docker-compose","tag-docker-engine","tag-dockge","tag-fedora","tag-fedora-44","tag-fedora-silverblue","tag-selinux"],"_links":{"self":[{"href":"https:\/\/homelab.nvsd.ch\/index.php?rest_route=\/wp\/v2\/posts\/32","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/homelab.nvsd.ch\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/homelab.nvsd.ch\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/homelab.nvsd.ch\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/homelab.nvsd.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=32"}],"version-history":[{"count":4,"href":"https:\/\/homelab.nvsd.ch\/index.php?rest_route=\/wp\/v2\/posts\/32\/revisions"}],"predecessor-version":[{"id":38,"href":"https:\/\/homelab.nvsd.ch\/index.php?rest_route=\/wp\/v2\/posts\/32\/revisions\/38"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/homelab.nvsd.ch\/index.php?rest_route=\/wp\/v2\/media\/35"}],"wp:attachment":[{"href":"https:\/\/homelab.nvsd.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=32"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/homelab.nvsd.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=32"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/homelab.nvsd.ch\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=32"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}