El muntatge del volum de Docker falla després de connectar la VPN: comprova el dimoni

Gairebé tots els textos sobre aquest problema culpen el volum, i per això mateix la solució triga tant. Tenies un bind mount que funcionava, la VPN corporativa es va connectar i docker compose up ara falla amb un camí d'origen que falta, un directori buit o un muntatge que el motor es nega a crear. En els entorns que he netejat, el fitxer Compose no havia canviat i el camí era correcte. El que va canviar va ser quin dimoni va rebre la petició, i l'error de muntatge només va ser el primer lloc on aquesta diferència es va fer visible.

El volum no es va moure mai; la petició sí

La -v /srv/app:/app no és una còpia de directori feta per la teva shell. El client la converteix en una petició d'API, i el dimoni que respon resol /srv/app segons el seu propi sistema de fitxers. Quan tots dos costats s'executen al mateix nucli, aquest camí és el que veus al gestor de fitxers. Quan l'endpoint canvia, la mateixa cadena es busca en una màquina que mai no ha sentit a parlar del directori del teu projecte, i el dimoni o bé informa que l'origen falta o bé crea silenciosament un directori buit al seu lloc.

També és per això que un volum amb nom continua funcionant mentre que un bind mount no. -v appdata:/app anomena emmagatzematge que el dimoni posseeix, així que cap camí de l'amfitrió ha d'existir en cap lloc concret. Si canviar un servei d'un bind mount a un volum amb nom fa desaparèixer l'error, no has arreglat el problema. Has confirmat que el client i el dimoni no estan d'acord sobre a quin sistema de fitxers pertany el camí, i aquest desacord torna en el moment que necessites un directori real de l'amfitrió.

Imprimeix l'endpoint abans de tocar el muntatge

Diverses opcions poden apuntar el client a un endpoint, i no sempre coincideixen: l'opció --context , DOCKER_CONTEXT, DOCKER_HOST a la shell actual i el context desat a la configuració del client. En lloc de raonar sobre la precedència, imprimeix-los tots i compara les respostes.

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

La configuració del client és a ~/.docker/config.json a Linux i macOS i a %USERPROFILE%\.docker\config.json a Windows, i un valor exportat al terminal actual substitueix el desat només per a aquella sessió. Si l'endpoint és un nom d'amfitrió en lloc d'un sòcol local, la resolució de noms i les rutes decideixen on aterra, i són precisament el que reescriu un client VPN. Un túnel que afegeix una ruta o canvia el resolutor pot enviar un nom que abans significava aquest portàtil a una adreça dins de la xarxa corporativa.

Compara estat en lloc de configuració. Executa docker ps -a i docker images amb el túnel desconnectat, i després tornat a connectar. Una llista de contenidors diferent és una prova més sòlida que qualsevol fitxer de configuració, perquè mostra que un altre dimoni va respondre a la teva petició.

Pregunta al dimoni si el camí existeix allà

Quan sàpigues a quin dimoni has arribat, fes-li mirar el directori. La forma --mount falla amb un missatge més clar que l'opció curta, perquè valida l'origen abans d'iniciar el contenidor:

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

Si informa que l'origen falta, crea'l a la màquina que ha respost, o apunta el servei a un volum amb nom i copia-hi les dades. El que no hauries de fer és recrear volums i reinstal·lar el motor abans d'aquesta comprovació. Aquestes accions canvien prou l'entorn per amagar la discrepància mentre la deixen al seu lloc.

Hi ha un altre camí que va a un lloc completament diferent: baixar una imatge és feina del dimoni, no del client. Una baixada correcta només demostra que el dimoni pot arribar a un registry, i un bind mount que funciona només demostra que un camí s'ha resolt. Prova cada camí on s'executa realment, o passaràs una tarda amb l'equivocat.

Els noms d'intranet fallen per un motiu diferent

La segona meitat del mateix informe sol ser que el contenidor no pot arribar a intranet.corp.example. Aquest és un mecanisme separat, no un segon problema de volum. Un contenidor obté el seu /etc/resolv.conf en arrencar, generat a partir de la configuració del resolutor del dimoni, així que un servidor DNS que la VPN va afegir després de crear el contenidor no hi apareixerà fins que el contenidor es torni a crear.

El resolutor integrat de Docker en una xarxa definida per l'usuari reenvia les consultes externes als servidors configurats de l'amfitrió, cosa que ajuda quan la VPN reescriu el resolutor de l'amfitrió i perjudica quan el DNS dividit envia una zona interna a un servidor que el dimoni ja no veu. Un mapatge estret i explícit evita la discussió per a noms que no canvien mai:

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

Això escriu una entrada al fitxer hosts del contenidor, així que el contenidor no aprèn res del túnel, i també congela l'adreça. Quan l'amfitrió intern es mou, l'entrada continua malament fins que algú edita el fitxer Compose. Fes-lo servir per a un aparell fix o una base de dades fixada, i deixa que el DNS gestioni els noms que es mouen.

Què canvia realment una reinstal·lació

Reinstal·lar Docker Desktop recrea la VM, el sòcol i la llista de contextos, i el muntatge torna a funcionar. Aquest resultat és real i no ensenya res, i per això la mateixa fallada torna després de la següent actualització de la VPN. La reinstal·lació va substituir l'endpoint que feia servir el client; no va reconciliar el camí que nomena el teu projecte amb el sistema de fitxers que el dimoni llegeix realment.

El meu ordre de treball és curt. Confirma quin endpoint farà servir el client. Confirma quin dimoni ha respost comparant llistes de contenidors. Demana a aquest dimoni que llisti el camí d'origen. Només llavors edita el muntatge, afegeix una entrada hosts o canvia un tipus de volum. Si mantens el fitxer Compose per a un equip que treballa per VPN, prefereix volums amb nom per a les dades que el dimoni ha de posseir, perquè un camí de l'amfitrió no es converteixi mai en part del contracte.