VPN കണക്ട് ചെയ്തതിന് ശേഷം Docker വോള്യം മൗണ്ട് പരാജയപ്പെടുന്നു: daemon പരിശോധിക്കുക

ഈ പ്രശ്നത്തെക്കുറിച്ചുള്ള ഏതാണ്ട് എല്ലാ കുറിപ്പുകളും വോള്യത്തെ കുറ്റപ്പെടുത്തുന്നു, അതുകൊണ്ടാണ് പരിഹാരം ഇത്രയധികം സമയമെടുക്കുന്നത്. നിങ്ങൾക്ക് പ്രവർത്തിച്ചിരുന്ന ഒരു bind mount ഉണ്ടായിരുന്നു, കോർപ്പറേറ്റ് VPN കണക്ട് ചെയ്തു, എന്നിട്ട് docker compose up ഇപ്പോൾ കാണാത്ത source path, ശൂന്യമായ ഡയറക്ടറി, അല്ലെങ്കിൽ എൻജിൻ നിർമ്മിക്കാൻ വിസമ്മതിക്കുന്ന mount എന്നിവയോടെ പരാജയപ്പെടുന്നു. ഞാൻ വൃത്തിയാക്കിയ പരിസ്ഥിതികളിൽ Compose ഫയൽ മാറിയിരുന്നില്ല, പാത ശരിയായിരുന്നു. മാറിയത് ഏത് daemon ആണ് അഭ്യർത്ഥന സ്വീകരിച്ചത് എന്നതാണ്, mount പിശക് ആ വ്യത്യാസം ആദ്യം ദൃശ്യമായ സ്ഥലം മാത്രമായിരുന്നു.

വോള്യം ഒരിക്കലും നീങ്ങിയില്ല; അഭ്യർത്ഥന നീങ്ങി

ഒരു -v /srv/app:/app ഫ്ലാഗ് നിങ്ങളുടെ shell നടത്തുന്ന ഡയറക്ടറി പകർപ്പല്ല. ക്ലൈന്റ് അതിനെ API അഭ്യർത്ഥനയാക്കി മാറ്റുന്നു, പ്രതികരിക്കുന്ന daemon /srv/app അതിനെ സ്വന്തം ഫയൽസിസ്റ്റത്തിനെതിരെ പരിഹരിക്കുന്നു. ഇരുവശവും ഒരേ കേർണലിൽ പ്രവർത്തിക്കുമ്പോൾ, ആ പാതയാണ് ഫയൽ മാനേജറിൽ നിങ്ങൾ കാണുന്നത്. endpoint മാറുമ്പോൾ, അതേ സ്ട്രിംഗ് നിങ്ങളുടെ പ്രോജക്ട് ഡയറക്ടറിയെക്കുറിച്ച് ഒരിക്കലും കേട്ടിട്ടില്ലാത്ത ഒരു മെഷീനിൽ തിരയുന്നു, daemon ഉറവിടം കാണുന്നില്ലെന്ന് റിപ്പോർട്ട് ചെയ്യുകയോ അല്ലെങ്കിൽ അതിന്റെ സ്ഥാനത്ത് നിശബ്ദമായി ശൂന്യമായ ഡയറക്ടറി സൃഷ്ടിക്കുകയോ ചെയ്യുന്നു.

പേരുള്ള വോള്യം പ്രവർത്തിക്കുന്നതും bind mount പ്രവർത്തിക്കാത്തതും ഇതേ കാരണത്താലാണ്. -v appdata:/app daemon സ്വന്തമാക്കുന്ന സംഭരണത്തിന് പേര് നൽകുന്നു, അതിനാൽ ഏതെങ്കിലും host path ഒരു പ്രത്യേക സ്ഥലത്ത് ഉണ്ടായിരിക്കേണ്ടതില്ല. ഒരു സേവനത്തെ bind mount-ൽ നിന്ന് പേരുള്ള വോള്യത്തിലേക്ക് മാറ്റുന്നത് പിശക് അപ്രത്യക്ഷമാക്കുന്നുവെങ്കിൽ, നിങ്ങൾ പ്രശ്നം പരിഹരിച്ചിട്ടില്ല. പാത ഏത് ഫയൽസിസ്റ്റത്തിന് അവകാശപ്പെട്ടതാണ് എന്നതിൽ ക്ലൈന്റും daemon-ഉം യോജിക്കുന്നില്ലെന്ന് നിങ്ങൾ സ്ഥിരീകരിച്ചു, ആ വിയോജിപ്പ് വീണ്ടും ഒരു യഥാർത്ഥ host ഡയറക്ടറി ആവശ്യമാകുന്ന നിമിഷം തിരികെ വരുന്നു.

