Nabibigo ang pag-mount ng volume ng Docker pagkatapos kumonekta ang VPN: suriin ang daemon

Halos lahat ng sulatin tungkol sa problemang ito ay sinisisi ang volume, at iyon mismo ang dahilan kung bakit ang tagal ng pag-aayos. Mayroon kang bind mount na gumagana, kumonekta ang corporate VPN, at docker compose up nabibigo na ngayon dahil sa nawawalang source path, walang laman na direktoryo, o mount na ayaw gawin ng engine. Sa mga environment na nilinis ko, hindi nagbago ang file ng Compose at tama ang landas. Ang nagbago ay kung aling daemon ang tumanggap ng kahilingan, at ang error sa pag-mount ay ang unang lugar lamang kung saan nakita ang pagkakaibang iyon.

Hindi kailanman gumalaw ang volume; ang kahilingan ang gumalaw

Ang -v /srv/app:/app flag ay hindi kopya ng direktoryo na ginagawa ng iyong shell. Ginagawa ito ng kliyente na kahilingan sa API, at ang daemon na sumasagot ang nagre-resolve /srv/app laban sa sarili nitong file system. Kapag parehong tumatakbo sa iisang kernel ang dalawang panig, iyon ang landas na nakikita mo sa file manager. Kapag nagbago ang endpoint, hinahanap ang parehong string sa isang makina na hindi pa nakarinig tungkol sa direktoryo ng iyong proyekto, at ang daemon ay nag-uulat na nawawala ang pinagmulan o tahimik na gumagawa ng walang laman na direktoryo sa lugar nito.

Ito rin ang dahilan kung bakit nagpapatuloy ang isang pinangalanang volume samantalang ang bind mount ay hindi. -v appdata:/app pinangalanan ang storage na pag-aari ng daemon, kaya walang host path ang kailangang umiral sa isang partikular na lugar. Kung ang pagpapalit ng isang serbisyo mula sa bind mount patungo sa pinangalanang volume ay nagpapawala ng error, hindi mo pa naayos ang problema. Napatunayan mo na hindi nagkakasundo ang kliyente at ang daemon kung aling file system ang pag-aari ng landas, at bumabalik ang hindi pagkakasundong iyon sa sandaling kailangan mo muli ng tunay na direktoryo ng host.

I-print ang endpoint bago mo hawakan ang mount

Maraming setting ang maaaring magturo sa kliyente patungo sa isang endpoint, at hindi sila laging nagkakasundo: --context flag, DOCKER_CONTEXT, DOCKER_HOST sa kasalukuyang shell, at ang context na naka-save sa configuration ng kliyente. Sa halip na mag-isip tungkol sa priyoridad, i-print silang lahat at ihambing ang mga sagot.

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

Ang configuration ng kliyente ay nasa ~/.docker/config.json sa Linux at macOS at sa %USERPROFILE%\.docker\config.json sa Windows, at ang value na ini-export sa kasalukuyang terminal ay pumapalit sa naka-save para lamang sa session na iyon. Kung ang endpoint ay hostname sa halip na lokal na socket, ang resolution ng pangalan at mga ruta ang nagpapasya kung saan ito lalapag, at iyon mismo ang muling isinusulat ng kliyente ng VPN. Ang tunnel na nagdaragdag ng ruta o nagpapalit ng resolver ay maaaring magpadala ng pangalang dating tumutukoy sa laptop na ito patungo sa address sa loob ng corporate network.

Ihambing ang estado sa halip na configuration. Patakbuhin ang docker ps -a at docker images habang patay ang tunnel, pagkatapos ay muli habang buhay ito. Ang ibang listahan ng container ay mas matibay na ebidensya kaysa sa anumang configuration file, dahil ipinapakita nitong ibang daemon ang sumagot sa iyong kahilingan.

Tanungin ang daemon kung umiiral ang landas doon

