ಪ್ರಾಕ್ಸಿ ಕಂಟೇನರ್ DNS ಕಂಟೇನರ್ ಅನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಏಕೆ ಬಳಸುವುದಿಲ್ಲ

ಒಂದೇ Docker ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಪ್ರಾಕ್ಸಿ ಮತ್ತು DNS ಸರ್ವರ್ ಚಲಾಯಿಸುವುದು ಅವುಗಳ DNS ಮಾರ್ಗಗಳನ್ನು ಸಂಪರ್ಕಿಸುವುದಿಲ್ಲ. ಮೂರು ಪ್ರತ್ಯೇಕ ಸಂಬಂಧಗಳು ಮುಖ್ಯ:

• ನೆಟ್‌ವರ್ಕ್ ತಲುಪುವಿಕೆ. ಪ್ರತ್ಯೇಕ Compose ಯೋಜನೆಗಳಿಗೆ ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರತ್ಯೇಕ ಡೀಫಾಲ್ಟ್ ನೆಟ್‌ವರ್ಕ್‌ಗಳಿರುತ್ತವೆ. ಸೇವೆಗಳನ್ನು ಸೂಕ್ತವಾದ ಹಂಚಿದ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಇರಿಸಿ, ಒಂದೇ ಯೋಜನೆಯ ಒಳಗೆ ಅಥವಾ ಯೋಜನೆಗಳ ನಡುವೆ ಸ್ಪಷ್ಟವಾಗಿ ಹಂಚಿದ ನೆಟ್‌ವರ್ಕ್ ಮೂಲಕ.
• ಸೇವೆ ಪತ್ತೆ. ಕಸ್ಟಮ್ Docker ನೆಟ್‌ವರ್ಕ್‌ನ ಒಳಗೊಂಡಿರುವ DNS ಕಂಟೇನರ್ ಹೆಸರುಗಳನ್ನು ಪರಿಹರಿಸಬಲ್ಲದು. ಇದು ಅನ್ವಯಕ್ಕೆ ನೆರೆಯದನ್ನು ಕಂಡುಕೊಳ್ಳಲು ಅವಕಾಶ ನೀಡುತ್ತದೆ; ಆದರೆ ಆ ನೆರೆಯನ್ನು ತನ್ನ DNS ರೆಸಾಲ್ವರ್ ಆಗಿ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಆಯ್ಕೆ ಮಾಡುವುದಿಲ್ಲ.
• ರೆಸಾಲ್ವರ್ ಆಯ್ಕೆ. ಪ್ರಾಕ್ಸಿ ಕಂಟೇನರ್ ಒಳಗೆ ಬಳಸುವ ರೆಸಾಲ್ವರ್ ಅನ್ನು ಗುರುತಿಸಿ. Compose ನ dns ಕ್ಷೇತ್ರವು DNS ಸರ್ವರ್ ವಿಳಾಸಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ. ಅನ್ವಯದಲ್ಲಿ ಪರಿಹರಿಸಲ್ಪಡುವ dns.local ನಂತಹ ಹೆಸರು ಅದನ್ನು ಆ ಕ್ಷೇತ್ರಕ್ಕೆ ಮಾನ್ಯ ಮೌಲ್ಯವಾಗಿಸುವುದಿಲ್ಲ.

ಪ್ರಶ್ನೆಯನ್ನು ಪ್ರಾಕ್ಸಿ ಕಂಟೇನರ್‌ನಿಂದ ಅದರ ಸಂರಚಿತ ರೆಸಾಲ್ವರ್ ವಿಳಾಸದವರೆಗೆ ಅನುಸರಿಸಿ. ಆ ವಿಳಾಸದಲ್ಲಿ ಮಾರ್ಗ ಮತ್ತು DNS ಶ್ರೋತೃವಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ಹೋಸ್ಟ್ ಪೋರ್ಟ್ 53 ಪ್ರಕಟಿಸುವುದು ಹೋಸ್ಟ್ ಬದಿಯಲ್ಲಿ ಪ್ರವೇಶ ಮಾರ್ಗವನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ; ಆದರೆ ಅದನ್ನು ಬಳಸಲು ಕಂಟೇನರ್‌ಗಳಿಗೆ ಹೇಳುವುದಿಲ್ಲ. ನೆಟ್‌ವರ್ಕ್ ಹಂಚಿಕೊಳ್ಳುವ ಕಂಟೇನರ್‌ಗಳು ಬದಲಾಗಿ ನೇರವಾಗಿ ಸಂವಹನ ಮಾಡಬಹುದು.

ಸಂರಚನೆಯು DNS ಕಂಟೇನರ್‌ನ ವಿಳಾಸವನ್ನು ಉಲ್ಲೇಖಿಸಿದರೆ, ಹೊಂದಾಣಿಕೆಯ IPAM ಸಂರಚನೆಯ ಅಡಿಯಲ್ಲಿ ಅದನ್ನು ಸ್ಥಿರವಾಗಿರಿಸಿ. ನಿನ್ನೆಯ ಕಂಟೇನರ್‌ನಿಂದ ನಕಲಿಸಿದ ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಹಂಚಿದ ವಿಳಾಸವು ಮರುಸೃಷ್ಟಿಯಲ್ಲಿ ವಿಫಲವಾಗಬಹುದು. ರೆಸಾಲ್ವರ್‌ನ ಮೇಲ್ಮುಖ ಮಾರ್ಗವನ್ನೂ ಪರಿಶೀಲಿಸಿ: ಉತ್ತರಿಸದ ಪ್ರಶ್ನೆಗಳನ್ನು ಅದಕ್ಕೇ ಹಿಂತಿರುಗಿಸುವುದು ತಲುಪಲಾಗದ ರೆಸಾಲ್ವರ್‌ಗಿಂತ ಬೇರೆ ವೈಫಲ್ಯವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.

ಕೊನೆಯದಾಗಿ, ಗಮ್ಯವನ್ನು ಯಾರು ಪರಿಹರಿಸುತ್ತಾರೆ ಎಂದು ಗುರುತಿಸಿ. CONNECT ಹೆಸರನ್ನು ಪರಿಹರಿಸುವ HTTP ಪ್ರಾಕ್ಸಿ ಈ ಕಂಟೇನರ್ ಮಾರ್ಗವನ್ನು ಬಳಸಬಹುದು; ಸ್ಥಳೀಯವಾಗಿ ಪರಿಹರಿಸುವ SOCKS ಕ್ಲೈಂಟ್ ಬಳಸದೇ ಇರಬಹುದು. ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಮಾಡಿದ ಹುಡುಕಾಟವು ಹೋಸ್ಟ್‌ನ ಮಾರ್ಗವನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಪ್ರಾಕ್ಸಿ ಪ್ರಕ್ರಿಯೆಯದನ್ನು ಅಲ್ಲ.