Comment utiliser Docker dans un homelab sur un NAS ou un serveur domestique

Docker vous permet d'utiliser un homelab comme plateforme d'applications reproductible en définissant chaque service, port, réseau et chemin de données persistantes avant le déploiement.

Sur un NAS ou un serveur domestique, cela signifie que vous pouvez exécuter le filtrage DNS, la surveillance, les médias, la synchronisation de fichiers, les tableaux de bord et d'autres applications auto-hébergées sans installer chaque dépendance directement sur l'hôte. L'objectif pratique n'est pas simplement de démarrer un conteneur une fois. Il s'agit de construire une pile qui survit aux redémarrages, conserve ses données lors des mises à jour, reste accessible uniquement là où c'est prévu, et peut être restaurée en cas de problème.

Ce que fait Docker dans un homelab

Docker empaquette une application et ses dépendances d'exécution dans une image, puis lance cette image en tant que conteneur. L'hôte fournit toujours le CPU, la mémoire, le stockage et le réseau, mais chaque service bénéficie d'un environnement défini, plus facile à reproduire qu'une longue liste d'étapes d'installation manuelle.

Cinq concepts expliquent la plupart des configurations Docker que vous utiliserez dans un homelab :

Un conteneur doit être considéré comme remplaçable. Votre fichier Compose, les paramètres d'environnement et les données persistantes sont les éléments qui rendent le service récupérable.

Ce dont vous avez besoin avant d'installer Docker

Commencez par décider où Docker sera exécuté. Un système d'exploitation NAS peut fournir un gestionnaire d'applications visuel, tandis qu'un serveur domestique Linux standard utilise généralement Docker Engine et le plugin Compose en ligne de commande. Une machine virtuelle peut également fonctionner si vous souhaitez séparer Docker de l'hyperviseur de base.

• Confirmez si l'hôte utilise amd64 ou arm64 afin de choisir des images compatibles.
• Réservez une adresse LAN stable via une réservation DHCP ou une IP statique.
• Créez un emplacement persistant unique pour les configurations de conteneurs et les bases de données, séparé des partages médias volumineux.
• Choisissez soit les projets Compose, soit un gestionnaire visuel comme flux de travail principal au lieu de mélanger des méthodes non documentées.
• Décidez quels services resteront uniquement sur le LAN et lesquels pourraient éventuellement nécessiter un accès à distance.
• Choisissez une deuxième destination de stockage pour les sauvegardes des fichiers Compose et des données persistantes.

Lorsque l'hôte lui-même est encore en cours de planification, le guide sur comment construire et configurer votre propre serveur domestique peut aider à établir la base de stockage, réseau et système d'exploitation avant d'ajouter Docker.

Installez Docker et vérifiez l'hôte

La méthode d'installation dépend du système d'exploitation, mais la séquence de validation doit rester cohérente. Certaines plateformes NAS intègrent Docker derrière une interface d'application. Un hôte Linux nécessite normalement Docker Engine et le plugin Compose, tandis que Windows et macOS conviennent mieux à l'apprentissage ou aux tests qu'à un service NAS en fonctionnement permanent.

Une configuration Docker pour débutants en homelab montre la séquence utile d'installation de Docker, d'exécution d'un premier conteneur, d'organisation des dossiers de projet et de déplacement des services répétables dans Compose. Utilisez cette séquence comme cadre, puis suivez la méthode d'installation requise par votre propre NAS ou distribution Linux.

Vérifiez Docker et Compose

Après l'installation, ouvrez un terminal sur l'hôte et confirmez que Docker et Compose répondent tous deux :

docker --version
docker compose version

Si l'une des commandes est manquante, arrêtez-vous ici et corrigez l'installation avant de créer les dossiers d'application. Sur Linux, confirmez également que le service Docker démarre automatiquement et que le compte utilisé pour la gestion est protégé. L'accès au démon Docker équivaut à un accès administratif à l'hôte.

Exécutez un conteneur de validation jetable

Utilisez un conteneur temporaire pour confirmer que le démon peut télécharger une image et la démarrer :

docker run --rm hello-world

Un résultat réussi confirme le chemin de base entre le client en ligne de commande, le démon Docker et le registre d'images. Le --rm cette option supprime ce conteneur de test après sa sortie, afin qu'il ne fasse pas partie de votre pile permanente.

Confirmez les commandes d'administration de base

docker ps
docker ps -a
docker images

docker ps affiche les conteneurs en cours d'exécution, docker ps -a inclut les conteneurs arrêtés, et docker images affiche les images stockées sur l'hôte. Ces trois vues suffisent souvent à déterminer si un problème est causé par un conteneur arrêté, une image jamais téléchargée ou un service jamais créé.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Déployez votre première stack Docker Compose

Ponctuel docker run les commandes sont utiles pour les tests, mais Compose est plus facile à répéter, revoir, sauvegarder et migrer. Chaque projet a son propre répertoire et un compose.yaml fichier qui enregistre l'image, les ports, le stockage, le comportement de redémarrage et le réseau.

Créez un répertoire de projet

L'exemple suivant crée une petite page de démarrage Nginx. Elle est volontairement simple, mais teste le même flux de travail que vous utiliserez pour un tableau de bord, un serveur multimédia, un outil de surveillance ou un cloud personnel :

mkdir -p ~/docker/start-page/site
cd ~/docker/start-page
printf '<h1>Docker homelab est en cours d'exécution</h1>\n' > site/index.html

Garder chaque service dans un dossier séparé facilite l'identification de son fichier Compose, des valeurs d'environnement et des données persistantes. Un NAS plus grand peut utiliser un chemin tel que /docker/start-page ou un dossier partagé dédié au lieu du répertoire personnel.

Créez le fichier Compose

Créez un fichier nommé compose.yaml dans le répertoire du projet :

services :
  start-page :
    image : nginx:alpine
    nom_du_conteneur : homelab-start-page
    ports :
      - "8080:80"
    volumes :
      - ./site:/usr/share/nginx/html:ro
    redémarrage : sauf arrêt
    réseaux :
      - homelab

réseaux :
homelab :
driver : bridge

Le mappage de port envoie les requêtes du port 8080 sur le NAS vers le port 80 à l'intérieur du conteneur. Le montage de liaison rend le local site répertoire disponible dans Nginx en tant que contenu en lecture seule. La politique de redémarrage relance le service après un redémarrage normal sauf si vous l'avez arrêté intentionnellement.

Cet exemple publie le port 8080 sur l'hôte. Gardez le transfert de port du routeur désactivé pendant les tests. Lorsque le service doit être accessible uniquement depuis l'hôte Docker lui-même, liez-le à la boucle locale avec 127.0.0.1:8080:80 à la place.

Démarrer et vérifier le service

docker compose up -d
docker compose ps
docker compose logs --tail=100

Ouvrir http://NAS-IP:8080 depuis un appareil sur le même réseau. La page doit afficher « Docker homelab est en cours d'exécution. » Ensuite, redémarrez l'hôte une fois et confirmez que le conteneur redémarre automatiquement.

Les commandes que vous utiliserez le plus souvent sont :

Évitez d'ajouter -v à docker compose down sauf si vous souhaitez intentionnellement supprimer les volumes gérés par Compose. Supprimer le conteneur est une opération courante ; supprimer les données persistantes ne l'est pas.

Si votre système d'exploitation NAS propose un gestionnaire d'applications Docker visuel, les mêmes champs restent importants. L'interface doit afficher l'image, les ports hôtes, les ports du conteneur, les chemins montés, les variables d'environnement et le comportement de redémarrage. Ce flux de travail du système d'exploitation NAS est utile lorsque vous préférez une interface graphique mais souhaitez tout de même des chemins d'applications prévisibles.

Stockez les données Docker en toute sécurité sur un NAS

Les conteneurs sont jetables, mais les données du service ne le sont pas. La plupart des pannes dans un homelab après une mise à jour proviennent d'une base de données, d'un fichier de compte ou d'une configuration d'application sauvegardée uniquement dans la couche du conteneur. Recréer ce conteneur produit alors une installation propre au lieu de restaurer le service original.

Un montage par liaison mappe un fichier ou répertoire hôte connu dans un conteneur. Un volume est géré par Docker dans sa zone de stockage. Les deux peuvent préserver les données, mais diffèrent en visibilité et en flux de sauvegarde.

Séparez les données d'application des médias volumineux

Gardez les configurations, bases de données, vignettes, index et autres charges de petits fichiers sur un docker-data emplacement sauvegardé fréquemment. Les gros films, photos, enregistrements et téléchargements peuvent rester sur des partages médias normaux. Cette séparation clarifie la portée de la sauvegarde et peut empêcher les métadonnées de l'application de concurrencer les charges de stockage séquentiel importantes.

Avant de déployer une application réelle, notez chaque chemin hôte utilisé dans son fichier Compose. Une disposition simple pourrait ressembler à ceci :

/docker
  /nom-application
    compose.yaml
    .env
    /config
    /data

Sauvegardez ce qui recrée le service

Sauvegardez le fichier Compose, ainsi que tout .env fichiers, certificats, configuration personnalisée et données persistantes des conteneurs. Les images n'ont normalement pas besoin d'être sauvegardées car elles peuvent être retéléchargées. Protégez soigneusement les fichiers d'environnement car ils peuvent contenir des mots de passe, des jetons ou des identifiants de base de données.

La règle de sauvegarde 3-2-1 offre un modèle de planification utile, mais une sauvegarde Docker n'est complète que lorsque vous pouvez recréer la stack et restaurer ses données. Testez une restauration non critique avant que votre homelab ne devienne dépendant du service.

Lors de l'utilisation d'une interface NAS visuelle, vérifiez où ses données persistantes des conteneurs sont stockées au lieu de supposer que l'interface les protège automatiquement.

Comment fonctionne le réseau Docker dans un homelab

Le réseau Docker contrôle deux chemins différents : la communication entre conteneurs et l'accès depuis des appareils extérieurs à Docker. Garder ces chemins séparés réduit la publication inutile de ports et facilite la compréhension des piles multi-services.

Lisez les mappages de ports de gauche à droite

Dans 8080:80, le port 8080 appartient à l'hôte Docker et le port 80 appartient au conteneur. Les appareils sur le LAN se connectent à l'adresse NAS et au port hôte. Docker redirige ensuite la requête vers le port interne de l'application.

Ne publiez un port hôte que lorsqu'un navigateur, un téléphone, une télévision ou un autre appareil non Docker a besoin d'un accès direct. Une base de données utilisée uniquement par un autre conteneur n'a généralement pas besoin d'un port publié.

Utilisez des réseaux personnalisés pour les services liés

Compose peut créer un réseau pont défini par l'utilisateur pour chaque pile. Les conteneurs sur ce réseau peuvent se joindre par nom de service, ce qui signifie qu'une application web peut se connecter à un service nommé base de données sans dépendre d'une adresse IP de conteneur changeante.

Un exemple pratique de réseaux Docker personnalisés et isolation des conteneurs montre comment la résolution de noms et la connectivité changent lorsque les conteneurs sont placés sur des réseaux ponts séparés ou connectés à plus d'un réseau.

Regroupez les services qui doivent réellement communiquer. Gardez les piles non liées sur des réseaux séparés, et ne publiez pas une base de données interne, un cache ou une file de messages simplement pour que les conteneurs puissent se voir.

Gardez l'accès LAN séparé de l'accès Internet