മൗണ്ട് സ്പർശിക്കുന്നതിന് മുൻപ് endpoint അച്ചടിക്കുക

നിരവധി ക്രമീകരണങ്ങൾക്ക് ക്ലൈന്റിനെ ഒരു endpoint-ലേക്ക് ചൂണ്ടാൻ കഴിയും, അവ എപ്പോഴും യോജിക്കുന്നില്ല: --context ഫ്ലാഗ്, DOCKER_CONTEXT, DOCKER_HOST നിലവിലെ shell-ൽ, കൂടാതെ ക്ലൈന്റ് കോൺഫിഗറേഷനിൽ സംരക്ഷിച്ച context. മുൻഗണനയെക്കുറിച്ച് ചിന്തിക്കുന്നതിന് പകരം എല്ലാം അച്ചടിച്ച് ഉത്തരങ്ങൾ താരതമ്യം ചെയ്യുക.

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

ക്ലൈന്റ് കോൺഫിഗ് ഇതിലാണ്: ~/.docker/config.json Linux, macOS എന്നിവയിൽ, ഇതിലും: %USERPROFILE%\.docker\config.json Windows-ൽ, കൂടാതെ നിലവിലെ ടെർമിനലിൽ export ചെയ്ത മൂല്യം സംരക്ഷിച്ചതിനെ ആ സെഷനിൽ മാത്രം അസാധുവാക്കുന്നു. endpoint ഒരു ലോക്കൽ socket-ന് പകരം hostname ആണെങ്കിൽ, നാമപരിഹാരവും റൂട്ടുകളും അത് എവിടെ ഇറങ്ങുമെന്ന് തീരുമാനിക്കുന്നു, VPN ക്ലൈന്റ് പുനരെഴുതുന്നത് അതേ കാര്യങ്ങളാണ്. ഒരു റൂട്ട് ചേർക്കുന്നതോ resolver മാറ്റുന്നതോ ആയ tunnel, മുൻപ് ഈ ലാപ്ടോപ്പിനെ അർത്ഥമാക്കിയിരുന്ന ഒരു പേര് കോർപ്പറേറ്റ് നെറ്റ്വർക്കിനുള്ളിലെ വിലാസത്തിലേക്ക് അയച്ചേക്കാം.

കോൺഫിഗറേഷനല്ല, അവസ്ഥ താരതമ്യം ചെയ്യുക. tunnel അടച്ചിരിക്കുമ്പോൾ docker ps -a ഉം docker images ഉം പ്രവർത്തിപ്പിക്കുക, പിന്നീട് tunnel തുറന്നിരിക്കുമ്പോൾ വീണ്ടും. വ്യത്യസ്ത കണ്ടെയ്നർ പട്ടിക ഏതൊരു കോൺഫിഗ് ഫയലിനെക്കാളും ശക്തമായ തെളിവാണ്, കാരണം നിങ്ങളുടെ അഭ്യർത്ഥനയോട് മറ്റൊരു daemon പ്രതികരിച്ചു എന്ന് അത് കാണിക്കുന്നു.

പാത അവിടെ ഉണ്ടോ എന്ന് daemon-നോട് ചോദിക്കുക

