Uppsetning Docker-bindis mistekst eftir VPN-tengingu: athugaðu daemoninn

Næstum hver lýsing á þessu vandamáli kennir bindinu um, og það er einmitt ástæðan fyrir því að viðgerðin tekur svo langan tíma. Þú varst með bind mount sem virkaði, fyrirtækis-VPN-ið tengdist, og docker compose up mistekst núna með slóð sem vantar, tóma möppu eða uppsetningu sem vélin neitar að búa til. Í umhverfum sem ég hef þrífið var Compose-skráin óbreytt og slóðin rétt. Það sem breyttist var hvaða daemon fékk beiðnina, og uppsetningarvillan var bara fyrsti staðurinn þar sem þessi munur varð sýnilegur.

Bindið hreyfðist aldrei; beiðnin hreyfðist

Fáninn -v /srv/app:/app er ekki afrit af möppu sem skeljin þín gerir. Biðlarinn breytir honum í API-beiðni, og daemoninn sem svarar leysir /srv/app gagnvart eigin skráarkerfi. Þegar báðar hliðar keyra á sama kjarna er þessi slóð sú sem þú sérð í skráastjóranum. Þegar endpointið breytist er sama strengurinn leitaður á vél sem hefur aldrei heyrt um verkefnamöppuna þína, og daemoninn tilkynnir annaðhvort að uppruninn vanti eða býr hljóðlega til tóma möppu í hans stað.

Þess vegna heldur nefnt bindi áfram að virka á meðan bind mount gerir það ekki. -v appdata:/app nefnir geymslu sem daemoninn á, svo engin hýsilslóð þarf að vera til á tilteknum stað. Ef að skipta einni þjónustu úr bind mounti yfir í nefnt bindi lætur villuna hverfa hefurðu ekki lagað vandamálið. Þú hefur staðfest að biðlarinn og daemoninn eru ósammála um hvaða skráarkerfi slóðin tilheyrir, og sá ágreiningur kemur aftur um leið og þú þarft aftur raunverulega hýsilsmöppu.

Prentaðu endpointið áður en þú snertir uppsetninguna

Nokkrar stillingar geta beint biðlaranum að endpointi, og þær eru ekki alltaf sammála: fáninn --context , DOCKER_CONTEXT, DOCKER_HOST í núverandi skel, og samhengið sem vistað er í stillingum biðlarans. Í stað þess að velta fyrir sér forgangi skaltu prenta þær allar og bera saman svörin.

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

Stillingar biðlarans eru í ~/.docker/config.json á Linux og macOS og í %USERPROFILE%\.docker\config.json á Windows, og gildi sem er flutt út í núverandi skjáhermi yfirskrifar það vistaða aðeins fyrir þá lotu. Ef endpointið er hýsilnafn í stað staðbundins socket mun nafnaleysing og leiðir ráða því hvar það lendir, og það er einmitt það sem VPN-biðlari endurskrifar. Göng sem bæta við leið eða skipta um leysi geta sent nafn sem áður þýddi þessa fartölvu á vistfang innan fyrirtækjanetsins.

Berðu saman ástand í stað stillinga. Keyrðu docker ps -a og docker images með göngin niðri, og svo aftur með þau uppi. Önnur listi yfir gáma er sterkari sönnun en hvaða stillingarskrá sem er, því hann sýnir að annar daemon svaraði beiðninni þinni.

Spyrðu daemoninn hvort slóðin sé þar

Þegar þú veist hvaða daemon þú náðir til skaltu láta hann líta á möppuna. Formið --mount mistekst með skýrari skilaboðum en stutti fáninn, því það staðfestir upprunann áður en gáma er ræstur:

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

Ef það tilkynnir að uppruninn vanti skaltu búa hann til á vélinni sem svaraði, eða beina þjónustunni að nefndu bindi og afrita gögnin þangað. Það sem þú ættir ekki að gera er að endurskapa bindi og enduruppsetja vélina fyrir þessa athugun. Þessar aðgerðir breyta umhverfinu nóg til að fela misræmið á meðan það er látið vera.

Ein slóð til fer alveg annars staðar: að sækja image er vinna daemonsins, ekki biðlarans. Árangursrík sæking sannar aðeins að daemoninn nái registry, og virkt bind mount aðeins að slóð hafi verið leyst. Prófaðu hverja slóð þar sem hún er í raun keyrð, annars eyðirðu síðdegi í þeirri röngu.

Intranet-nöfn mistekst af annarri ástæðu

Seinni helmingur sömu skýrslu er venjulega að gámurinn nái ekki intranet.corp.example. Það er sérstakt fyrirbæri, ekki annað bindisvandamál. Gámur fær /etc/resolv.conf sinn við ræsingu, búið til úr leysistillingum daemonsins, svo DNS-þjónn sem VPN bætti við eftir að gámurinn var búinn til birtist ekki þar fyrr en gámurinn er endurskapaður.

Innbyggði leysir Docker á neti sem notandi skilgreinir sendir utanaðkomandi fyrirspurnir til stilltu þjónanna á hýsilnum, sem hjálpar þegar VPN endurskrifar leysi hýsilsins og skaðar þegar skipt DNS sendir innra svæði til þjóns sem daemoninn sér ekki lengur. Þröng, skýr vörpun kemst hjá deilunni um nöfn sem breytast aldrei:

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

Þetta skrifar færslu í hosts-skrá gámsins, svo gámurinn lærir ekkert um göngin, og það frystir líka vistfangið. Þegar innri hýsillinn flyst verður færslan röng þar til einhver breytir Compose-skránni. Notaðu það fyrir fastan búnað eða festan gagnagrunn, og láttu DNS sjá um nöfn sem hreyfast.

Hvað enduruppsetning breytir í raun

Enduruppsetning Docker Desktop endurskapar VM-ið, socketið og samhengislistann, og uppsetningin byrjar að virka aftur. Sú niðurstaða er raunveruleg og kennir ekkert, og þess vegna kemur sama bilunin aftur eftir næstu VPN-uppfærslu. Enduruppsetningin skipti um endpointið sem biðlarinn notaði; hún samræmdi ekki slóðina sem verkefnið þitt nefnir við skráarkerfið sem daemoninn les í raun.

Vinnuferill minn er stuttur. Staðfestu hvaða endpoint biðlarinn muni nota. Staðfestu hvaða daemon svaraði með því að bera saman gámalista. Biddu þann daemon að telja upp upprunaslóðina. Aðeins þá breytirðu uppsetningunni, bætir við hosts-færslu eða skiptir um bindistegund. Ef þú heldur við Compose-skránni fyrir teymi sem vinnur yfir VPN skaltu velja nefnd bindi fyrir gögn sem daemoninn á að eiga, svo hýsilslóð verði aldrei hluti samningsins.