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 इंजन भी “होस्ट” को इंजन के स्थान पर रखता है।