ഏത് daemon-ലേക്ക് എത്തി എന്ന് അറിഞ്ഞാൽ, അതിനെ ഡയറക്ടറി നോക്കാൻ അനുവദിക്കുക. --mount രൂപം ചെറിയ ഫ്ലാഗിനെക്കാളും വ്യക്തമായ സന്ദേശത്തോടെ പരാജയപ്പെടുന്നു, കാരണം കണ്ടെയ്നർ ആരംഭിക്കുന്നതിന് മുൻപ് ഉറവിടം സാധൂകരിക്കുന്നു:

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

ഉറവിടം കാണുന്നില്ലെന്ന് റിപ്പോർട്ട് ചെയ്താൽ, പ്രതികരിച്ച മെഷീനിൽ അത് സൃഷ്ടിക്കുക, അല്ലെങ്കിൽ സേവനത്തെ പേരുള്ള വോള്യത്തിലേക്ക് ചൂണ്ടി ഡാറ്റ അവിടേക്ക് പകർത്തുക. ഈ പരിശോധനയ്ക്ക് മുൻപ് വോള്യങ്ങൾ പുനഃസൃഷ്ടിക്കുന്നതും എൻജിൻ വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്യുന്നതും നിങ്ങൾ ചെയ്യരുത്. ആ പ്രവർത്തനങ്ങൾ പൊരുത്തക്കേട് മറയ്ക്കാൻ മതിയാകും വിധം പരിസ്ഥിതി മാറ്റുന്നു, പക്ഷേ അത് അതിന്റെ സ്ഥാനത്ത് തന്നെ നിലനിർത്തുന്നു.

ഇനിയൊരു പാത തികച്ചും വേറൊരിടത്ത് പ്രവർത്തിക്കുന്നു: image വലിക്കുന്നത് daemon-ന്റെ ജോലിയാണ്, ക്ലൈന്റിന്റേതല്ല. വിജയകരമായ വലിക്കൽ daemon-ന് registry-യിൽ എത്താമെന്ന് മാത്രം തെളിയിക്കുന്നു, പ്രവർത്തിക്കുന്ന bind mount പാത പരിഹരിക്കപ്പെട്ടു എന്ന് മാത്രം. ഓരോ പാതയും അത് യഥാർത്ഥത്തിൽ പ്രവർത്തിക്കുന്നിടത്ത് പരിശോധിക്കുക, അല്ലെങ്കിൽ തെറ്റായ ഒന്നിന് ഒരു ഉച്ചയ്ക്ക് ശേഷം ചെലവിടും.

ഇൻട്രാനെറ്റ് പേരുകൾ മറ്റൊരു കാരണത്താൽ പരാജയപ്പെടുന്നു

അതേ റിപ്പോർട്ടിന്റെ രണ്ടാം പകുതി സാധാരണയായി കണ്ടെയ്നറിന് intranet.corp.exampleഎത്താൻ കഴിയില്ല എന്നതാണ്. അത് വേറിട്ടൊരു സംവിധാനമാണ്, രണ്ടാമത്തെ വോള്യം പ്രശ്നമല്ല. കണ്ടെയ്നറിന് അതിന്റെ /etc/resolv.conf ആരംഭിക്കുമ്പോൾ ലഭിക്കുന്നു, daemon resolver ക്രമീകരണങ്ങളിൽ നിന്ന് സൃഷ്ടിക്കപ്പെടുന്നത്, അതിനാൽ കണ്ടെയ്നർ സൃഷ്ടിച്ചതിന് ശേഷം VPN ചേർത്ത DNS സെർവർ കണ്ടെയ്നർ വീണ്ടും സൃഷ്ടിക്കുന്നത് വരെ അവിടെ ദൃശ്യമാകില്ല.

