ਪ੍ਰੌਕਸੀ ਕੰਟੇਨਰ DNS ਕੰਟੇਨਰ ਦੀ ਸਵੈਚਾਲਿਤ ਵਰਤੋਂ ਕਿਉਂ ਨਹੀਂ ਕਰਦਾ

ਇੱਕੋ Docker ਹੋਸਟ ਉੱਤੇ ਪ੍ਰੌਕਸੀ ਅਤੇ DNS ਸਰਵਰ ਚਲਾਉਣਾ ਉਨ੍ਹਾਂ ਦੇ DNS ਰਸਤਿਆਂ ਨੂੰ ਜੋੜਦਾ ਨਹੀਂ। ਤਿੰਨ ਵੱਖਰੇ ਸੰਬੰਧ ਮਹੱਤਵਪੂਰਨ ਹਨ:

• ਨੈੱਟਵਰਕ ਪਹੁੰਚ। ਵੱਖਰੇ Compose ਪ੍ਰੋਜੈਕਟਾਂ ਕੋਲ ਆਮ ਤੌਰ ਉੱਤੇ ਵੱਖਰੇ ਡਿਫਾਲਟ ਨੈੱਟਵਰਕ ਹੁੰਦੇ ਹਨ। ਸੇਵਾਵਾਂ ਨੂੰ ਢੁੱਕਵੇਂ ਸਾਂਝੇ ਨੈੱਟਵਰਕ ਉੱਤੇ ਰੱਖੋ, ਭਾਵੇਂ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਦੇ ਅੰਦਰ ਜਾਂ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿਚਕਾਰ ਸਪਸ਼ਟ ਤੌਰ ਉੱਤੇ ਸਾਂਝੇ ਕੀਤੇ ਨੈੱਟਵਰਕ ਰਾਹੀਂ।
• ਸੇਵਾ ਖੋਜ। ਕਸਟਮ Docker ਨੈੱਟਵਰਕ ਦਾ ਅੰਦਰੂਨੀ DNS ਕੰਟੇਨਰ ਨਾਮ ਹੱਲ ਕਰ ਸਕਦਾ ਹੈ। ਇਸ ਨਾਲ ਐਪਲੀਕੇਸ਼ਨ ਗੁਆਂਢੀ ਲੱਭ ਸਕਦੀ ਹੈ; ਪਰ ਇਹ ਉਸ ਗੁਆਂਢੀ ਨੂੰ ਸਵੈਚਾਲਿਤ ਤੌਰ ਉੱਤੇ ਆਪਣਾ DNS ਰੈਜ਼ੋਲਵਰ ਨਹੀਂ ਚੁਣਦਾ।
• ਰੈਜ਼ੋਲਵਰ ਚੋਣ। ਪ੍ਰੌਕਸੀ ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਰੈਜ਼ੋਲਵਰ ਦੀ ਪਛਾਣ ਕਰੋ। Compose ਦਾ dns ਖੇਤਰ DNS ਸਰਵਰ ਪਤੇ ਲੈਂਦਾ ਹੈ। dns.local ਵਰਗਾ ਨਾਮ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਹੱਲ ਹੁੰਦਾ ਹੈ, ਉਸ ਖੇਤਰ ਲਈ ਇਸ ਨੂੰ ਵੈਧ ਮੁੱਲ ਨਹੀਂ ਬਣਾਉਂਦਾ।

ਕਿਊਰੀ ਨੂੰ ਪ੍ਰੌਕਸੀ ਕੰਟੇਨਰ ਤੋਂ ਇਸ ਦੇ ਸੰਰਚਿਤ ਰੈਜ਼ੋਲਵਰ ਪਤੇ ਤੱਕ ਟ੍ਰੈਕ ਕਰੋ। ਉਸ ਪਤੇ ਉੱਤੇ ਰੂਟ ਅਤੇ DNS ਸਰੋਤਾ ਹੋਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਹੋਸਟ ਪੋਰਟ 53 ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨਾ ਹੋਸਟ ਵੱਲ ਪਹੁੰਚ ਮਾਰਗ ਬਣਾਉਂਦਾ ਹੈ; ਪਰ ਇਹ ਕੰਟੇਨਰਾਂ ਨੂੰ ਇਸ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਨਹੀਂ ਕਹਿੰਦਾ। ਨੈੱਟਵਰਕ ਸਾਂਝਾ ਕਰਨ ਵਾਲੇ ਕੰਟੇਨਰ ਇਸ ਦੀ ਬਜਾਏ ਸਿੱਧਾ ਸੰਚਾਰ ਕਰ ਸਕਦੇ ਹਨ।

ਜੇ ਸੰਰਚਨਾ DNS ਕੰਟੇਨਰ ਦੇ ਪਤੇ ਦਾ ਹਵਾਲਾ ਦਿੰਦੀ ਹੈ, ਤਾਂ ਇਸ ਨੂੰ ਅਨੁਕੂਲ IPAM ਸੰਰਚਨਾ ਅਧੀਨ ਸਥਿਰ ਰੱਖੋ। ਕੱਲ੍ਹ ਦੇ ਕੰਟੇਨਰ ਤੋਂ ਕਾਪੀ ਕੀਤਾ ਗਤੀਸ਼ੀਲ ਤੌਰ ਉੱਤੇ ਨਿਰਧਾਰਿਤ ਪਤਾ ਮੁੜ ਬਣਾਉਣ ਸਮੇਂ ਫੇਲ ਹੋ ਸਕਦਾ ਹੈ। ਰੈਜ਼ੋਲਵਰ ਦੇ ਉੱਪਰਲੇ ਮਾਰਗ ਦੀ ਵੀ ਜਾਂਚ ਕਰੋ: ਬਿਨਾਂ ਜਵਾਬ ਵਾਲੀਆਂ ਕਿਊਰੀਆਂ ਨੂੰ ਵਾਪਸ ਇਸੇ ਕੋਲ ਭੇਜਣਾ ਅਪਹੁੰਚ ਰੈਜ਼ੋਲਵਰ ਨਾਲੋਂ ਵੱਖਰੀ ਅਸਫਲਤਾ ਪੈਦਾ ਕਰਦਾ ਹੈ।

ਅੰਤ ਵਿੱਚ, ਪਛਾਣੋ ਕਿ ਮੰਜ਼ਿਲ ਕੌਣ ਹੱਲ ਕਰਦਾ ਹੈ। CONNECT ਨਾਮ ਹੱਲ ਕਰਨ ਵਾਲਾ HTTP ਪ੍ਰੌਕਸੀ ਇਹ ਕੰਟੇਨਰ ਮਾਰਗ ਵਰਤ ਸਕਦਾ ਹੈ; ਸਥਾਨਕ ਤੌਰ ਉੱਤੇ ਹੱਲ ਕਰਨ ਵਾਲਾ SOCKS ਕਲਾਇੰਟ ਸ਼ਾਇਦ ਨਾ ਕਰੇ। ਹੋਸਟ ਉੱਤੇ ਖੋਜ ਹੋਸਟ ਦੇ ਮਾਰਗ ਨੂੰ ਸਾਬਤ ਕਰਦੀ ਹੈ, ਪ੍ਰੌਕਸੀ ਪ੍ਰਕਿਰਿਆ ਦੇ ਨਹੀਂ।