VPN ਰਾਹੀਂ docker pull: ਡੈਮਨ ਦਾ ਆਪਣਾ ਨੈੱਟਵਰਕ ਹੈ

ਤੁਹਾਡਾ ਲੈਪਟਾਪ ਕਾਰਪੋਰੇਟ VPN ਉੱਤੇ ਹੈ, curl ਅੰਦਰੂਨੀ ਰਜਿਸਟਰੀ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਵੀ docker pull EOF ਨਾਲ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ। ਇਹ ਸੁਮੇਲ ਵਿਰੋਧਾਭਾਸ ਨਹੀਂ। ਤੁਸੀਂ ਲਿਖਿਆ ਹੁਕਮ ਤੁਹਾਡੇ ਸ਼ੈਲ ਵਿੱਚ ਚੱਲਦਾ ਹੈ, ਪਰ ਤਬਦੀਲੀ ਉਸ ਡੈਮਨ ਦੇ ਅੰਦਰ ਚੱਲਦੀ ਹੈ ਜੋ Docker CLI ਨੇ ਚੁਣਿਆ ਹੈ, ਅਤੇ ਉਹ ਡੈਮਨ ਬਿਲਕੁਲ ਹੋਰ ਹੋਸਟ ਉੱਤੇ ਹੋ ਸਕਦਾ ਹੈ। ਉਸੇ ਦਾ ਨੈੱਟਵਰਕ ਮਾਰਗ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਉਸੇ ਦੀਆਂ ਪ੍ਰਾਕਸੀ ਸੈਟਿੰਗਾਂ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ।

ਮਾਰਗ ਨਹੀਂ, ਇੰਜਣ ਦੀ ਪਛਾਣ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ

docker context show ਅਤੇ docker version ਚਲਾਓ। ਵਰਜਨ ਦਾ ਆਉਟਪੁੱਟ ਇੱਕ ਕਲਾਇੰਟ ਭਾਗ ਅਤੇ ਇੱਕ ਸਰਵਰ ਭਾਗ ਛਾਪਦਾ ਹੈ, ਅਤੇ ਸਰਵਰ ਬਲਾਕ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਸਨੇ ਜਵਾਬ ਦਿੱਤਾ: ਸਥਾਨਕ ਨੇਟਿਵ ਇੰਜਣ, Docker Desktop ਵਰਚੁਅਲ ਮਸ਼ੀਨ, ਜਾਂ ਦੂਰ ਦੀ ਮਸ਼ੀਨ ਉੱਤੇ ਡੈਮਨ। ਪੱਕਾ ਹੋਣਾ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ docker context inspect ਚੁਣੇ ਹੋਏ ਸੰਦਰਭ ਦਾ ਅੰਤ ਬਿੰਦੂ ਦਿਖਾਏਗਾ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਹੁਕਮ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ।

DOCKER_HOST ਵਰਗਾ ਵਾਤਾਵਰਨ ਚਰ CLI ਨੂੰ ਤੁਹਾਡੇ ਅਨੁਮਾਨ ਤੋਂ ਵੱਖਰੇ ਇੰਜਣ ਵੱਲ ਚੁੱਪਚਾਪ ਨਿਰਦੇਸ਼ਿਤ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਲੈਪਟਾਪ VPN ਉੱਤੇ ਦਿਖਣ ਦੇ ਬਾਵਜੂਦ ਪੁੱਲ ਕਿਤੇ ਹੋਰ ਜਾਣ ਦੀ ਇਹੀ ਆਮ ਵਿਆਖਿਆ ਹੈ।

ਡੈਮਨ ਦੀ ਆਪਣੀ ਨੈੱਟਵਰਕ ਪਛਾਣ ਹੈ

