ಹೋಸ್ಟ್‌ನ 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 ಎಂಜಿನ್ ಕೂಡ “ಹೋಸ್ಟ್” ಅನ್ನು ಎಂಜಿನ್‌ನ ಸ್ಥಳದಲ್ಲಿ ಇಡುತ್ತದೆ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು