Pour un projet Docker local sur macOS, utilisez un bind mount lorsque vous devez modifier ou inspecter les mêmes fichiers sous macOS et dans un conteneur ; utilisez un volume nommé lorsque le conteneur doit détenir des données persistantes telles qu'une base de données ou un cache. Le test pratique consiste à déterminer si vous avez besoin d'un accès direct aux fichiers dans le Finder ou une application Mac. Si oui, montez le dossier spécifique du projet. Si non, conservez les données dans un volume nommé géré par Docker.

Qu'est-ce qui change entre les deux types de montages ?

Un bind mount relie un chemin d'accès sur votre Mac à un chemin à l'intérieur d'un conteneur. Les modifications sont visibles des deux côtés, ce qui le rend utile pour le code source, la configuration et les fichiers générés que vous souhaitez conserver dans le dossier de votre projet. Un volume nommé est stocké et géré par Docker, puis attaché à un conteneur au niveau du chemin de votre choix. Docker recommande les volumes pour les données persistantes des conteneurs et lorsque l'hôte n'a pas besoin d'un accès direct aux fichiers. La documentation de Docker sur les bind mounts et la documentation sur les volumes décrivent ces différences.

Vos données Choix habituel Raison
Fichiers sources modifiés dans un IDE Mac Bind mount Le Mac et le conteneur accèdent tous deux aux fichiers du projet.
Répertoire de données d'une base de données Volume nommé Docker gère les données persistantes du conteneur sans partager chaque fichier de base de données via macOS.
Sortie que vous souhaitez ouvrir ou utiliser avec des outils Mac Bind mount La sortie apparaît à l'emplacement choisi sur le Mac.
État temporaire pouvant être supprimé Aucun par défaut Déterminez si les données ont réellement besoin de persister ; un volume nommé subsiste après la suppression du conteneur, sauf si vous le supprimez séparément.

Pourquoi macOS rend ce choix important

Docker Desktop exécute des conteneurs Linux au sein d'une machine virtuelle Linux, servant ainsi d'intermédiaire pour les accès entre le système de fichiers Mac et les conteneurs. La documentation des paramètres de Docker indique que le partage de fichiers avec l'hôte entraîne une surcharge ; partager un nombre excessif de fichiers peut augmenter la charge processeur et ralentir les opérations sur le système de fichiers. Elle recommande spécifiquement de conserver les éléments autres que le code, tels que les caches et les bases de données, dans un volume de données lorsque les performances comptent. Paramètres de Docker Desktop

Cette directive ne signifie pas que tout bind mount sera lent. Elle signifie que le type de données et votre flux de travail concret sont déterminants. L'arborescence des sources d'un projet est un candidat naturel pour un bind mount, car le but est de pouvoir l'éditer sur le Mac. Les nombreux fichiers en constante évolution d'une base de données n'ont généralement pas besoin d'être consultés dans le Finder : un volume nommé est donc un meilleur point de départ. Pour les dépôts particulièrement volumineux, Docker Desktop documente également les partages de fichiers synchronisés (Synchronized file shares) comme une option soumise à abonnement pouvant améliorer les performances des bind mounts ; cela modifie le comportement du partage de fichiers, mais pas la distinction fondamentale entre le code source visible par l'hôte et le volume géré par Docker. Synchronized file shares

Configurer un dossier de projet et un volume de base de données

Depuis le Terminal, placez-vous dans le répertoire de votre projet et utilisez un bind mount pour le code. Cet exemple monte le dossier actuel sur /workspace dans un conteneur Alpine jetable ; adaptez l'image ou la commande selon les besoins de votre conteneur de développement.

docker run --rm -it \
  --mount "type=bind,source=$PWD,target=/workspace" \
  alpine:latest sh

Dans les shells par défaut de macOS, $PWD est remplacé par le répertoire courant. Mettre l'intégralité de l'argument de montage entre guillemets permet de préserver le chemin développé sur l'hôte si le nom d'un dossier contient des espaces. La syntaxe --mount de Docker est explicite. Le chemin hôte doit impérativement exister : Docker précise qu'un chemin source manquant entraîne par défaut l'échec de --mount. Un bind mount est accessible en écriture sauf s'il est configuré en lecture seule, ce qui permet à un processus du conteneur de modifier les fichiers situés dans le répertoire Mac monté. Utilisez readonly lorsque le conteneur a uniquement besoin de lire le projet. Options et comportement des bind mounts

Pour les données appartenant au conteneur, créez et attachez plutôt un volume nommé. Cette commande lance PostgreSQL avec un volume situé sur son répertoire de données standard :

docker volume create project-db

docker run --name project-postgres \
  --mount type=volume,source=project-db,target=/var/lib/postgresql/data \
  -e POSTGRES_PASSWORD='local-dev-only' \
  -d postgres:17

Ici, project-db est le nom du volume persistant, et POSTGRES_PASSWORD est un paramètre local fourni à titre d'exemple, et non une méthode recommandée pour gérer les secrets en production. Supprimer le conteneur ne supprime pas automatiquement un volume nommé. Cette persistance facilite le remplacement d'un conteneur, mais signifie également que d'anciennes données peuvent subsister et qu'une nouvelle exécution risque de les réutiliser. Notez soigneusement le nom du volume et la configuration du conteneur nécessaire pour s'y reconnecter.

Vérifier la visibilité, la portabilité et le nettoyage

Avant de choisir, demandez-vous : vais-je ouvrir ou modifier ces fichiers précis avec des logiciels Mac ? Si c'est le cas, montez via bind mount le dossier le plus restreint possible répondant à votre besoin, plutôt que de partager une portion inutilement large de votre répertoire personnel. Docker note que macOS et Linux gèrent la casse des noms de fichiers différemment, ce qui peut révéler des problèmes de sensibilité à la casse au sein d'un conteneur. Vérifiez attentivement les noms si le projet se comporte différemment sous Linux. Remarques sur le partage de fichiers dans Docker Desktop

Si les fichiers doivent rester cantonnés à l'intérieur du conteneur, optez pour un volume nommé et gérez-le avec les commandes de volume de Docker. Le volume n'est pas un dossier du Finder accessible dans l'emplacement habituel du projet ; Docker Desktop stocke ses données Linux dans l'environnement de sa machine virtuelle. Considérez la suppression d'un volume comme une étape de suppression de données, et sauvegardez séparément le contenu des volumes importants. Les recommandations de Docker en matière de sauvegarde précisent que les images de conteneurs n'incluent pas les modifications apportées au système de fichiers stockées dans les volumes attachés. Sauvegarde et restauration dans Docker Desktop

Un bind mount dépend de la présence du chemin d'accès sur l'hôte, ce qui peut le rendre moins portable entre différents Mac ayant des arborescences de répertoires distinctes. Un volume nommé évite cette dépendance au chemin du projet, mais ses données nécessitent tout de même un plan explicite de sauvegarde ou de migration. Par conséquent, pour de nombreux projets de développement sur Mac, le choix par défaut le plus simple consiste à utiliser un bind mount pour le code source et un volume nommé pour l'état de la base de données, en documentant chaque emplacement de données dans la configuration Compose ou dans les instructions d'exécution du projet.

Sources