ਦੂਰ ਦੇ ਇੰਜਣ ਨੂੰ ਨਿੱਜੀ ਰਜਿਸਟਰੀ ਤੱਕ ਆਪਣਾ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਮਾਰਗ ਚਾਹੀਦਾ ਹੈ। ਤੁਹਾਡੇ ਲੈਪਟਾਪ ਦਾ VPN ਕਲਾਇੰਟ ਜੋੜਨ ਨਾਲ ਉਸ ਲੈਪਟਾਪ ਨੂੰ ਮਾਰਗ ਮਿਲਦਾ ਹੈ; ਇਸ ਨਾਲ ਪ੍ਰਯੋਗਸ਼ਾਲਾ ਜਾਂ ਕਲਾਉਡ ਸਬਨੈੱਟ ਵਿੱਚ ਬੈਠੇ ਡੈਮਨ ਨੂੰ ਉਹੀ ਨਿੱਜੀ ਪਤਾ ਨਹੀਂ ਮਿਲਦਾ। ਜੇ ਇੰਜਣ Docker Desktop ਹੈ, ਪੁੱਲ ਉਸਦੀ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਦੇ ਅੰਦਰ ਹੁੰਦਾ ਹੈ, ਜਿਸਦੀ ਤੁਹਾਡੇ ਸ਼ੈਲ ਦੇ ਵਾਤਾਵਰਨ ਤੋਂ ਵੱਖਰੀ ਆਪਣੀ ਨੈੱਟਵਰਕਿੰਗ ਅਤੇ ਪ੍ਰਾਕਸੀ ਸੰਰਚਨਾ ਹੈ।

ਇਸੇ ਲਈ ਹੋਸਟ ਉੱਤੇ ਸਫਲ curl ਹੋਸਟ ਬਾਰੇ ਸਬੂਤ ਹੈ ਅਤੇ ਹੋਰ ਕੁਝ ਨਹੀਂ।

ਪਤਾ ਲਗਾਓ ਕਿ ਰਜਿਸਟਰੀ ਨਾਲ ਕਿਹੜਾ ਵਟਾਂਦਰਾ ਖਤਮ ਹੋਇਆ

ਇਮੇਜ ਪੁੱਲ ਇੱਕ ਕ੍ਰਮ ਹੈ: ਪ੍ਰਮਾਣਿਕਤਾ, ਮੈਨੀਫੈਸਟ ਪ੍ਰਾਪਤ ਕਰਨਾ, ਅਤੇ ਫਿਰ blob ਤਬਦੀਲੀਆਂ ਜੋ ਅਕਸਰ ਆਬਜੈਕਟ ਸਟੋਰੇਜ ਜਾਂ CDN ਅੰਤ ਬਿੰਦੂ ਵੱਲ ਰੀਡਾਇਰੈਕਟ ਹੁੰਦੀਆਂ ਹਨ। ਸਫਲ docker login ਸਿਰਫ ਪਹਿਲਾ ਕਦਮ ਸਾਬਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਟੋਕਨ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੈਧ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਰੀਡਾਇਰੈਕਟ ਹੋਇਆ blob ਹੋਸਟ ਡੈਮਨ ਦੇ ਨੈੱਟਵਰਕ ਤੋਂ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਹੋਵੇ। ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਸਹੀ ਸਮਾਂ, ਇਮੇਜ ਸੰਦਰਭ ਅਤੇ ਡੈਮਨ ਜਾਂ ਕਲਾਇੰਟ ਲਾਗ ਦੀ ਪਹਿਲੀ ਲਾਹੇਵੰਦ ਘਟਨਾ ਨੋਟ ਕਰੋ।

