ஹோஸ்ட்டின் 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-to-host போர்ட் தானியங்கி ஃபார்வேர்டிங்கை முடக்குகிறது; வெளிப்படையான போர்ட் இங்குத் தேவையான சேவையைத் தேர்ந்தெடுக்கிறது. தனி pasta:--map-gw விருப்பம் கேட்வே முகவரி வழியாக ஹோஸ்ட்டை அடைவதைப் பற்றியது, அது வேறு ஏற்பாடு.

Compose உடன், உண்மையான வழங்குநர் மற்றும் உருவாக்கப்பட்ட நெட்வொர்க் உள்ளமைவைச் சரிபாருங்கள். பெயரிடப்பட்ட பிரிட்ஜ் நெட்வொர்க் தானாக pasta namespace ஆகாது, ஒரு சுயாதீன podman run கட்டளை pasta ஐ வெற்றிகரமாகப் பயன்படுத்தியதால் மட்டும். தொலை Podman இயந்திரமும் “ஹோஸ்ட்டை” இயந்திரத்தின் இடத்தில் வைக்கிறது.

தொடர்புடைய கட்டுரைகள்