Kapag alam mo kung aling daemon ang naabot mo, ipatingin ito sa direktoryo. --mount nabibigo ang anyo na may mas malinaw na mensahe kaysa sa maikling flag, dahil vine-validate nito ang pinagmulan bago simulan ang container:

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

Kung iniuulat nitong nawawala ang pinagmulan, gawin ito sa makinang sumagot, o ituro ang serbisyo sa isang pinangalanang volume at kopyahin ang data doon. Ang hindi mo dapat gawin ay muling gumawa ng mga volume at muling i-install ang engine bago ang pagsusuring ito. Binabago ng mga aksyong iyon ang environment nang sapat upang itago ang pagkakaiba habang iniwan ito sa lugar.

May isa pang landas na tumatakbo sa ibang lugar: ang paghila ng image ay trabaho ng daemon, hindi ng kliyente. Ang matagumpay na paghila ay nagpapatunay lamang na naaabot ng daemon ang registry, at ang gumaganang bind mount ay nagpapatunay lamang na naresolba ang isang landas. Subukan ang bawat landas kung saan ito talagang tumatakbo, kung hindi ay gugugol ka ng isang hapon sa maling landas.

Nabibigo ang mga pangalan ng intranet sa ibang dahilan

Ang ikalawang kalahati ng parehong ulat ay karaniwang ang container ay hindi maaabot ang intranet.corp.example. Iyon ay hiwalay na mekanismo, hindi pangalawang problema sa volume. Ang container ay nakakakuha ng /etc/resolv.conf nito sa pagsisimula, na nabuo mula sa mga setting ng resolver ng daemon, kaya ang DNS server na idinagdag ng VPN pagkatapos gawin ang container ay hindi lalabas doon hanggang muling gawin ang container.

Ang built-in na resolver ng Docker sa isang network na tinukoy ng gumagamit ay nagpapasa ng panlabas na query sa mga naka-configure na server ng host, na nakakatulong kapag muling isinusulat ng VPN ang resolver ng host at nakakasama kapag nagpapadala ang split DNS ng panloob na zone sa server na hindi na nakikita ng daemon. Ang makitid at tahasang pagma-map ay lumalampas sa pagtatalo para sa mga pangalang hindi kailanman nagbabago:

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

Nagsusulat ito ng entry sa hosts file ng container, kaya wala itong natututuhan tungkol sa tunnel, at pinipigil din nito ang address. Kapag lumipat ang panloob na host, nananatiling mali ang entry hanggang may mag-edit ng file ng Compose. Gamitin ito para sa nakapirming device o naka-pin na database, at hayaang ang DNS ang humawak sa mga pangalang gumagalaw.

Ano ang talagang binabago ng muling pag-install

Ang muling pag-install ng Docker Desktop ay muling gumagawa ng VM, socket, at listahan ng context, at nagsisimulang gumana muli ang mount. Totoo ang resultang iyon at wala itong itinuturo, kaya bumabalik ang parehong sira pagkatapos ng susunod na update ng VPN. Pinalitan ng muling pag-install ang endpoint na ginagamit ng kliyente; hindi nito pinagkasundo ang landas na pinangalanan ng iyong proyekto sa file system na talagang binabasa ng daemon.

Maikli ang aking pagkakasunod-sunod ng trabaho. Tiyakin kung aling endpoint ang gagamitin ng kliyente. Tiyakin kung aling daemon ang sumagot sa pamamagitan ng paghahambing ng mga listahan ng container. Hilingin sa daemon na iyon na ilista ang source path. Pagkatapos lamang ay i-edit ang mount, magdagdag ng entry sa hosts, o magpalit ng uri ng volume. Kung pinapanatili mo ang file ng Compose para sa isang team na nagtatrabaho sa VPN, piliin ang mga pinangalanang volume para sa data na dapat pag-aari ng daemon, upang ang host path ay hindi kailanman maging bahagi ng kontrata.