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 ਕਦੇ ਸਮਝੌਤੇ ਦਾ ਹਿੱਸਾ ਨਾ ਬਣੇ।