Docker-voluma muntado malsukcesas post konekto de VPN: kontrolu la demonon

Preskaŭ ĉiu priskribo de ĉi tiu problemo kulpigas la volumon, kaj ĝuste tial la riparo daŭras tiel longe. Vi havis bind-muntadon kiu funkciis, la firmaa VPN konektiĝis, kaj docker compose up nun malsukcesas kun mankanta fonta vojo, malplena dosierujo aŭ muntado kiun la maŝino rifuzas krei. En la medioj kiujn mi purigis, la Compose-dosiero ne ŝanĝiĝis kaj la vojo estis ĝusta. Kio ŝanĝiĝis estis kiun demonon la peto atingis, kaj la muntada eraro estis simple la unua loko kie tiu diferenco fariĝis videbla.

La volumo neniam moviĝis; la peto moviĝis

La -v /srv/app:/app ne estas dosieruja kopio farata de via ŝelo. La kliento igas ĝin API-peto, kaj la demono kiu respondas solvas /srv/app kontraŭ sia propra dosiersistemo. Kiam ambaŭ flankoj rulas sur la sama kerno, tiu vojo estas tiu kiun vi vidas en via dosieradministrilo. Kiam la finpunkto ŝanĝiĝas, la sama signoĉeno estas serĉata sur maŝino kiu neniam aŭdis pri la dosierujo de via projekto, kaj la demono aŭ raportas la fonton mankanta aŭ silente kreas malplenan dosierujon en ĝia loko.

Tial ankaŭ nomita volumo daŭre funkcias dum bind-muntado ne. -v appdata:/app nomas konservejon kiun la demono posedas, do neniu gastiga vojo devas ekzisti ie ajn speciale. Se ŝanĝi unu servon de bind-muntado al nomita volumo igas la eraron malaperi, vi ne riparis la problemon. Vi konfirmis ke la kliento kaj la demono malkonsentas pri tio al kiu dosiersistemo la vojo apartenas, kaj tiu malkonsento revenas en la momento kiam vi denove bezonas veran gastigan dosierujon.

Presu la finpunkton antaŭ ol tuŝi la muntadon

Pluraj agordoj povas direkti la klienton al finpunkto, kaj ili ne ĉiam konsentas: la flago --context , DOCKER_CONTEXT, DOCKER_HOST en la nuna ŝelo, kaj la kunteksto konservita en la klienta agordo. Anstataŭ pripensi prioritaton, presu ĉiujn kaj komparu la respondojn.

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

La klienta agordo troviĝas en ~/.docker/config.json sur Linux kaj macOS kaj en %USERPROFILE%\.docker\config.json sur Windows, kaj valoro eksportita en la nuna terminalo anstataŭigas la konservitan nur por tiu seanco. Se la finpunkto estas gastignomo anstataŭ loka soklo, nomrezolucio kaj itineroj decidas kie ĝi surteriĝos, kaj ĝuste tion reskribas VPN-kliento. Tunelo kiu aldonas itineron aŭ ŝanĝas la solvilon povas sendi nomon kiu antaŭe signifis ĉi tiun tekkomputilon al adreso ene de la firmaa reto.

Komparu staton anstataŭ agordon. Rulu docker ps -a kaj docker images kun la tunelo malsupre, poste denove kun ĝi supre. Malsama listo de ujoj estas pli forta pruvo ol iu ajn agorda dosiero, ĉar ĝi montras ke alia demono respondis vian peton.

Demandu la demonon ĉu la vojo ekzistas tie

Kiam vi scias kiun demonon vi atingis, igi lin rigardi la dosierujon. La formo --mount malsukcesas kun pli klara mesaĝo ol la mallonga flago, ĉar ĝi validigas la fonton antaŭ ol starti la ujon:

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

Se ĝi raportas la fonton mankanta, kreu ĝin sur la maŝino kiu respondis, aŭ direktu la servon al nomita volumo kaj kopiu la datumojn enen. Kion vi ne faru estas rekrei volumojn kaj reinstali la maŝinon antaŭ ĉi tiu kontrolo. Tiuj agoj ŝanĝas la medion sufiĉe por kaŝi la malkongruon dum ili lasas ĝin surloke.

Ankoraŭ unu vojo iras tute aliloke: eltiri bildon estas laboro de la demono, ne de la kliento. Sukcesa eltiro pruvas nur ke la demono povas atingi registry, kaj funkcianta bind-muntado nur ke vojo estis solvita. Testu ĉiun vojon tie kie ĝi efektive plenumiĝas, alie vi pasigos posttagmezon ĉe la malĝusta.

Intranetaj nomoj malsukcesas pro alia kialo

La dua duono de la sama raporto kutime estas ke la ujo ne povas atingi intranet.corp.example. Tio estas aparta mekanismo, ne dua voluma problemo. Ujo ricevas sian /etc/resolv.conf kiam ĝi startas, generitan el la solvilaj agordoj de la demono, do DNS-servilo kiun la VPN aldonis post kiam la ujo estis kreita ne aperos tie ĝis la ujo estos rekrea.

La enkonstruita solvilo de Docker sur uzanto-difinita reto plusendas eksterajn serĉojn al la agorditaj serviloj de la gastiganto, kio helpas kiam la VPN reskribas la gastigan solvilon kaj malhelpas kiam split DNS sendas internan zonon al servilo kiun la demono ne plu vidas. Mallarĝa, eksplicita mapado evitas la disputon por nomoj kiuj neniam ŝanĝiĝas:

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

Ĉi tio skribas eron en la hosts-dosieron de la ujo, do la ujo neniam lernas ion pri la tunelo, kaj ĝi ankaŭ frostigas la adreson. Kiam la interna gastiganto translokiĝas, la ero restas malĝusta ĝis iu redaktas la Compose-dosieron. Uzu ĝin por fiksa aparato aŭ fiksita datumbazo, kaj lasu DNS prizorgi nomojn kiuj moviĝas.

Kion reinstalo efektive ŝanĝas

Reinstalo de Docker Desktop rekreas la VM, la soklon kaj la kuntekstan liston, kaj la muntado denove funkcias. Tiu rezulto estas reala kaj ĝi instruas nenion, tial la sama fiasko revenas post la sekva VPN-ĝisdatigo. La reinstalo anstataŭigis la finpunkton kiun la kliento uzis; ĝi ne akordigis la vojon kiun via projekto nomas kun la dosiersistemo kiun la demono efektive legas.

Mia laborordo estas mallonga. Konfirmu kiun finpunkton la kliento uzos. Konfirmu kiun demonon respondis komparante ujajn listojn. Petu tiun demonon listigi la fontan vojon. Nur tiam redaktu la muntadon, aldonu hosts-ereton aŭ ŝanĝu volumtipon. Se vi prizorgas la Compose-dosieron por teamo kiu laboras tra VPN, preferu nomitajn volumojn por datumoj kiujn la demono devus posedi, por ke gastiga vojo neniam fariĝu parto de la kontrakto.