Docker: ਇੱਕ ਕੰਟੇਨਰ ਨੂੰ VPN ਰਾਹੀਂ ਭੇਜੋ ਅਤੇ ਦੂਜੇ ਨੂੰ ਸਿੱਧਾ ਰੱਖੋ
ਟਨਲ ਨੂੰ ਇਸਦਾ ਆਪਣਾ ਕੰਟੇਨਰ ਦਿਓ, ਸਿਰਫ਼ ਉਹਨਾਂ ਸੇਵਾਵਾਂ ਨੂੰ ਜਿਨ੍ਹਾਂ ਨੂੰ ਇਸਦੀ ਲੋੜ ਹੈ ਉਹ ਨੇਮਸਪੇਸ ਸਾਂਝਾ ਕਰਨ ਦਿਓ, ਫਿਰ ਮਾਲਕ ਤੋਂ ਬਾਅਦ ਕੀ ਆਉਂਦਾ ਹੈ ਦਾ ਹਿਸਾਬ ਰੱਖੋ: ਪੋਰਟਾਂ, localhost, DNS.
ਇੱਕ ਹੋਸਟ, ਦੋ ਵਰਕਲੋਡ ਅਤੇ ਇੱਕ ਲੋੜ ਜੋ ਉਹਨਾਂ ਨੂੰ ਵੱਖ ਕਰਦੀ ਹੈ: ਇੱਕ ਡਾਊਨਲੋਡ ਕਲਾਇੰਟ ਜਿਸਨੂੰ ਵਪਾਰਕ VPN ਵਿੱਚੋਂ ਬਾਹਰ ਆਉਣਾ ਹੈ, ਅਤੇ ਇੱਕ ਪ੍ਰਬੰਧਨ ਇੰਟਰਫ਼ੇਸ ਜਿਸਨੂੰ ਹੋਸਟ ਦੇ ਕਨੈਕਸ਼ਨ ਦੀ ਵਰਤੋਂ ਜਾਰੀ ਰੱਖਣੀ ਹੈ। ਹੋਸਟ ਉੱਤੇ VPN ਕਲਾਇੰਟ ਇੰਸਟਾਲ ਕਰਨ ਨਾਲ ਲੋੜ ਤੁਰੰਤ ਪੂਰੀ ਨਹੀਂ ਹੁੰਦੀ, ਕਿਉਂਕਿ ਫਿਰ ਦੋਵੇਂ ਵਰਕਲੋਡ ਇੱਕੋ ਨਿਕਾਸ ਸਾਂਝਾ ਕਰਦੇ ਹਨ। ਜੋ ਪੈਟਰਨ ਅਸਲ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹੈ ਉਹ ਹੈ ਟਨਲ ਨੂੰ ਇਸਦੇ ਆਪਣੇ ਕੰਟੇਨਰ ਵਿੱਚ ਲਿਜਾਣਾ ਅਤੇ ਸਿਰਫ਼ ਉਹਨਾਂ ਵਰਕਲੋਡਾਂ ਨੂੰ ਉਸ ਕੰਟੇਨਰ ਦੇ ਨੈੱਟਵਰਕ ਨੇਮਸਪੇਸ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣ ਦੇਣਾ. ਬਾਕੀ ਸਭ ਆਮ Docker ਮਾਰਗ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਅੱਗੇ ਆਉਣ ਵਾਲੇ ਵੇਰਵੇ ਨੇਮਸਪੇਸ ਕਿਸਦਾ ਹੈ ਦੇ ਨਤੀਜੇ ਹਨ।
ਸਾਂਝਾ ਨੇਮਸਪੇਸ ਨਿਯਮ ਕਿਉਂ ਬਦਲਦਾ ਹੈ
ਦੂਜੇ ਦੇ ਨੇਮਸਪੇਸ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣ ਵਾਲੇ ਕੰਟੇਨਰ ਨੂੰ ਆਪਣਾ ਨੈੱਟਵਰਕ ਸਟੈਕ ਨਹੀਂ ਮਿਲਦਾ। ਇਹ ਉਸ ਕੰਟੇਨਰ ਵਾਂਗ ਹੀ ਇੰਟਰਫ਼ੇਸ, ਉਹੀ ਰਾਊਟਿੰਗ ਸਾਰਣੀ ਅਤੇ ਉਹੀ loopback ਦੇਖਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਇਹ ਸ਼ਾਮਲ ਹੋਇਆ, ਅਤੇ ਇਸੇ ਲਈ ਇਹ ਪੈਟਰਨ ਲਾਭਦਾਇਕ ਹੈ: ਵਰਕਲੋਡ ਆਮ ਤਰ੍ਹਾਂ ਰਿਜ਼ੌਲਵ ਅਤੇ ਕਨੈਕਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਹੇਠਾਂ ਦਾ ਟਨਲ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਦੱਸੇ ਬਿਨਾਂ ਟ੍ਰੈਫ਼ਿਕ ਫੜ ਲੈਂਦਾ ਹੈ। ਕੀਮਤ ਇਹ ਹੈ ਕਿ ਹਰ ਨੈੱਟਵਰਕ ਸੰਬੰਧੀ ਸੈਟਿੰਗ ਦਾ ਹੁਣ ਇੱਕੋ ਮਾਲਕ ਹੈ, ਅਤੇ ਸ਼ਾਮਲ ਹੋਣ ਵਾਲਾ ਕੰਟੇਨਰ ਉਹ ਨਹੀਂ ਹੈ।
ਇਹ ਮਾਲਕੀ ਨਿਯਮ ਬਹੁਤ ਸਾਰੇ ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਉਹਨਾਂ ਦੇ ਪੁੱਛੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਦਿੰਦਾ ਹੈ। ਜੇ ਸੈਟਿੰਗ ਨੈੱਟਵਰਕ ਸਟੈਕ ਵਿੱਚ ਰਹਿੰਦੀ ਹੈ, ਤਾਂ ਇਹ ਸਾਈਡਕਾਰ ਦੀ ਹੈ। ਜੇ ਇਹ ਪ੍ਰਕਿਰਿਆ ਦਾ ਵਰਣਨ ਕਰਦੀ ਹੈ, ਤਾਂ ਇਹ ਵਰਕਲੋਡ ਨਾਲ ਰਹਿੰਦੀ ਹੈ।
loopback ਉਹ ਹਿੱਸਾ ਹੈ ਜੋ ਲੋਕਾਂ ਨੂੰ ਹੈਰਾਨ ਕਰਦਾ ਹੈ। ਸ਼ਾਮਲ ਹੋਣ ਵਾਲੇ ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ, localhost ਸਾਈਡਕਾਰ ਦੇ loopback ਉੱਤੇ ਰਿਜ਼ੌਲਵ ਹੁੰਦਾ ਹੈ, ਆਪਣੇ ਕਿਸੇ ਨਿੱਜੀ ਉੱਤੇ ਨਹੀਂ, ਇਸ ਲਈ 127.0.0.1 ਉੱਤੇ ਬੱਝ ਕੇ ਅਲੱਗ ਰਹਿਣ ਦੀ ਉਮੀਦ ਕਰਨ ਵਾਲੀ ਸੇਵਾ ਹੁਣ ਉਹ ਪਤਾ ਟਨਲ ਕੰਟੇਨਰ ਨਾਲ ਸਾਂਝਾ ਕਰਦੀ ਹੈ।
ਨੇਮਸਪੇਸ ਵਾਲੇ ਕੰਟੇਨਰ ਉੱਤੇ ਪੋਰਟ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ
ਪੋਰਟ ਮੈਪਿੰਗ ਨੇਮਸਪੇਸ ਦੇ ਮਾਲਕ ਦੀ ਹੈ, ਭਾਵੇਂ ਸੁਣਨ ਵਾਲੀ ਪ੍ਰਕਿਰਿਆ ਦੂਜੇ ਕੰਟੇਨਰ ਵਿੱਚ ਚੱਲਦੀ ਹੋਵੇ। ਮੈਪਿੰਗ ਸਾਈਡਕਾਰ ਉੱਤੇ ਘੋਸ਼ਿਤ ਕਰੋ, ਅਤੇ ਵਰਕਲੋਡ ਆਪਣੀ ਪ੍ਰਕਿਰਿਆ ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਨੂੰ ਅਛੂਤਾ ਰੱਖੇ। ਸ਼ਾਮਲ ਹੋਣ ਵਾਲੀ ਸੇਵਾ ਉੱਤੇ ਮੈਪਿੰਗ ਲਾਗੂ ਨਹੀਂ ਹੋ ਸਕਦੀ, ਚਾਹੇ ਇੰਜਣ ਇਸਨੂੰ ਰੱਦ ਕਰੇ ਜਾਂ ਕੰਟੇਨਰ ਕਿਵੇਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਇਸਦੇ ਆਧਾਰ ਉੱਤੇ ਚੁੱਪਚਾਪ ਅਣਡਿੱਠ ਕਰੇ, ਅਤੇ ਇਸੇ ਲਈ ਇੱਕ ਪਲ ਪਹਿਲਾਂ ਪਹੁੰਚਯੋਗ ਇੰਟਰਫ਼ੇਸ ਪੈਟਰਨ ਲਾਗੂ ਹੁੰਦਿਆਂ ਹੀ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ।
services:
gluetun:
image: qmcgaw/gluetun
cap_add: [NET_ADMIN]
ports: ["8080:8080"]
client-vpn:
image: example/client
network_mode: "service:gluetun"
client-direct:
image: example/client
ports: ["8081:8080"]ਇਸ ਬਲਾਕ ਨੂੰ ਤਿੰਨ ਸੇਵਾਵਾਂ ਨਹੀਂ ਸਗੋਂ ਤਿੰਨ ਫ਼ੈਸਲੇ ਪੜ੍ਹੋ। ਸਾਈਡਕਾਰ ਟਨਲ ਅਤੇ ਪ੍ਰਕਾਸ਼ਿਤ ਪੋਰਟ ਦਾ ਮਾਲਕ ਹੈ; ਸ਼ਾਮਲ ਹੋਣ ਵਾਲਾ ਕਲਾਇੰਟ ਕੋਈ ਨੈੱਟਵਰਕ ਘੋਸ਼ਿਤ ਨਹੀਂ ਕਰਦਾ; ਸਿੱਧਾ ਕਲਾਇੰਟ ਡਿਫ਼ਾਲਟ ਨੈੱਟਵਰਕ ਉੱਤੇ ਆਪਣੀ ਮੈਪਿੰਗ ਰੱਖਦਾ ਹੈ। ਸਮਰੱਥਾ NET_ADMIN ਹੀ ਸਾਈਡਕਾਰ ਨੂੰ ਇੰਟਰਫ਼ੇਸ ਬਣਾਉਣ ਅਤੇ ਰਾਊਟ ਬਦਲਣ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਇਸੇ ਕਰਕੇ ਇਸ ਕੰਟੇਨਰ ਨੂੰ ਉਹਨਾਂ ਵਰਕਲੋਡਾਂ ਨਾਲੋਂ ਵੱਧ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਚਾਹੀਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਦੀ ਇਹ ਸੇਵਾ ਕਰਦਾ ਹੈ।
ਸਿੱਧੀ ਰਹਿਣ ਵਾਲੀ ਸੇਵਾ ਆਪਣਾ ਨੈੱਟਵਰਕ ਰੱਖਦੀ ਹੈ
ਜਿਸ ਵਰਕਲੋਡ ਨੂੰ ਟਨਲ ਵਿੱਚੋਂ ਨਹੀਂ ਲੰਘਣਾ ਚਾਹੀਦਾ ਉਹ ਡਿਫ਼ਾਲਟ ਬ੍ਰਿਜ ਜਾਂ ਆਪਣਾ ਵਰਤੋਂਕਾਰ-ਪਰਿਭਾਸ਼ਿਤ ਨੈੱਟਵਰਕ ਆਪਣੇ ਪ੍ਰਕਾਸ਼ਿਤ ਪੋਰਟ ਅਤੇ ਆਪਣੇ ਨਿਕਾਸ ਸਮੇਤ ਰੱਖਦਾ ਹੈ। ਦੋਵੇਂ ਕੰਟੇਨਰ ਨਾਮ ਨਾਲ ਗੱਲ ਕਰ ਸਕਣ ਲਈ ਇਸਨੂੰ ਸਾਈਡਕਾਰ ਨੈੱਟਵਰਕ ਨਾਲ ਜੋੜਨ ਦਾ ਲਾਲਚ ਹੁੰਦਾ ਹੈ, ਪਰ ਉਹ ਇੱਕ ਕਦਮ ਇਸਦਾ ਟ੍ਰੈਫ਼ਿਕ ਚੁੱਪਚਾਪ ਟਨਲ ਵਿੱਚ ਲੈ ਜਾਂਦਾ ਹੈ। ਜੇ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਦੂਜੇ ਤੱਕ ਪਹੁੰਚਣਾ ਹੈ, ਤਾਂ ਵੱਖਰਾ ਵਰਤੋਂਕਾਰ-ਪਰਿਭਾਸ਼ਿਤ ਨੈੱਟਵਰਕ ਬਣਾਓ, ਦੋਵੇਂ ਨੂੰ ਉਸ ਨਾਲ ਜੋੜੋ, ਅਤੇ ਸਾਈਡਕਾਰ ਨੂੰ ਬਾਹਰ ਜਾਣ ਦਾ ਇੱਕੋ-ਇੱਕ ਰਾਹ ਰਹਿਣ ਦਿਓ।
ਦੋ ਸਵਾਲ ਵੱਖਰੇ ਰੱਖੋ: ਕਿਹੜੇ ਕੰਟੇਨਰ ਇੱਕ ਦੂਜੇ ਤੱਕ ਪਹੁੰਚ ਸਕਦੇ ਹਨ, ਅਤੇ ਕਿਹੜਾ ਕਿੱਥੋਂ ਬਾਹਰ ਜਾਂਦਾ ਹੈ। ਇਹਨਾਂ ਨੂੰ ਮਿਲਾਉਣਾ ਹੀ ਇਸ ਡਿਜ਼ਾਈਨ ਦੇ ਦੁਬਾਰਾ ਪੂਰੇ ਹੋਸਟ-ਵਿਆਪੀ VPN ਬਣਨ ਦਾ ਸਭ ਤੋਂ ਆਮ ਤਰੀਕਾ ਹੈ।
ਪਹਿਲੇ ਘੰਟੇ ਲਈ ਅਸਫ਼ਲਤਾ ਮੈਟ੍ਰਿਕਸ
ਬਹੁਤੇ ਪਹਿਲੇ ਯਤਨ ਚਾਰ ਵਿੱਚੋਂ ਇੱਕ ਤਰੀਕੇ ਨਾਲ ਅਸਫ਼ਲ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਹਰ ਇੱਕ ਦਾ ਕਾਰਨ ਵੱਖਰਾ ਹੈ। ਇਹਨਾਂ ਨੂੰ ਇਸੇ ਕ੍ਰਮ ਵਿੱਚ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਪਹਿਲੇ ਦੋ ਲਗਭਗ ਹਰ ਰਿਪੋਰਟ ਦੀ ਵਿਆਖਿਆ ਕਰਦੇ ਹਨ।
| Symptom | Likely cause |
|---|---|
| Web UI unreachable after the change | Port mapping declared on the joining container instead of the sidecar |
| Both containers show the provider's exit address | The direct service was attached to the sidecar network |
| Internal names stop resolving | Resolver settings live on the host, not in the shared namespace |
| Health check fails but the app works | The check probes localhost, which now means the sidecar |
ਚੌਥੀ ਕਤਾਰ ਉਹ ਹੈ ਜਿਸਨੂੰ ਲੋਕ ਗਲਤੀ ਨਾਲ ਐਪਲੀਕੇਸ਼ਨ ਬੱਗ ਸਮਝਦੇ ਹਨ। ਵਰਕਲੋਡ ਦੇ ਆਪਣੇ loopback ਵਿਰੁੱਧ ਲਿਖੀ ਜਾਂਚ ਹੁਣ ਟਨਲ ਕੰਟੇਨਰ ਦੀ ਪਰਖ ਕਰ ਰਹੀ ਹੈ, ਇਸ ਲਈ ਇਹ ਜਾਂ ਤਾਂ ਅਸਫ਼ਲ ਹੁੰਦੀ ਹੈ ਜਾਂ ਬਿਲਕੁਲ ਗਲਤ ਸੇਵਾ ਦੀ ਰਿਪੋਰਟ ਕਰਦੀ ਹੈ।
ਜਦੋਂ ਇੱਕ ਹੀ ਹੋਸਟਨਾਮ ਨੂੰ ਟਨਲ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ
ਕਈ ਵਾਰ ਪੂਰਾ ਟਨਲ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੁੰਦਾ ਹੈ: ਇੱਕ ਅੰਦਰੂਨੀ ਨਾਮ ਨੂੰ ਕਾਰਪੋਰੇਟ VPN ਰਾਹੀਂ ਜਾਣਾ ਹੁੰਦਾ ਹੈ ਜਦਕਿ ਸਥਾਨਕ ਸਾਕਟ ਜਾਂ ਡਿਸਪਲੇ ਕਨੈਕਸ਼ਨ ਚੱਲਦਾ ਰਹਿੰਦਾ ਹੈ। ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ ਪੂਰਾ ਟਨਲ ਉਸ ਮਾਰਗ ਅਤੇ ਹੋਸਟ ਨੂੰ ਸੰਬੋਧਿਤ ਸਭ ਕੁਝ ਤੋੜ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਸਿਰਫ਼ ਲੋੜੀਂਦਾ ਪ੍ਰੀਫ਼ਿਕਸ ਰਾਊਟ ਕਰੋ। ਕਲਾਇੰਟ ਦੁਆਲੇ ਵੰਡਿਆ ਰਾਊਟਿੰਗ ਰੈਪਰ ਇਹ ਕਰਦਾ ਹੈ, ਨਾਮਿਤ ਹੋਸਟ ਨੂੰ ਟਨਲ ਰਾਹੀਂ ਭੇਜਦਾ ਹੈ ਅਤੇ ਬਾਕੀ ਸਭ ਲਈ ਪਿਛਲਾ ਰਾਹ ਅਛੂਤਾ ਰੱਖਦਾ ਹੈ।
ਇਹ ਤਦ ਚੁਣੋ ਜਦੋਂ ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਸੇਵਾ ਤੱਕ ਪਹੁੰਚਣਾ ਹੈ ਅਤੇ ਕੰਟੇਨਰ ਦਾ ਸਾਰਾ ਟ੍ਰੈਫ਼ਿਕ ਹਿਲਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰ ਰਹੇ। ਇਹ ਸਾਈਡਕਾਰ ਤੋਂ ਵੱਖਰਾ ਸਾਧਨ ਹੈ ਅਤੇ ਵੱਖਰੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ।
ਪੁਸ਼ਟੀ ਕਰੋ, ਫਿਰ ਇਸਨੂੰ ਮੁੜ-ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਟਿਕਣ ਵਾਲਾ ਬਣਾਓ
ਹਰ ਕੰਟੇਨਰ ਨੂੰ ਪੁੱਛੋ ਕਿ ਇਹ ਕਿਸ ਪਤੇ ਤੋਂ ਆਉਂਦਾ ਦਿਸਦਾ ਹੈ। ਟਨਲ ਵਾਲੇ ਨੂੰ ਪ੍ਰਦਾਤਾ ਦਾ ਪਤਾ ਛਾਪਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਸਿੱਧੇ ਨੂੰ ਹੋਸਟ ਦਾ ਨਿਕਾਸ। ਇੱਕੋ ਜਿਹੇ ਜਵਾਬ ਦਾ ਅਰਥ ਹੈ ਕਿ ਸਿੱਧੀ ਸੇਵਾ ਨੇ ਗਲਤ ਨੇਮਸਪੇਸ ਵਿਰਾਸਤ ਵਿੱਚ ਲਿਆ ਹੈ ਜਾਂ ਹੋਸਟ-ਪੱਧਰੀ VPN ਅਜੇ ਵੀ ਸਭ ਕੁਝ ਫੜ ਰਿਹਾ ਹੈ, ਅਤੇ ਉਹ ਦੋ ਸੁਧਾਰ ਵੱਖਰੇ ਹਨ। ਹਰ compose ਸੋਧ ਤੋਂ ਬਾਅਦ ਜਾਂਚ ਦੁਬਾਰਾ ਚਲਾਓ, ਕਿਉਂਕਿ ਇੱਕ ਕਾਪੀ ਕੀਤਾ ਸੇਵਾ ਬਲਾਕ ਸਮੱਸਿਆ ਵਾਪਸ ਲਿਆਉਣ ਲਈ ਕਾਫ਼ੀ ਹੈ।
ਤਿੰਨ ਚੀਜ਼ਾਂ ਬਾਅਦ ਵਿੱਚ ਟੁੱਟਣ ਦੀ ਪ੍ਰਵਿਰਤੀ ਰੱਖਦੀਆਂ ਹਨ। DNS ਨੇਮਸਪੇਸ ਦੇ ਮਾਲਕ ਦਾ ਪਿੱਛਾ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਰਿਜ਼ੌਲਵਰ ਅਤੇ ਖੋਜ ਡੋਮੇਨ ਦੀਆਂ ਸੈਟਿੰਗਾਂ ਹੋਸਟ ਉੱਤੇ ਨਹੀਂ ਸਗੋਂ ਸਾਈਡਕਾਰ ਉੱਤੇ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਪੋਰਟ-ਫ਼ਾਰਵਰਡ ਕੀਤਾ VPN ਮੁੜ-ਕਨੈਕਸ਼ਨ ਉੱਤੇ ਆਪਣਾ ਸੁਣਨ ਵਾਲਾ ਪੋਰਟ ਬਦਲਦਾ ਹੈ, ਇਸ ਲਈ ਪ੍ਰਦਾਤਾ ਦਾ ਫ਼ਾਰਵਰਡ ਕੀਤਾ ਪੋਰਟ ਅਤੇ ਕੰਟੇਨਰ-ਪਾਸੇ ਦਾ ਸੁਣਨ ਵਾਲਾ ਪੋਰਟ ਕਲਾਇੰਟ ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਜਾਂ ਪੋਰਟ ਮੈਪਿੰਗ ਵਿੱਚ ਵਾਪਸ ਲਿਖਣਾ ਪੈਂਦਾ ਹੈ, ਆਮ ਤੌਰ ਉੱਤੇ ਪ੍ਰਦਾਤਾ ਦਾ API ਪੜ੍ਹਨ ਵਾਲੇ ਛੋਟੇ ਅੱਪਡੇਟਰ ਰਾਹੀਂ। ਅਤੇ localhost ਵਿਰੁੱਧ ਲਿਖੀ ਕੋਈ ਵੀ ਜਾਂਚ ਹੁਣ ਵਰਕਲੋਡ ਦੀ ਥਾਂ ਟਨਲ ਕੰਟੇਨਰ ਨੂੰ ਪੁੱਛਦੀ ਹੈ।
ਪੈਟਰਨ ਲਿਖੋ, ਜਿਸ ਵਿੱਚ ਇਹ ਵੀ ਸ਼ਾਮਲ ਹੋਵੇ ਕਿ ਕਿਹੜਾ ਕੰਟੇਨਰ ਨੇਮਸਪੇਸ ਰੱਖਦਾ ਹੈ ਅਤੇ ਕਿਹੜੀਆਂ ਪੋਰਟਾਂ ਇਸਦੀਆਂ ਹਨ। ਅਗਲਾ ਵਿਅਕਤੀ ਇੱਕ ਸੇਵਾ ਜੋੜੇਗਾ, ਗਲਤ ਬਲਾਕ ਕਾਪੀ ਕਰੇਗਾ ਅਤੇ ਇਸ ਲੇਖ ਦੀ ਪਹਿਲੀ ਅਸਫ਼ਲਤਾ ਦੁਹਰਾਏਗਾ।