EOF ਇਕੱਲਾ ਕੋਈ ਕਾਰਨ ਨਹੀਂ ਦੱਸਦਾ। ਇਹ ਕਟਿਆ ਹੋਇਆ ਕਨੈਕਸ਼ਨ, ਸਟਰੀਮ ਛੱਡ ਦੇਣ ਵਾਲੀ ਪ੍ਰਾਕਸੀ, ਸਮਾਂ ਸਮਾਪਤੀ ਜਾਂ MTU ਸਮੱਸਿਆ ਹੋ ਸਕਦੀ ਹੈ, ਅਤੇ ਸਮਾਂ-ਚਿੰਨ੍ਹਿਤ ਘਟਨਾ ਤੋਂ ਬਿਨਾਂ ਇਹਨਾਂ ਵਿਚਕਾਰ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣਾ ਹੀ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਲੋਕ ਸਿਹਤਮੰਦ ਇੰਜਣ ਦੁਬਾਰਾ ਬਣਾਉਂਦੇ ਹਨ। ਕਲਾਇੰਟ ਆਉਟਪੁੱਟ ਵਿੱਚ ਬਾਈਟ ਆਫਸੈੱਟ ਨੂੰ ਡੇਟਾ ਮੰਨੋ, ਕਿਉਂਕਿ ਹਰ ਵਾਰ ਇੱਕੋ ਆਕਾਰ ਉੱਤੇ ਰੁਕਣ ਵਾਲੀ ਤਬਦੀਲੀ ਕਦੇ ਸ਼ੁਰੂ ਨਾ ਹੋਣ ਵਾਲੀ ਤੋਂ ਬਿਲਕੁਲ ਵੱਖਰੀ ਚੀਜ਼ ਹੈ। ਦੋਵੇਂ ਨਤੀਜੇ ਨੋਟ ਕਰੋ ਅਤੇ ਕੋਸ਼ਿਸ਼ਾਂ ਵਿਚਕਾਰ ਉਹਨਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ।

ਜੋ ਹਿੱਸਾ ਤਬਦੀਲੀ ਕਰਦਾ ਹੈ ਉਸਨੂੰ ਸੰਰਚਿਤ ਕਰੋ

ਨੇਟਿਵ Linux ਇੰਜਣ ਲਈ ਪ੍ਰਾਕਸੀ ਸੇਵਾ ਵਾਤਾਵਰਨ ਵਿੱਚ ਹੁੰਦੀ ਹੈ, ਤੁਹਾਡੇ ਸ਼ੈਲ ਵਿੱਚ ਨਹੀਂ। /etc/systemd/system/docker.service.d/ ਦੇ ਹੇਠਾਂ HTTP_PROXY, HTTPS_PROXY ਅਤੇ NO_PROXY ਐਂਟਰੀਆਂ ਵਾਲੀ drop-in ਫਾਈਲ, ਫਿਰ systemctl daemon-reload ਅਤੇ ਰੀਸਟਾਰਟ, ਇਹੀ ਦਸਤਾਵੇਜ਼ੀ ਵਿਵਸਥਾ ਹੈ। Docker Desktop ਉਹੀ ਮੁੱਲ ਆਪਣੀਆਂ ਸੈਟਿੰਗਾਂ ਰਾਹੀਂ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਸ਼ੈਲ ਪ੍ਰੋਫਾਈਲ ਸੋਧਣ ਨਾਲ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਹੁੰਦਾ।

ਜੇ ਰਜਿਸਟਰੀ ਤੱਕ ਸਿੱਧਾ VPN ਰਾਹੀਂ ਪਹੁੰਚਣਾ ਹੈ, ਤਾਂ ਡੈਮਨ ਨੂੰ ਰਿਜ਼ੋਲਵਰ, ਮਾਰਗ ਅਤੇ ਜਾਣਬੁੱਝ ਕੇ ਕੀਤਾ ਪ੍ਰਾਕਸੀ ਬਾਹਰ ਕੱਢਣਾ ਚਾਹੀਦਾ ਹੈ, ਸਿਰਫ ਬਾਹਰ ਕੱਢਣਾ ਨਹੀਂ। NO_PROXY ਮੇਲ ਹਰ ਹਿੱਸੇ ਲਈ ਸਟਰਿੰਗ ਤੁਲਨਾ ਹੈ, ਅਤੇ ਅੰਤਰਨਿਹਿਤ ਮਾਰਗ ਤੋਂ ਬਿਨਾਂ ਛੋਟ ਪ੍ਰਾਕਸੀ ਸਮੱਸਿਆ ਵਰਗੀ ਦਿਖਣ ਵਾਲੀ ਅਸਫਲਤਾ ਪੈਦਾ ਕਰਦੀ ਹੈ।

