होस्टको 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

अनुप्रयोगको अवस्थित इमेज र आदेश प्रयोग गर्नुहोस्। उदाहरणले होस्ट पक्षमा पोर्ट 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 इन्जिनले पनि “होस्ट” लाई इन्जिनको स्थानमा राख्छ।

सम्बन्धित लेखहरू