Un service accessible à NAS-IP:8080 sur votre réseau domestique n'est pas automatiquement accessible depuis Internet. L'exposition publique nécessite normalement une règle de transfert de routeur, un tunnel, un VPN ou un autre chemin d'accès à distance. Considérez cette étape supplémentaire comme une décision de sécurité distincte plutôt que comme une partie de chaque déploiement.

Exposez les services Docker en toute sécurité

L'accès à distance est l'endroit où un homelab pratique peut devenir une véritable faille de sécurité. La solution par défaut la plus sûre est de garder les interfaces des applications privées sur le LAN et d'exposer uniquement une couche d'accès contrôlée lorsque l'utilisation à distance est nécessaire.

Utilisez un VPN pour un accès à distance privé

Un VPN privé ou un réseau superposé permet aux appareils approuvés d'accéder aux services domestiques sans publier chaque application directement. C'est souvent la solution la plus simple pour les tableaux de bord personnels, les panneaux d'administration, l'accès aux fichiers et les services utilisés par seulement quelques personnes de confiance. Le guide sur l'accès à distance sécurisé couvre la décision plus large entre l'accès basé sur VPN et l'exposition publique sur le web pour les serveurs domestiques.

Utilisez un proxy inverse comme point d'entrée public

Lorsqu'un service web doit être public, un proxy inverse offre un point unique pour les noms d'hôtes, certificats, règles de routage et contrôles d'accès. Exposez le proxy plutôt que de rediriger un port de routeur séparé vers chaque application. Gardez les bases de données, interfaces d'administration et ports de services internes sur des réseaux Docker privés autant que possible.

Utilisez HTTPS et des règles de ports délibérées

Toute connexion ou session accessible en dehors du réseau domestique doit utiliser HTTPS. Vérifiez périodiquement les règles de redirection du routeur et supprimez les entrées qui ne sont plus nécessaires. L'automatisation des certificats aide, mais ne remplace pas une authentification forte, des mises à jour régulières ou un contrôle rigoureux des services publics.

Mettez à jour, surveillez et restaurez la pile

Un homelab Docker reste gérable lorsque la maintenance suit une séquence répétable. Ne mettez pas à jour tous les services aveuglément en même temps. Commencez par une sauvegarde, mettez à jour une pile, et vérifiez les chemins importants avant de passer à l'application suivante.

Utilisez une séquence de mise à jour contrôlée

cd ~/docker/start-page
docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=100

Pour un service important, notez la balise de l'image fonctionnelle avant une mise à jour afin d'avoir une référence de retour en arrière. Après le redéploiement, testez la connexion, le stockage monté, la connexion à la base de données, l'accès LAN et toute route de proxy inverse. Un état « Up » du conteneur prouve seulement que le processus fonctionne ; cela ne garantit pas que l'application est saine.

Surveillez les signaux qui dérivent silencieusement

• Utilisation du disque système par d'anciennes images, couches modifiables, journaux et données abandonnées.
• Nombre de redémarrages du conteneur et erreurs répétées dans les journaux de l'application.
• Redirections inattendues du routeur ou ports hôtes qui ne sont plus nécessaires.
• Âge de la sauvegarde, taille de la sauvegarde et possibilité d'ouvrir la dernière archive.
• Pression mémoire lorsque des services supplémentaires sont ajoutés à un petit NAS.

Utilisez les commandes de nettoyage uniquement après avoir vérifié ce qu'elles vont supprimer. Les images inutilisées consomment de l'espace, mais un nettoyage agressif peut aussi supprimer des couches mises en cache ou des volumes inutilisés qui sont encore importants pour un plan de récupération.

Répétez une restauration

Choisissez un service non critique, arrêtez-le, déplacez ses données persistantes de côté, puis reconstruisez-le à partir du fichier Compose. Ensuite, restaurez les données et confirmez que les comptes, paramètres et l'état de l'application sont revenus. Une restauration réussie est une preuve plus solide qu'un travail de sauvegarde réussi.

Problèmes courants et solutions pour Docker Homelab

Choisissez le prochain conteneur pour votre homelab

