Montimi i vëllimit të Docker dështon pasi lidhet VPN-i: kontrollo daemon-in

Pothuajse çdo shkrim për këtë problem fajëson vëllimin, dhe pikërisht për këtë rregullimi zgjat kaq shumë. Kishe një bind mount që funksiononte, VPN-i i korporatës u lidh, dhe docker compose up tani dështon me një shteg burimi që mungon, një drejtori bosh ose një montim që motori refuzon ta krijojë. Në mjediset që kam pastruar, skedari Compose nuk ishte ndryshuar dhe shtegu ishte i saktë. Ajo që ndryshoi ishte cili daemon mori kërkesën, dhe gabimi i montimit ishte thjesht vendi i parë ku ai ndryshim u bë i dukshëm.

Vëllimi nuk u zhvendos kurrë; kërkesa u zhvendos

Flamuri -v /srv/app:/app nuk është një kopje drejtorie e kryer nga shell-i yt. Klienti e kthen atë në një kërkesë API, dhe daemoni që përgjigjet zgjidh /srv/app kundrejt sistemit të vet të skedarëve. Kur të dyja anët ekzekutohen në të njëjtin kernel, ai shteg është ai që shihni në menaxherin e skedarëve. Kur endpoint-i ndryshon, i njëjti varg kërkohet në një makinë që nuk ka dëgjuar kurrë për drejtorinë e projektit tuaj, dhe daemoni ose raporton burimin si që mungon ose krijon në heshtje një drejtori bosh në vend të tij.

Kjo është edhe arsyeja pse një vëllim i emërtuar vazhdon të funksionojë ndërsa një bind mount jo. -v appdata:/app emërton ruajtje që daemoni zotëron, kështu që asnjë shteg hosti nuk duhet të ekzistojë në një vend të caktuar. Nëse kalimi i një shërbimi nga bind mount në vëllim të emërtuar e bën gabimin të zhduket, nuk e ke rregulluar problemin. Ke konfirmuar që klienti dhe daemoni nuk bien dakord se cilit sistem skedarësh i përket shtegu, dhe ai mospajtim kthehet në momentin kur të duhet përsëri një drejtori e vërtetë hosti.

Printo endpoint-in përpara se të prekësh montimin

Disa cilësime mund ta drejtojnë klientin drejt një endpoint-i, dhe ato nuk bien gjithmonë dakord: --context flamuri, DOCKER_CONTEXT, DOCKER_HOST në shell-in aktual, dhe konteksti i ruajtur në konfigurimin e klientit. Në vend që të arsyetosh për përparësinë, printoji të gjitha dhe krahaso përgjigjet.

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

Konfigurimi i klientit ndodhet në ~/.docker/config.json në Linux dhe macOS dhe në %USERPROFILE%\.docker\config.json në Windows, dhe një vlerë e eksportuar në terminalin aktual zëvendëson atë të ruajtur vetëm për atë sesion. Nëse endpoint-i është emër hosti në vend të një socket lokal, zgjidhja e emrave dhe rrugët vendosin ku ateron, dhe pikërisht ato rishkruan një klient VPN. Një tunel që shton një rrugë ose zëvendëson resolver-in mund të dërgojë një emër që dikur nënkuptonte këtë laptop në një adresë brenda rrjetit të korporatës.

Krahaso gjendjen, jo konfigurimin. Ekzekuto docker ps -a dhe docker images me tunelin poshtë, dhe më pas përsëri me atë lart. Një listë tjetër kontejnerësh është provë më e fortë se çdo skedar konfigurimi, sepse tregon që një daemon tjetër iu përgjigj kërkesës tënde.

Pyet daemon-in nëse shtegu ekziston atje

Pasi të dish cilin daemon ke arritur, bëje të shikojë drejtorinë. --mount forma dështon me një mesazh më të qartë sesa flamuri i shkurtër, sepse vërteton burimin përpara se të nisë kontejnerin:

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

Nëse raporton burimin si që mungon, krijoje në makinën që u përgjigj, ose drejto shërbimin në një vëllim të emërtuar dhe kopjo të dhënat atje. Ajo që nuk duhet të bësh është të rikrijosh vëllime dhe të riinstalosh motorin përpara këtij kontrolli. Ato veprime e ndryshojnë mjedisin mjaftueshëm për ta fshehur mospërputhjen duke e lënë në vend.

Një shteg tjetër kalon diku krejt tjetër: tërheqja e një image është punë e daemon-it, jo e klientit. Një tërheqje e suksesshme vërteton vetëm që daemoni arrin një registry, dhe një bind mount që funksionon vetëm që një shteg u zgjidh. Testo çdo shteg atje ku ekzekutohet vërtet, përndryshe do të kalosh një pasdite me atë të gabuarin.

Emrat e intranetit dështojnë për një arsye tjetër

Gjysma e dytë e të njëjtit raport zakonisht është që kontejneri nuk mund të arrijë intranet.corp.example. Ky është një mekanizëm i veçantë, jo një problem i dytë vëllimi. Një kontejner merr /etc/resolv.conf e tij kur niset, e gjeneruar nga cilësimet e resolver-it të daemon-it, kështu që një server DNS që VPN-i e shtoi pasi kontejneri u krijua nuk do të shfaqet atje derisa kontejneri të rikrijohet.

Resolver-i i integruar i Docker në një rrjet të përcaktuar nga përdoruesi i përcjell kërkesat e jashtme te serverët e konfiguruar të hostit, gjë që ndihmon kur VPN-i rishkruan resolver-in e hostit dhe dëmton kur DNS i ndarë dërgon një zonë të brendshme te një server që daemoni nuk e sheh më. Një hartëzim i ngushtë dhe i qartë shmang debatin për emrat që nuk ndryshojnë kurrë:

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

Kjo shkruan një zë në skedarin hosts të kontejnerit, kështu që kontejneri nuk mëson kurrë asgjë për tunelin, dhe gjithashtu e ngrin adresën. Kur hosti i brendshëm zhvendoset, zëri mbetet i gabuar derisa dikush të redaktojë skedarin Compose. Përdore për një pajisje fikse ose një bazë të dhënash të fiksuar, dhe lëri DNS-ja të merret me emrat që lëvizin.

Çfarë ndryshon në të vërtetë një riinstalim

Riinstalimi i Docker Desktop rikrijon VM-në, socket-in dhe listën e konteksteve, dhe montimi fillon të funksionojë përsëri. Ai rezultat është i vërtetë dhe nuk të mëson asgjë, prandaj i njëjti defekt kthehet pas përditësimit të radhës të VPN-it. Riinstalimi zëvendësoi endpoint-in që klienti përdorte; nuk e pajtoi shtegun që projekti yt emërton me sistemin e skedarëve që daemoni lexon vërtet.

Rendi im i punës është i shkurtër. Konfirmo cilin endpoint do të përdorë klienti. Konfirmo cili daemon u përgjigj duke krahasuar listat e kontejnerëve. Kërko nga ai daemon të listojë shtegun e burimit. Vetëm atëherë redakto montimin, shto një zë hosts ose ndrysho një lloj vëllimi. Nëse mirëmban skedarin Compose për një ekip që punon përmes VPN-it, prefero vëllime të emërtuar për të dhënat që daemoni duhet të zotërojë, që një shteg hosti të mos bëhet kurrë pjesë e kontratës.