ہوسٹ کا 127.0.0.1:8118 اور کنٹینر کا 127.0.0.1:8118 عام طور پر الگ لوپ بیک اینڈ پوائنٹس ہوتے ہیں۔ rootless کنٹینر میں پراکسی متغیر بھیجنا ان لوپ بیک انٹرفیسز کو نہیں جوڑتا۔

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

ایپلی کیشن کی موجودہ image اور command استعمال کریں۔ مثال فرض کرتی ہے کہ ہوسٹ کی طرف پورٹ 8118 پر HTTP پراکسی کام کر رہی ہے اور دکھایا گیا فارورڈنگ آپشن سپورٹ کرنے والا Podman/pasta ورژن موجود ہے۔

pasta کا بڑا -T ہدف namespace سے ہوسٹ namespace کی طرف فارورڈ کرتا ہے۔ چھوٹا -t اور Podman کا --publish مخالف سمت میں ہیں۔ اس لیے کنٹینر پورٹ 8118 شائع کرنا بذات خود ہوسٹ کی پراکسی کو کنٹینر کے لیے دستیاب نہیں کرتا۔

Podman بطور ڈیفالٹ namespace سے ہوسٹ تک خودکار پورٹ فارورڈنگ بند رکھتا ہے؛ واضح پورٹ یہاں مطلوبہ سروس منتخب کرتا ہے۔ الگ pasta:--map-gw آپشن گیٹ وے ایڈریس کے ذریعے ہوسٹ تک پہنچنے سے متعلق ہے، جو دوسرا انتظام ہے۔

Compose کے ساتھ، اصل فراہم کنندہ اور تیار کردہ نیٹ ورک کنفیگریشن کا معائنہ کریں۔ نامزد برج نیٹ ورک خود بخود pasta namespace نہیں بنتا صرف اس لیے کہ ایک آزاد podman run کمانڈ نے pasta کامیابی سے استعمال کیا۔ دور دراز Podman انجن بھی «ہوسٹ» کو انجن کے مقام پر رکھتا ہے۔

متعلقہ مضامین