ਜਦੋਂ ਐਂਟਰਪ੍ਰਾਈਜ਼ TLS ਨਿਰੀਖਣ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਮਾਰਗ ਉੱਤੇ ਹੋਵੇ, ਤਾਂ ਇਸਦਾ ਪ੍ਰਮਾਣਿਤ ਰੂਟ ਇੰਜਣ ਜਾਂ Desktop ਵਰਕਫਲੋ ਰਾਹੀਂ ਸਥਾਪਿਤ ਕਰੋ। ਰਜਿਸਟਰੀ ਨੂੰ insecure-registries ਵਿੱਚ ਜੋੜਨਾ ਇੱਕ ਵੱਖਰੀ ਤਬਦੀਲੀ ਹੈ ਜੋ ਪ੍ਰਮਾਣਿਕਤਾ ਜਾਂਚ ਬੰਦ ਕਰਦੀ ਹੈ, ਅਤੇ ਇਹ ਟਰੱਸਟ ਸਟੋਰ ਸੰਰਚਨਾ ਨਹੀਂ ਹੈ।

ਇੱਕ ਨਿਯੰਤਰਿਤ ਪੁੱਲ ਦੁਹਰਾਓ ਅਤੇ ਦੇਖੋ ਕਿ ਕੀ ਬਦਲਿਆ

ਇੱਕ ਸੀਮਾ ਬਦਲੋ, ਉਸਦਾ ਮਾਲਕ ਹਿੱਸਾ ਰੀਸਟਾਰਟ ਕਰੋ, ਅਤੇ ਉਸੇ ਸੰਦਰਭ ਤੋਂ ਉਹੀ ਪੁੱਲ ਦੁਹਰਾਓ। ਨਤੀਜੇ ਵਜੋਂ ਮਿਲਿਆ ਇਮੇਜ ਸੰਦਰਭ ਅਤੇ digest ਪ੍ਰਮਾਣਿਤ ਕਰੋ, ਗਲਤੀ ਦੀ ਗੈਰਹਾਜ਼ਰੀ ਨਹੀਂ, ਕਿਉਂਕਿ ਕੈਸ਼ ਕੀਤੀ ਪਰਤ ਦੂਜੀ ਕੋਸ਼ਿਸ਼ ਨੂੰ ਪਹਿਲੀ ਨਾਲੋਂ ਬਹੁਤ ਘੱਟ ਮਾਰਗ ਲੰਘਣ ਦੇ ਸਕਦੀ ਹੈ। ਅਸਲ ਵਿੱਚ ਹੋਈਆਂ ਤਬਦੀਲੀਆਂ ਟਿਕਟ ਵਿੱਚ ਰੱਖੋ, ਕਿਉਂਕਿ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਨੇ ਸੱਚਮੁੱਚ ਕੀ ਪਰਖਿਆ ਇਸਦਾ ਉਹੀ ਇੱਕੋ ਇੱਕ ਰਿਕਾਰਡ ਹੈ।

ਬਿਲਡ ਕਦਮਾਂ ਅਤੇ ਚੱਲ ਰਹੇ ਕੰਟੇਨਰਾਂ ਦੇ ਆਪਣੇ ਨੈੱਟਵਰਕ ਸੰਦਰਭ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਪੁੱਲ ਆਪਣੇ ਆਪ ਕੰਮ ਕਰਨ ਤੋਂ ਬਾਅਦ ਉਹਨਾਂ ਨੂੰ ਵੱਖਰੇ ਸਵਾਲ ਮੰਨੋ।