Podman pasta: రూట్లెస్ కంటైనర్ నుండి హోస్ట్ లూప్బ్యాక్ ప్రాక్సీని చేరుకోవడం
ఉన్న లూప్బ్యాక్ ప్రాక్సీ కోసం pasta యొక్క namespace-to-host TCP ఫార్వర్డింగ్ను ఉపయోగించి, దాన్ని కంటైనర్ పోర్ట్ ప్రచురణ నుండి వేరుగా ఉంచండి.
హోస్ట్ యొక్క 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 ఇంజిన్ కూడా “హోస్ట్”ను ఇంజిన్ స్థానంలో ఉంచుతుంది.