Podman pasta: ਰੂਟਲੈੱਸ ਕੰਟੇਨਰ ਤੋਂ ਹੋਸਟ ਲੂਪਬੈਕ ਪ੍ਰੌਕਸੀ ਤੱਕ ਪਹੁੰਚੋ

ਹੋਸਟ ਦਾ 127.0.0.1:8118 ਅਤੇ ਕੰਟੇਨਰ ਦਾ 127.0.0.1:8118 ਆਮ ਤੌਰ 'ਤੇ ਵੱਖਰੇ ਲੂਪਬੈਕ ਐਂਡਪੁਆਇੰਟ ਹੁੰਦੇ ਹਨ। ਰੂਟਲੈੱਸ ਕੰਟੇਨਰ ਵਿੱਚ ਪ੍ਰੌਕਸੀ ਵੇਰੀਏਬਲ ਭੇਜਣਾ ਉਹਨਾਂ ਲੂਪਬੈਕ ਇੰਟਰਫੇਸਾਂ ਨੂੰ ਨਹੀਂ ਜੋੜਦਾ।

pasta ਵਰਤਣ ਵਾਲੇ Podman ਡਿਪਲੌਇਮੈਂਟ ਵਿੱਚ, ਇਸਦੀ namespace-to-host TCP ਫਾਰਵਰਡਿੰਗ namespace ਦੇ ਅੰਦਰ ਲੋੜੀਂਦਾ ਹੋਸਟ ਪੋਰਟ ਖੋਲ੍ਹ ਸਕਦੀ ਹੈ:

podman run --network=pasta:-T,8118 \
  --env http_proxy=http://127.0.0.1:8118 \
  --env https_proxy=http://127.0.0.1:8118 \
  existing-image application-command

ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਮੌਜੂਦਾ ਇਮੇਜ ਅਤੇ ਕਮਾਂਡ ਵਰਤੋ। ਉਦਾਹਰਨ ਮੰਨਦੀ ਹੈ ਕਿ ਹੋਸਟ ਪਾਸੇ ਪੋਰਟ 8118 'ਤੇ ਕੰਮ ਕਰਦੀ HTTP ਪ੍ਰੌਕਸੀ ਹੈ ਅਤੇ ਦਿਖਾਇਆ ਗਿਆ ਫਾਰਵਰਡਿੰਗ ਵਿਕਲਪ ਸਮਰਥਨ ਕਰਨ ਵਾਲਾ Podman/pasta ਸੰਸਕਰਣ ਹੈ।

pasta ਦਾ ਵੱਡਾ -T ਨਿਸ਼ਾਨਾ namespace ਤੋਂ ਹੋਸਟ namespace ਵੱਲ ਫਾਰਵਰਡ ਕਰਦਾ ਹੈ। ਛੋਟਾ -t ਅਤੇ Podman ਦਾ --publish ਉਲਟ ਦਿਸ਼ਾ ਵੱਲ ਹੁੰਦੇ ਹਨ। ਇਸ ਲਈ ਕੰਟੇਨਰ ਪੋਰਟ 8118 ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨਾ ਆਪਣੇ ਆਪ ਹੋਸਟ ਦੀ ਪ੍ਰੌਕਸੀ ਨੂੰ ਕੰਟੇਨਰ ਲਈ ਉਪਲਬਧ ਨਹੀਂ ਕਰਦਾ।

Podman ਡਿਫ਼ਾਲਟ ਰੂਪ ਵਿੱਚ namespace-to-host ਪੋਰਟ ਸਵੈਚਾਲਿਤ ਫਾਰਵਰਡਿੰਗ ਬੰਦ ਰੱਖਦਾ ਹੈ; ਸਪਸ਼ਟ ਪੋਰਟ ਇੱਥੇ ਲੋੜੀਂਦੀ ਸੇਵਾ ਚੁਣਦਾ ਹੈ। ਵੱਖਰਾ pasta:--map-gw ਵਿਕਲਪ ਗੇਟਵੇ ਪਤੇ ਰਾਹੀਂ ਹੋਸਟ ਤੱਕ ਪਹੁੰਚਣ ਬਾਰੇ ਹੈ, ਜੋ ਦੂਜੀ ਵਿਵਸਥਾ ਹੈ।

Compose ਨਾਲ, ਅਸਲ ਪ੍ਰਦਾਤਾ ਅਤੇ ਬਣਾਈ ਗਈ ਨੈੱਟਵਰਕ ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਦੀ ਜਾਂਚ ਕਰੋ। ਨਾਮਿਤ ਬ੍ਰਿਜ ਨੈੱਟਵਰਕ ਆਪਣੇ ਆਪ pasta namespace ਨਹੀਂ ਹੁੰਦਾ, ਸਿਰਫ਼ ਇਸ ਲਈ ਕਿ ਇੱਕ ਸੁਤੰਤਰ podman run ਕਮਾਂਡ ਨੇ pasta ਸਫਲਤਾਪੂਰਵਕ ਵਰਤਿਆ। ਦੂਰਸਥ Podman ਇੰਜਣ ਵੀ “ਹੋਸਟ” ਨੂੰ ਇੰਜਣ ਦੀ ਥਾਂ ’ਤੇ ਰੱਖਦਾ ਹੈ।