ನಿಮ್ಮ ಕಾರ್ಪೊರೇಟ್ ಪ್ರಾಕ್ಸಿ ಏಕೆ Compose ಸೇವಾ ಹೆಸರನ್ನು ಪರಿಹರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದೆ
HTTP ಕ್ಲೈಂಟ್ Docker ನ ಸೇವಾ-ಹೆಸರಿನ ಪರಿಹಾರವನ್ನು ಬಳಸುವ ಮೊದಲು ತನ್ನ ಸಂರಚಿತ ಪ್ರಾಕ್ಸಿಗೆ ಆಂತರಿಕ ಸೇವಾ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಬಹುದು. ಸರಿಯಾದ ಕ್ಲೈಂಟ್ಗೆ ಉದ್ದೇಶಪೂರ್ವಕ ಬೈಪಾಸ್ಗಳನ್ನು ಸೇರಿಸಿ.
ಅಪ್ಲಿಕೇಶನ್ ತನ್ನ ಕಾರ್ಪೊರೇಟ್ ಪ್ರಾಕ್ಸಿ ಮೂಲಕ ಇಂಟರ್ನೆಟ್ ತಲುಪುತ್ತದೆ, ಆದರೆ http://catalog:8080/ ವಿಫಲವಾಗುತ್ತದೆ ಮತ್ತು ಪ್ರಾಕ್ಸಿ “catalog” ಅನ್ನು ಪರಿಹರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಆ ವಿನಂತಿ ಬಹುಶಃ Docker ನ ಆಂತರಿಕ DNS ಅನ್ನು ಎಂದಿಗೂ ಬಳಸಿಲ್ಲ.
HTTP ಕ್ಲೈಂಟ್ ನೇರ ಸಂಪರ್ಕ ಮಾಡುವ ಮೊದಲು ತನ್ನ ಪ್ರಾಕ್ಸಿಯನ್ನು ಆಯ್ಕೆ ಮಾಡಬಹುದು. ನಂತರ ಬಾಹ್ಯ ಪ್ರಾಕ್ಸಿ, ಅರ್ಥವು Compose ನೆಟ್ವರ್ಕ್ನ ಒಳಗೆ ಮಾತ್ರ ಇರುವ ಹೆಸರನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ.
- ವಿನಂತಿಯಲ್ಲಿ ಹೋಸ್ಟ್ನಾಮ್ ಬಳಸಿ. Compose ಸೇವೆಗಳನ್ನು ಸೂಕ್ತ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಸೇವಾ ಹೆಸರಿನಿಂದ ಕಂಡುಹಿಡಿಯಬಹುದು. ಬದಲಾಗಬಹುದಾದ ಕಂಟೇನರ್ IP ಅನ್ನು ಹಾರ್ಡ್-ಕೋಡ್ ಮಾಡುವ ಬದಲು ಬಳಕೆದಾರ ಕ್ಲೈಂಟ್ನ ಬೆಂಬಲಿತ ಬೈಪಾಸ್ ಸಂರಚನೆಗೆ
catalogಸೇರಿಸಿ. - ಇರುವ ವಿನಾಯಿತಿಗಳನ್ನು ಸಂರಕ್ಷಿಸಿ. ಪರಿಸರ-ಅರಿವುಳ್ಳ ಕ್ಲೈಂಟ್ಗೆ, ಸಂಬಂಧಿತ ನಮೂದುಗಳನ್ನು ಸಂಸ್ಥೆಯ ಪಟ್ಟಿಯೊಂದಿಗೆ ವಿಲೀನಗೊಳಿಸಿ:
NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalogಚಿತ್ರದಲ್ಲಿನ ನಿಜವಾದ ಲೈಬ್ರರಿ ಅಥವಾ ಎಕ್ಸಿಕ್ಯೂಟೆಬಲ್ ಅನ್ನು ದೊಡ್ಡ/ಸಣ್ಣ ಅಕ್ಷರ ನಿರ್ವಹಣೆ, ಆವೃತ್ತಿ ಮತ್ತು ಹೊಂದಾಣಿಕೆ ವ್ಯಾಕರಣಕ್ಕಾಗಿ ಪರಿಶೀಲಿಸಿ. ಸಾರ್ವತ್ರಿಕ NO_PROXY ಪಾರ್ಸರ್ ಇಲ್ಲ. ಸಣ್ಣ ಚಿತ್ರದಲ್ಲಿ wget ಎಂಬ ಪ್ರೋಗ್ರಾಂ GNU Wget ನಂತೆ ವರ್ತಿಸಬೇಕಿಲ್ಲ.
ವಿನಂತಿ ನೇರ ರೂಟಿಂಗ್ ಆಯ್ಕೆ ಮಾಡಿದ ನಂತರ, ಕರೆದವರು ಮತ್ತು ಸೇವೆಯ ಹಂಚಿಕೆಯ ನೆಟ್ವರ್ಕ್, ಕೇಳುತ್ತಿರುವ ಸೇವೆ ಮತ್ತು ಕಂಟೇನರ್ ಪೋರ್ಟ್ ಪರಿಶೀಲಿಸಿ. ಪ್ರಕಟಿತ ಹೋಸ್ಟ್ ಪೋರ್ಟ್ ಇನ್ನೊಂದು ಎಂಡ್ಪಾಯಿಂಟ್. ಬೈಪಾಸ್ ಕಾಣೆಯಾದ ನೆಟ್ವರ್ಕ್ ಸಂಪರ್ಕವನ್ನು ಸೇರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ನೆಟ್ವರ್ಕ್ ಮರುಸೃಷ್ಟಿಸುವುದು ಬಾಹ್ಯ ಪ್ರಾಕ್ಸಿಗೆ ಖಾಸಗಿ Compose ಹೆಸರನ್ನು ಕಲಿಸಲು ಸಾಧ್ಯವಿಲ್ಲದಂತೆ.
ಉದ್ದೇಶಿತ ವಿಭಜನೆಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳಿ: ಆಂತರಿಕ ವಿನಂತಿಗಳು ತಮ್ಮ ಆಂತರಿಕ ಮಾರ್ಗವನ್ನು ಬಳಸುತ್ತವೆ; ಬಾಹ್ಯ ವಿನಂತಿಗಳು ಅನುಮೋದಿತ ಪ್ರಾಕ್ಸಿಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತವೆ. ಪ್ರಾಕ್ಸಿಯನ್ನು ಜಾಗತಿಕವಾಗಿ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು ಈ ಒಂದು ವೈಫಲ್ಯವನ್ನು ಮರೆಮಾಡಬಹುದು ಮತ್ತು ಮುಂದಿನ ಬಾಹ್ಯ ವಿನಂತಿಗೆ ಬೇಕಾದ ಮಾರ್ಗವನ್ನು ತೆಗೆದುಹಾಕಬಹುದು.