ഉപയോക്താവ് നിർവചിച്ച നെറ്റ്വർക്കിലെ Docker-ന്റെ ഉൾച്ചേർത്ത resolver ബാഹ്യ അന്വേഷണങ്ങൾ host-ൽ കോൺഫിഗർ ചെയ്ത സെർവറുകളിലേക്ക് കൈമാറുന്നു, ഇത് VPN host resolver പുനരെഴുതുമ്പോൾ സഹായിക്കുന്നു, വിഭജിത DNS ഒരു ആന്തരിക മേഖല daemon ഇനി കാണാത്ത സെർവറിലേക്ക് അയക്കുമ്പോൾ ദോഷം ചെയ്യുന്നു. ഒരിക്കലും മാറാത്ത പേരുകൾക്കായുള്ള ഈ വാദം ഒരു ഇടുങ്ങിയ, വ്യക്തമായ മാപ്പിംഗ് ഒഴിവാക്കുന്നു:

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

ഇത് കണ്ടെയ്നറിന്റെ hosts ഫയലിൽ ഒരു എൻട്രി എഴുതുന്നു, അതിനാൽ കണ്ടെയ്നർ tunnel-നെക്കുറിച്ച് ഒന്നും പഠിക്കുന്നില്ല, കൂടാതെ വിലാസവും സ്ഥിരീകരിക്കുന്നു. ആന്തരിക host നീങ്ങുമ്പോൾ, ആരെങ്കിലും Compose ഫയൽ എഡിറ്റ് ചെയ്യുന്നത് വരെ എൻട്രി തെറ്റായി തുടരും. സ്ഥിരമായ ഉപകരണത്തിനോ പിൻ ചെയ്ത ഡാറ്റാബേസിനോ ഇത് ഉപയോഗിക്കുക, നീങ്ങുന്ന പേരുകൾ DNS-ന് വിടുക.

വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്യുന്നത് യഥാർത്ഥത്തിൽ എന്ത് മാറ്റുന്നു

Docker Desktop വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്യുന്നത് VM, socket, context പട്ടിക എന്നിവ പുനഃസൃഷ്ടിക്കുന്നു, മൗണ്ട് വീണ്ടും പ്രവർത്തിക്കാൻ തുടങ്ങുന്നു. ആ ഫലം യഥാർത്ഥമാണ്, അത് ഒന്നും പഠിപ്പിക്കുന്നുമില്ല, അതുകൊണ്ടാണ് അടുത്ത VPN അപ്ഡേറ്റിന് ശേഷം അതേ തകരാർ തിരികെ വരുന്നത്. വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്യൽ ക്ലൈന്റ് ഉപയോഗിച്ചിരുന്ന endpoint മാറ്റിസ്ഥാപിച്ചു; അത് നിങ്ങളുടെ പ്രോജക്ട് പേരിടുന്ന പാതയെ daemon യഥാർത്ഥത്തിൽ വായിക്കുന്ന ഫയൽസിസ്റ്റവുമായി യോജിപ്പിച്ചില്ല.

എന്റെ പ്രവർത്തനക്രമം ചെറുതാണ്. ക്ലൈന്റ് ഏത് endpoint ഉപയോഗിക്കുമെന്ന് സ്ഥിരീകരിക്കുക. കണ്ടെയ്നർ പട്ടികകൾ താരതമ്യം ചെയ്ത് ഏത് daemon പ്രതികരിച്ചു എന്ന് സ്ഥിരീകരിക്കുക. ആ daemon-നോട് source path ലിസ്റ്റ് ചെയ്യാൻ ആവശ്യപ്പെടുക. അതിന് ശേഷം മാത്രം മൗണ്ട് എഡിറ്റ് ചെയ്യുക, hosts എൻട്രി ചേർക്കുക, അല്ലെങ്കിൽ വോള്യം തരം മാറ്റുക. VPN-ൽ പ്രവർത്തിക്കുന്ന ഒരു ടീമിനായി Compose ഫയൽ പരിപാലിക്കുന്നുണ്ടെങ്കിൽ, daemon സ്വന്തമാക്കേണ്ട ഡാറ്റയ്ക്ക് പേരുള്ള വോള്യങ്ങൾക്ക് മുൻഗണന നൽകുക, അങ്ങനെ host path ഒരിക്കലും കരാറിന്റെ ഭാഗമാകാതിരിക്കും.