Le montage de volume Docker échoue après la connexion VPN : vérifiez le démon

Votre bind mount est correct. Un VPN change quel démon répond au client, alors affichez l'endpoint, prouvez le chemin là-bas et arrêtez de modifier le volume.

Presque tous les articles sur ce problème accusent le volume, et c'est exactement pourquoi la correction prend si longtemps. Vous aviez un bind mount qui fonctionnait, le VPN d'entreprise s'est connecté, et docker compose up échoue maintenant avec un chemin source manquant, un répertoire vide ou un montage que le moteur refuse de créer. Dans les environnements que j'ai nettoyés, le fichier Compose n'avait pas changé et le chemin était correct. Ce qui avait changé, c'était quel démon recevait la requête, et l'erreur de montage n'était que le premier endroit où cette différence devenait visible.

Le volume n'a jamais bougé ; c'est la requête qui a bougé

L'option -v /srv/app:/app n'est pas une copie de répertoire effectuée par votre shell. Le client la transforme en requête API, et le démon qui répond résout /srv/app par rapport à son propre système de fichiers. Quand les deux côtés tournent sur le même noyau, ce chemin est celui que vous voyez dans votre gestionnaire de fichiers. Quand l'endpoint change, la même chaîne est recherchée sur une machine qui n'a jamais entendu parler du répertoire de votre projet, et le démon signale la source comme manquante ou crée discrètement un répertoire vide à sa place.

C'est aussi pourquoi un volume nommé continue de fonctionner alors qu'un bind mount, non. -v appdata:/app nomme un stockage que le démon possède, donc aucun chemin hôte n'a besoin d'exister à un endroit précis. Si remplacer un service d'un bind mount par un volume nommé fait disparaître l'erreur, vous n'avez pas corrigé le problème. Vous avez confirmé que le client et le démon ne sont pas d'accord sur le système de fichiers auquel le chemin appartient, et ce désaccord revient dès que vous avez de nouveau besoin d'un vrai répertoire hôte.

Affichez l'endpoint avant de toucher au montage

Plusieurs réglages peuvent pointer le client vers un endpoint, et ils ne sont pas toujours d'accord : l'option --context , DOCKER_CONTEXT, DOCKER_HOST dans le shell courant, et le contexte enregistré dans la configuration du client. Plutôt que de raisonner sur la priorité, affichez-les tous et comparez les réponses.

docker context show
docker context ls
docker version
docker info --format "{{.Name}} {{.OperatingSystem}} {{.ServerVersion}}"

La configuration du client se trouve dans ~/.docker/config.json sous Linux et macOS et dans %USERPROFILE%\.docker\config.json sous Windows, et une valeur exportée dans le terminal courant remplace celle enregistrée pour cette session seulement. Si l'endpoint est un nom d'hôte plutôt qu'un socket local, la résolution de noms et les routes décident où il atterrit, et c'est précisément ce qu'un client VPN réécrit. Un tunnel qui ajoute une route ou remplace le résolveur peut envoyer un nom qui désignait autrefois ce portable vers une adresse à l'intérieur du réseau d'entreprise.

Comparez l'état plutôt que la configuration. Lancez docker ps -a et docker images tunnel coupé, puis de nouveau tunnel actif. Une liste de conteneurs différente est une preuve plus solide que n'importe quel fichier de configuration, car elle montre qu'un autre démon a répondu à votre requête.

Demandez au démon si le chemin existe là-bas

Une fois que vous savez quel démon vous avez atteint, faites-lui regarder le répertoire. La forme --mount échoue avec un message plus clair que l'option courte, car elle valide la source avant de démarrer le conteneur :

docker run --rm --mount type=bind,source=/srv/app,target=/app alpine ls -la /app

Si elle signale la source comme manquante, créez-la sur la machine qui a répondu, ou pointez le service vers un volume nommé et copiez-y les données. Ce qu'il ne faut pas faire, c'est recréer des volumes et réinstaller le moteur avant cette vérification. Ces actions changent suffisamment l'environnement pour masquer la discordance tout en la laissant en place.

Un autre chemin s'exécute ailleurs entièrement : tirer une image est un travail de démon, pas de client. Un tirage réussi prouve seulement que le démon peut atteindre un registry, et un bind mount qui fonctionne seulement qu'un chemin a été résolu. Testez chaque chemin là où il s'exécute réellement, sinon vous passerez un après-midi sur le mauvais.

Les noms intranet échouent pour une autre raison

La seconde moitié du même rapport est généralement que le conteneur ne peut pas atteindre intranet.corp.example. C'est un mécanisme distinct, pas un second problème de volume. Un conteneur reçoit son /etc/resolv.conf au démarrage, généré à partir des réglages du résolveur du démon, donc un serveur DNS que le VPN a ajouté après la création du conteneur n'y apparaîtra pas tant que le conteneur n'est pas recréé.

Le résolveur intégré de Docker sur un réseau défini par l'utilisateur transmet les requêtes externes aux serveurs configurés de l'hôte, ce qui aide quand le VPN réécrit le résolveur de l'hôte et nuit quand un DNS divisé envoie une zone interne vers un serveur que le démon ne voit plus. Un mappage étroit et explicite contourne le débat pour les noms qui ne changent jamais :

services:
  web:
    extra_hosts:
      - "intranet.corp.example:10.20.30.40"

Cela écrit une entrée dans le fichier hosts du conteneur, donc le conteneur n'apprend rien du tunnel, et cela fige aussi l'adresse. Quand l'hôte interne se déplace, l'entrée reste fausse jusqu'à ce que quelqu'un modifie le fichier Compose. Utilisez-la pour un équipement fixe ou une base de données épinglée, et laissez le DNS gérer les noms qui bougent.

Ce qu'une réinstallation change réellement

Réinstaller Docker Desktop recrée la VM, le socket et la liste des contextes, et le montage se remet à fonctionner. Ce résultat est réel et n'apprend rien, c'est pourquoi la même panne revient après la mise à jour VPN suivante. La réinstallation a remplacé l'endpoint que le client utilisait ; elle n'a pas réconcilié le chemin que votre projet nomme avec le système de fichiers que le démon lit réellement.

Mon ordre de travail est court. Confirmez quel endpoint le client utilisera. Confirmez quel démon a répondu en comparant les listes de conteneurs. Demandez à ce démon de lister le chemin source. C'est seulement ensuite que vous modifiez le montage, ajoutez une entrée hosts ou changez un type de volume. Si vous maintenez le fichier Compose pour une équipe qui travaille via un VPN, préférez les volumes nommés pour les données que le démon doit posséder, afin qu'un chemin hôte ne fasse jamais partie du contrat.

Articles similaires