Docker-volume-koppeling misluk nadat VPN koppel: ondersoek die daemon

Byna elke beskrywing van hierdie probleem blameer die volume, en dit is juis waarom die regstelling so lank neem. Jy het 'n bind-koppeling gehad wat gewerk het, die korporatiewe VPN het verbind, en docker compose up misluk nou met 'n ontbrekende bronpad, 'n leë gids, of 'n koppeling wat die enjin weier om te skep. In die eenhede wat ek opgeruim het, het die Compose-lêer nie verander nie en was die pad korrek. Wat verander het, was watter daemon die versoek ontvang het, en die koppelingsfout was bloot die eerste plek waar daardie verskil sigbaar geword het.

Die volume het nooit beweeg nie; die versoek het

'n -v /srv/app:/app vlag is nie 'n gidskopie wat jou shell uitvoer nie. Die klient verander dit in 'n API-versoek, en die daemon wat antwoord, los /srv/app op teen sy eie lêerstelsel. Wanneer beide kante op dieselfde kern loop, is daardie pad die een wat jy in jou lêerbestuurder sien. Wanneer die eindpunt verander, word dieselfde string op 'n masjien gesoek wat nog nooit van jou projekgids gehoor het nie, en die daemon rapporteer die bron as ontbrekend of skep stilweg 'n leë gids in sy plek.

Dit is ook waarom 'n benoemde volume bly werk terwyl 'n bind-koppeling dit nie doen nie. -v appdata:/app benoem berging wat die daemon besit, so geen gasheerpad hoef op enige spesifieke plek te bestaan nie. As die omruil van een diens van 'n bind-koppeling na 'n benoemde volume die fout laat verdwyn, het jy nie die probleem reggemaak nie. Jy het bevestig dat die klient en die daemon verskil oor watter lêerstelsel die pad besit, en daardie meningsverskil kom terug sodra jy weer 'n regte gasheergids nodig het.

Druk die eindpunt voordat jy aan die koppeling raak

Verskeie instellings kan die klient na 'n eindpunt wys, en hulle stem nie altyd ooreen nie: 'n --context vlag, DOCKER_CONTEXT, DOCKER_HOST in die huidige shell, en die konteks wat in die klientkonfigurasie gestoor is. Eerder as om oor voorrang te redeneer, druk almal en vergelyk die antwoorde.

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

Die klientkonfigurasie woon by ~/.docker/config.json op Linux en macOS en by %USERPROFILE%\.docker\config.json op Windows, en 'n waarde wat in die huidige terminaal uitgevoer word, oorheers die gestoorde een slegs vir daardie sessie. As die eindpunt 'n gasheernaam is eerder as 'n plaaslike socket, besluit naamresolusie en roetes waar dit beland, en dit is presies wat 'n VPN-klient herskryf. 'n Tonnel wat 'n roete byvoeg of die resolver omruil, kan 'n naam wat vroeër hierdie skootrekenaar beteken het, na 'n adres binne die korporatiewe netwerk stuur.

Vergelyk toestand eerder as konfigurasie. Voer docker ps -a en docker images uit met die tonnel af, en dan weer met dit op. 'n Ander lys houers is sterker bewyse as enige konfigurasielêer, want dit wys dat 'n ander daemon jou versoek beantwoord het.

Vra die daemon of die pad daar bestaan

Sodra jy weet watter daemon jy bereik het, laat dit na die gids kyk. Die --mount vorm misluk met 'n duideliker boodskap as die kort vlag, want dit valideer die bron voordat dit die houer begin:

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

As dit die bron as ontbrekend rapporteer, skep dit op die masjien wat geantwoord het, of wys die diens na 'n benoemde volume en kopieer die data in. Wat jy nie moet doen nie, is om volumes te herskep en die enjin te herinstalleer voordat hierdie kontrole gedoen is. Daardie aksies verander die omgewing genoeg om die wanverhouding te versteek terwyl dit in plek bly.

Nog een pad loop heeltemal elders: om 'n beeld te trek is daemon-werk, nie klient-werk nie. 'n Suksesvolle trek bewys net dat die daemon 'n registry kan bereik, en 'n werkende bind-koppeling bewys net dat 'n pad opgelos het. Toets elke pad waar dit werklik uitgevoer word, of jy sal 'n middag op die verkeerde een spandeer.

Intranet-name misluk om 'n ander rede

Die tweede helfte van dieselfde verslag is gewoonlik dat die houer nie intranet.corp.examplekan bereik nie. Dit is 'n aparte meganisme, nie 'n tweede volume-probleem nie. 'n Houer kry sy /etc/resolv.conf wanneer dit begin, gegenereer uit die daemon-resolver-instellings, so 'n DNS-bediener wat die VPN bygevoeg het nadat die houer geskep is, sal nie daarin verskyn voordat die houer herskep word nie.

Die Docker-ingeboude resolver op 'n gebruikergedefinieerde netwerk stuur eksterne opsoeke na die gasheer se gekonfigureerde bedieners, wat help wanneer die VPN die gasheer-resolver herskryf en seermaak wanneer split-DNS 'n interne sone na 'n bediener stuur wat die daemon nie meer sien nie. 'n Noukeurige, eksplisiete kartering omseil die argument vir name wat nooit verander nie:

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

Dit skryf 'n inskrywing in die houer se hosts-lêer, so die houer leer nooit iets van die tonnel nie, en dit bevries ook die adres. Wanneer die interne gasheer skuif, bly die inskrywing verkeerd totdat iemand die Compose-lêer wysig. Gebruik dit vir 'n vaste toestel of 'n vasgepen databasis, en laat DNS name hanteer wat beweeg.

Wat 'n herinstallasie werklik verander

Herinstallasie van Docker Desktop herskep die VM, die socket en die kontekslys, en die koppeling begin weer werk. Daardie uitkoms is werklik en dit leer niks, en daarom kom dieselfde fout terug ná die volgende VPN-opdatering. Die herinstallasie het die eindpunt wat die klient gebruik het, vervang; dit het nie die pad wat jou projek benoem, met die lêerstelsel wat die daemon werklik lees, versoen nie.

My werkorde is kort. Bevestig watter eindpunt die klient sal gebruik. Bevestig watter daemon geantwoord het deur houerslyste te vergelyk. Vra daardie daemon om die bronpad te lys. Wysig eers daarna die koppeling, voeg 'n hosts-inskrywing by, of verander 'n volume-tipe. As jy die Compose-lêer onderhou vir 'n span wat oor 'n VPN werk, verkies benoemde volumes vir data wat die daemon moet besit, sodat 'n gasheerpad nooit deel van die kontrak word nie.