Docker-folume-mount mislearret nei't VPN ferbynt: kontrolearje de daemon

Suver elke beskriuwing fan dit probleem jout it folume de skuld, en dat is krekt wêrom't de oplossing sa lang duorret. Do hiest in bind mount dy't wurke, it bedriuws-VPN ferbûn, en docker compose up mislearret no mei in ûntbrekkend boarnepaad, in lege map, of in mount dy't de motor wegert te meitsjen. Yn de omjouwings dy't ik opromme haw, wie it Compose-bestân net feroare en wie it paad korrekt. Wat feroare wie hokker daemon it fersyk krige, en de mount-flater wie gewoan it earste plak dêr't dat ferskil sichtber waard.

It folume ferhuze nea; it fersyk ferhuze

In -v /srv/app:/app flagge is gjin mapkeapy dy't dyn shell docht. De klant makket der in API-fersyk fan, en de daemon dy't antwurdet, lûkt /srv/app tsjin syn eigen bestânsysteem op. As beide kanten op deselde kernel rinne, is dat it paad dat do yn dyn bestânsbehearder sjochst. As it endpoint feroaret, wurdt deselde tekenrige socht op in masine dy't nea fan dyn projektmap heard hat, en de daemon meldt de boarne as ûntbrekkend of makket stil in lege map yn 't plak.

Dat is ek wêrom't in neamd folume bliuwt wurkjen wylst in bind mount dat net docht. -v appdata:/app neamt opslach dy't de daemon besit, dus gjin hostpaad hoecht earne spesifyk te bestean. As it omwikseljen fan ien tsjinst fan in bind mount nei in neamd folume de flater ferdwine lit, hast it probleem net oplost. Do hast befêstige dat de klant en de daemon it net iens binne oer by hokker bestânsysteem it paad heart, en dat ferskil komt werom op it stuit dat do wer in echte hostmap nedich hast.

Printsje it endpoint foardat do de mount oanrekkest

Ferskate ynstellings kinne de klant nei in endpoint wize, en se binne it net altyd iens: in --context flagge, DOCKER_CONTEXT, DOCKER_HOST yn 'e hjoeddeiske shell, en de kontekst dy't yn 'e klantkonfiguraasje bewarre is. Ynstee fan oer foarrang te riddenearjen, printsje se allegear en fergelykje de antwurden.

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

De klantkonfiguraasje stiet yn ~/.docker/config.json op Linux en macOS en yn %USERPROFILE%\.docker\config.json op Windows, en in wearde dy't yn 'e hjoeddeiske terminal eksportearre wurdt, oerhearsket de bewarre allinne foar dy sesje. As it endpoint in hostnamme is ynstee fan in lokale socket, beslute nammeresolúsje en rûtes wêr't it delkomt, en dat is krekt wat in VPN-klant oerskriuwt. In tunnel dy't in rûte tafoeget of de resolver omwikselet, kin in namme dy't eartiids dizze laptop betsjutte, nei in adres binnen it bedriuwsnetwurk stjoere.

Fergelykje steat ynstee fan konfiguraasje. Rin docker ps -a en docker images mei de tunnel del, en dan wer mei de tunnel op. In oare list fan konteners is sterker bewiis as hokker konfiguraasjebestân dan ek, want it lit sjen dat in oare daemon dyn fersyk beantwurde.

Freegje de daemon oft it paad dêr bestiet

As do witst hokker daemon do berikt hast, lit him dan nei de map sjen. De foarm --mount mislearret mei in dúdliker berjocht as de koarte flagge, want hy falidearret de boarne foardat er de kontener start:

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

As er de boarne as ûntbrekkend meldt, meitsje him dan op 'e masine dy't antwurde, of wizigje de tsjinst nei in neamd folume en kopiearje de gegevens der yn. Wat do net dwaan moatst, is folumes opnij meitsje en de motor opnij ynstallearje foar dizze kontrôle. Dy aksjes feroarje de omjouwing genôch om de misferhâlding te ferbergjen wylst se dy op syn plak litte.

Noch ien paad rint hiel earne oars: in image lûke is daemonwurk, gjin klantwurk. In suksesfolle pull bewist allinne dat de daemon in registry berikke kin, en in wurkjende bind mount allinne dat in paad oplost is. Test elk paad dêr't it echt útfierd wurdt, oars bringst do in middei troch oan it ferkearde.

Intranetnammen mislearje om in oare reden

De twadde helte fan itselde rapport is meastentiids dat de kontener intranet.corp.examplenet berikke kin. Dat is in apart meganisme, gjin twadde folumeprobleem. In kontener krijt syn /etc/resolv.conf by it starten, generearre út 'e resolver-ynstellings fan de daemon, dus in DNS-tsjinner dy't it VPN tafoege neidat de kontener makke wie, sil dêr net ferskine oant de kontener opnij makke wurdt.

De ynboude resolver fan Docker op in troch de brûker definiearre netwurk stjoert eksterne opfragen troch nei de konfigurearre tsjinners fan 'e host, wat helpt as it VPN de hostresolver oerskriuwt en skea docht as split DNS in ynterne sône nei in tsjinner stjoert dy't de daemon net mear sjocht. In smelle, eksplisite mapping giet de diskusje foar nammen dy't nea feroarje foarby:

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

Dit skriuwt in ynskriuwing yn it hosts-bestân fan 'e kontener, dus de kontener leart neat oer de tunnel, en it befriest ek it adres. As de ynterne host ferhuzet, bliuwt de ynskriuwing ferkeard oant immen it Compose-bestân bewurket. Brûk it foar in fêst apparaat of in fêstsette database, en lit DNS nammen beheare dy't bewege.

Wat in opnij-ynstallaasje eins feroaret

It opnij ynstallearjen fan Docker Desktop makket de VM, de socket en de kontekstlist opnij, en de mount begjint wer te wurkjen. Dat resultaat is echt en it leart neat, en dêrom komt deselde flater werom nei de folgjende VPN-update. De opnij-ynstallaasje ferfong it endpoint dat de klant brûkte; it brocht it paad dat dyn projekt neamt net yn oerienstimming mei it bestânsysteem dat de daemon eins lêst.

Myn wurkfolchoarder is koart. Befêstigje hokker endpoint de klant brûke sil. Befêstigje hokker daemon antwurde troch kontenerlisten te fergelykjen. Freegje dy daemon it boarnepaad te listjen. Pas dêrnei bewurkest do de mount, foeget in hosts-ynskriuwing ta, of feroarest in folumetype. As do it Compose-bestân ûnderhâldst foar in team dat oer in VPN wurket, foarkies dan neamde folumes foar gegevens dy't de daemon besitte moat, sadat in hostpaad nea diel fan it kontrakt wurdt.