ਤੁਹਾਡਾ ਕਾਰਪੋਰੇਟ ਪ੍ਰੌਕਸੀ ਕਿਉਂ Compose ਸੇਵਾ ਨਾਮ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੈ
ਇੱਕ HTTP ਕਲਾਇੰਟ Docker ਦੇ ਸੇਵਾ-ਨਾਮ ਹੱਲ ਦੀ ਵਰਤੋਂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੇ ਸੰਰਚਿਤ ਪ੍ਰੌਕਸੀ ਨੂੰ ਅੰਦਰੂਨੀ ਸੇਵਾ ਬੇਨਤੀ ਭੇਜ ਸਕਦਾ ਹੈ। ਸਹੀ ਕਲਾਇੰਟ ਲਈ ਜਾਣ-ਬੁੱਝ ਕੇ ਬਾਈਪਾਸ ਜੋੜੋ।
ਐਪਲੀਕੇਸ਼ਨ ਆਪਣੀ ਕਾਰਪੋਰੇਟ ਪ੍ਰੌਕਸੀ ਰਾਹੀਂ ਇੰਟਰਨੈੱਟ ਤੱਕ ਪਹੁੰਚਦੀ ਹੈ, ਪਰ http://catalog:8080/ ਅਸਫਲ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਪ੍ਰੌਕਸੀ “catalog” ਨੂੰ ਹੱਲ ਨਹੀਂ ਕਰ ਸਕਦੀ। ਉਹ ਬੇਨਤੀ ਸ਼ਾਇਦ ਕਦੇ Docker ਦੇ ਅੰਦਰੂਨੀ DNS ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੀ।
ਇੱਕ HTTP ਕਲਾਇੰਟ ਸਿੱਧਾ ਕਨੈਕਸ਼ਨ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੀ ਪ੍ਰੌਕਸੀ ਚੁਣ ਸਕਦਾ ਹੈ। ਫਿਰ ਬਾਹਰੀ ਪ੍ਰੌਕਸੀ ਨੂੰ ਅਜਿਹਾ ਨਾਮ ਮਿਲਦਾ ਹੈ ਜਿਸਦਾ ਅਰਥ ਸਿਰਫ਼ Compose ਨੈੱਟਵਰਕ ਦੇ ਅੰਦਰ ਹੀ ਹੁੰਦਾ ਹੈ।
- ਬੇਨਤੀ ਵਿੱਚ ਹੋਸਟਨਾਮ ਵਰਤੋ। Compose ਸੇਵਾਵਾਂ ਢੁਕਵੇਂ ਨੈੱਟਵਰਕ ਉੱਤੇ ਸੇਵਾ ਨਾਮ ਨਾਲ ਲੱਭੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ। ਬਦਲ ਸਕਣ ਵਾਲੇ ਕੰਟੇਨਰ IP ਨੂੰ ਹਾਰਡ-ਕੋਡ ਕਰਨ ਦੀ ਬਜਾਏ ਖਪਤਕਾਰ ਕਲਾਇੰਟ ਦੀ ਸਮਰਥਿਤ ਬਾਈਪਾਸ ਸੰਰਚਨਾ ਵਿੱਚ
catalogਜੋੜੋ। - ਮੌਜੂਦਾ ਅਪਵਾਦ ਬਚਾਓ। ਵਾਤਾਵਰਣ-ਸੁਚੇਤ ਕਲਾਇੰਟ ਲਈ, ਸੰਬੰਧਿਤ ਐਂਟਰੀਆਂ ਨੂੰ ਸੰਗਠਨ ਦੀ ਸੂਚੀ ਨਾਲ ਮਿਲਾਓ:
NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalogਇਮੇਜ ਵਿੱਚ ਮੌਜੂਦ ਅਸਲ ਲਾਇਬ੍ਰੇਰੀ ਜਾਂ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਦੀ ਕੇਸ ਸੰਭਾਲ, ਸੰਸਕਰਣ ਅਤੇ ਮਿਲਾਨ ਵਿਆਕਰਣ ਜਾਂਚੋ। ਕੋਈ ਸਰਵਵਿਆਪੀ NO_PROXY ਪਾਰਸਰ ਨਹੀਂ ਹੈ। ਛੋਟੀ ਇਮੇਜ ਵਿੱਚ wget ਨਾਮ ਦਾ ਪ੍ਰੋਗਰਾਮ GNU Wget ਵਾਂਗ ਵਿਵਹਾਰ ਕਰਨ ਲਈ ਬਾਧਿਅ ਨਹੀਂ ਹੈ।
ਬੇਨਤੀ ਵੱਲੋਂ ਸਿੱਧੀ ਰੂਟਿੰਗ ਚੁਣਨ ਤੋਂ ਬਾਅਦ, ਕਾਲਰ ਅਤੇ ਸੇਵਾ ਦਾ ਸਾਂਝਾ ਨੈੱਟਵਰਕ, ਸੁਣਨ ਵਾਲੀ ਸੇਵਾ ਅਤੇ ਕੰਟੇਨਰ ਪੋਰਟ ਜਾਂਚੋ। ਪ੍ਰਕਾਸ਼ਿਤ ਹੋਸਟ ਪੋਰਟ ਇੱਕ ਹੋਰ ਐਂਡਪੌਇੰਟ ਹੈ। ਬਾਈਪਾਸ ਗੁੰਮ ਨੈੱਟਵਰਕ ਅਟੈਚਮੈਂਟ ਨਹੀਂ ਜੋੜ ਸਕਦੀ, ਜਿਵੇਂ ਨੈੱਟਵਰਕ ਮੁੜ ਬਣਾਉਣ ਨਾਲ ਬਾਹਰੀ ਪ੍ਰੌਕਸੀ ਨੂੰ ਨਿੱਜੀ Compose ਨਾਮ ਨਹੀਂ ਸਿਖਾਇਆ ਜਾ ਸਕਦਾ।
ਇੱਛਤ ਵੰਡ ਬਣਾਈ ਰੱਖੋ: ਅੰਦਰੂਨੀ ਬੇਨਤੀਆਂ ਆਪਣਾ ਅੰਦਰੂਨੀ ਰਾਹ ਵਰਤਦੀਆਂ ਹਨ; ਬਾਹਰੀ ਬੇਨਤੀਆਂ ਮਨਜ਼ੂਰ ਪ੍ਰੌਕਸੀ ਰੱਖਦੀਆਂ ਹਨ। ਪ੍ਰੌਕਸੀ ਨੂੰ ਵਿਸ਼ਵ ਪੱਧਰੀ ਬੰਦ ਕਰਨਾ ਇਸ ਇੱਕ ਅਸਫਲਤਾ ਨੂੰ ਲੁਕਾ ਸਕਦਾ ਹੈ ਅਤੇ ਅਗਲੀ ਬਾਹਰੀ ਬੇਨਤੀ ਲਈ ਲੋੜੀਂਦਾ ਰਾਹ ਹਟਾ ਸਕਦਾ ਹੈ।