Après que la première pile Compose ait survécu à un redémarrage et à une petite mise à jour, ajoutez un service qui répond à un besoin réel du foyer. Chaque catégorie introduit une leçon opérationnelle différente :

Un filtre au niveau DNS est utile lorsque tout le foyer bénéficie d'un service réseau unique. Pour les flux de travail de stockage, la synchronisation privée de fichiers montre pourquoi les configurations et bases de données doivent rester en dehors de la couche de conteneurs jetables. Un serveur multimédia Plex ajoute des permissions médias, le placement des métadonnées et les éventuels besoins de transcodage.

N'ajoutez pas plusieurs services critiques en même temps. Une petite pile avec des chemins documentés, une exposition limitée et une sauvegarde testée est plus utile qu'un tableau de bord surchargé que personne ne peut reconstruire de manière fiable.

FAQ

Puis-je utiliser Docker sur un NAS basé sur ARM ?

Souvent, oui. L'image doit publier une version pour l'architecture du NAS. Vérifiez la plateforme proposée par l'image avant le déploiement, surtout pour les petits projets qui peuvent supporter amd64 mais pas arm64. Une incompatibilité d'architecture peut empêcher le conteneur de démarrer même si le fichier Compose est correct.

Combien de RAM un homelab Docker nécessite-t-il ?

Il n'y a pas de nombre universel car un filtre DNS, un serveur média, une base de données et un service d'IA ont des profils mémoire très différents. Listez les services que vous prévoyez d'exécuter, commencez avec une petite pile, mesurez l'utilisation maximale sur plusieurs jours et gardez une marge pour le système d'exploitation, le cache du système de fichiers, les mises à jour et les pics temporaires.

Ai-je besoin de Docker Compose si mon NAS a une interface graphique ?

Non. Une interface graphique bien conçue peut gérer un homelab simple, surtout lorsqu'elle expose chaque chemin, port, variable et paramètre de redémarrage. Compose devient plus utile lorsque vous souhaitez une configuration versionnée, une migration facilitée, une récupération répétable ou plusieurs services liés dans une même pile.

Chaque conteneur doit-il avoir son propre réseau ?

Pas nécessairement. Créez des réseaux autour des limites des applications plutôt que d'attribuer un réseau à chaque conteneur individuel. Une application web et sa base de données peuvent partager un réseau privé, tandis qu'un serveur média non lié utilise un autre. Publiez uniquement les ports dont les appareils non-Docker ont besoin.

Quelle est la manière la plus sûre d'accéder aux services Docker à distance ?

Pour un accès personnel, un VPN personnel que vous gérez chez vous peut réduire le besoin d'exposer plusieurs ports d'application publiquement. Les services publics nécessitent généralement un proxy inverse, HTTPS, une authentification forte, des mises à jour régulières et une décision réfléchie sur ce qui reste privé.

Comment savoir si une sauvegarde Docker est complète ?

Vous devriez pouvoir recréer les conteneurs à partir du fichier Compose et restaurer l'état de l'application à partir des données persistantes sauvegardées. Une sauvegarde contenant uniquement des images ou un fichier Compose sans les répertoires de base de données et de configuration n'est pas suffisante pour la plupart des services avec état.

Construisez un Homelab que Vous Pouvez Recréer

Apprendre à utiliser Docker dans un homelab ne consiste pas tant à accumuler des conteneurs qu'à rendre chaque service reproductible. Vérifiez Docker en premier, gardez un projet Compose par application, stockez l'état en dehors du conteneur, publiez uniquement les ports nécessaires et testez une restauration avant que le service ne devienne important.

Une fois que la première pile survit à un redémarrage, une mise à jour et un exercice de récupération, ajoutez la prochaine application avec la même rigueur. Cette séquence transforme un NAS, qui est un simple endroit où les conteneurs fonctionnent, en un serveur domestique que vous pouvez comprendre, maintenir et reconstruire.