Docker ನ pool ಓವರ್‌ಲ್ಯಾಪ್ ದೋಷ VPN ರೂಟ್‌ನ ಸಮಸ್ಯೆ ಅಲ್ಲ

Docker ಈ ವಿಳಾಸ ಸ್ಥಳದಲ್ಲಿ pool ಇನ್ನೊಂದರೊಂದಿಗೆ ಓವರ್‌ಲ್ಯಾಪ್ ಆಗುತ್ತದೆ ಎಂಬ ಸಂದೇಶದೊಂದಿಗೆ ಜಾಲವನ್ನು ರಚಿಸಲು ನಿರಾಕರಿಸುತ್ತದೆ, ಮತ್ತು VPN ರೂಟೇ ಕಾರಣವಾಗಿರಬೇಕು ಎಂದು ಯಾರೋ ನಿರ್ಧರಿಸುತ್ತಾರೆ. ಅದು ಸಾಧ್ಯವಿಲ್ಲ. ಆ ದೋಷ pool ಹಂಚಲ್ಪಡುವಾಗ, ಒಂದು ಪ್ಯಾಕೆಟ್ ಕೂಡ ಇರುವ ಮೊದಲು ಉಂಟಾಗುತ್ತದೆ, ಮತ್ತು ಕೈಯಿಂದ ಮಾಡಿದ ಕರ್ನೆಲ್ ರೂಟ್‌ಗೆ ಅದರ ಮೇಲೆ ಯಾವುದೇ ಪರಿಣಾಮವಿಲ್ಲ. VPN ಒಂದು ಹೆಜ್ಜೆ ನಂತರ ಮುಖ್ಯವಾಗುತ್ತದೆ, ಈಗಾಗಲೇ ವಿಳಾಸ ಹೊಂದಿರುವ ಕಂಟೇನರ್ ರೂಟ್ ಕಾಣಿಸಿಕೊಂಡ ನಂತರ ತಲುಪಲಾಗದಂತಾದಾಗ. ಎರಡು ಸಮಸ್ಯೆ, ಎರಡು ಸಾಕ್ಷ್ಯ ಸಮೂಹಗಳು, ಮತ್ತು ಅವನ್ನು ಬೆರೆಸುವುದು ಎರಡನ್ನೂ ಸರಿಪಡಿಸದ ಬದಲಾವಣೆಯನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.

ಒಂದೇ ರೀತಿ ಕಾಣುವ ಎರಡು ದೋಷಗಳು

ಹಂಚಿಕೆಯ ದೋಷ ಅಂಕಗಣಿತದ್ದು. Docker ನೀವು ಕೇಳಿದ ಉಪಜಾಲವನ್ನು ಅದು ಈಗಾಗಲೇ ನಿರ್ವಹಿಸುವ ಉಪಜಾಲಗಳೊಂದಿಗೆ ಹೋಲಿಸುತ್ತದೆ, ಛೇದನವನ್ನು ಕಂಡುಕೊಂಡು ನಿರಾಕರಿಸುತ್ತದೆ. ಇನ್ನೂ ಏನೂ ಚಲಿಸುತ್ತಿಲ್ಲ, ಆದ್ದರಿಂದ ರೂಟ್ ಇಲ್ಲ, ಕಂಟೇನರ್ ಇಲ್ಲ ಮತ್ತು ಪರಿಶೀಲಿಸಲು ಸಂಚಾರವಿಲ್ಲ.

ರನ್‌ಟೈಮ್ ಲಕ್ಷಣ ತಲುಪುವಿಕೆಯ ಪ್ರಶ್ನೆ. ನಿನ್ನೆ ಉತ್ತರಿಸಿದ ಕಂಟೇನರ್ ಈಗ ಉತ್ತರಿಸುತ್ತಿಲ್ಲ, ಮತ್ತು ಹೋಸ್ಟ್‌ನ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕದಲ್ಲಿ ಏನೋ ಬದಲಾಗಿದೆ. ಕಂಟೇನರ್ ಇನ್ನೂ ತನ್ನ ವಿಳಾಸವನ್ನು ಹೊಂದಿದೆ; ಪ್ರಶ್ನೆ ಎಂದರೆ ಆ ವಿಳಾಸ ಯಾವ ಮಾರ್ಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.

ಎರಡೂ ವಿಳಾಸ ಯೋಜನೆಯ ಸಮಸ್ಯೆಗಳು. ಅವುಗಳಲ್ಲಿ ಒಂದೇ Docker ನ ಸಮಸ್ಯೆ.

ಮೊದಲು ಹಂಚಿದ pool ಗಳನ್ನು ಓದಿ

ಜಾಲಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಿ ಮತ್ತು ಛೇದಿಸಬಹುದಾದವುಗಳನ್ನು ಪರಿಶೀಲಿಸಿ. ಉಪಜಾಲ IPAM ಸಂರಚನೆಯಲ್ಲಿದೆ, ಮತ್ತು ಸಂಪರ್ಕಿತ ಕಂಟೇನರ್‌ಗಳು ಪ್ರತ್ಯೇಕವಾಗಿ ಪಟ್ಟಿ ಮಾಡಲಾಗಿವೆ:

docker network ls
docker network inspect EXISTING_NETWORK

ಆ ಉಪಜಾಲವನ್ನು ಹೊಸ ಜಾಲ ಕೇಳುವ pool ನೊಂದಿಗೆ ಹೋಲಿಸಿ, ಮತ್ತು Compose ಪ್ರತಿ ಪ್ರಾಜೆಕ್ಟ್‌ಗೂ ತನ್ನದೇ ಡಿಫಾಲ್ಟ್ ಜಾಲವನ್ನು ರಚಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೆನಪಿಡಿ. ಮರೆತ ಪ್ರಾಜೆಕ್ಟ್‌ನೊಂದಿಗಿನ ಘರ್ಷಣೆ ಡೀಮನ್‌ನೊಂದಿಗಿನ ಘರ್ಷಣೆಯಂತೆಯೇ ಕಾಣುತ್ತದೆ.

ಸೇವೆಯ ಮೇಲಿನ ಸ್ಥಿರ ipv4_address ಒಂದು ಕಂಟೇನರ್‌ನ ವಿಳಾಸ, pool ನ ವ್ಯಾಖ್ಯಾನವಲ್ಲ. ಅದನ್ನು ಬದಲಿಸುವುದರಿಂದ ಓವರ್‌ಲ್ಯಾಪ್ ತೊಲಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಓವರ್‌ಲ್ಯಾಪ್ ಕಂಟೇನರ್‌ಗಳ ನಡುವೆ ಅಲ್ಲ, ಜಾಲದ ಉಪಜಾಲಗಳ ನಡುವೆ ಇರುತ್ತದೆ. Docker ನ network-create ಉಲ್ಲೇಖ ಸಾಮಾನ್ಯ ಬ್ರಿಡ್ಜ್ ಹಂಚಿಕೆಗೆ ಓವರ್‌ಲ್ಯಾಪ್ ಆಗದ ಉಪಜಾಲಗಳನ್ನು ಬೇಡುತ್ತದೆ ಮತ್ತು ಒಂದನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಆಯ್ಕೆ ಮಾಡುವ ಬಗೆಯನ್ನು ದಾಖಲಿಸುತ್ತದೆ.

VPN ಗೆ ಉಳಿಯುವ ಪ್ರಿಫಿಕ್ಸ್ ಆಯ್ಕೆಮಾಡಿ

ತಕ್ಷಣದ ಘರ್ಷಣೆ ಮತ್ತು ಭವಿಷ್ಯದ ರೂಟ್ ಒಂದೇ ಆಯ್ಕೆಯಿಂದ ನಿರ್ಧರಿಸಲ್ಪಡುತ್ತವೆ, ಆದ್ದರಿಂದ ಅದನ್ನು ಒಮ್ಮೆ ಮಾಡಿ. ಅಭ್ಯರ್ಥಿ ಶ್ರೇಣಿಯನ್ನು LAN, ಹೋಸ್ಟ್ ತಲುಪಬಹುದಾದ ಪ್ರತಿ VPN ಗಮ್ಯಸ್ಥಾನ ಮತ್ತು ಬಳಕೆಯಲ್ಲಿರುವ ಯಾವುದೇ ಇತರ overlay ನೊಂದಿಗೆ ಹೋಲಿಸಿ.

Docker ಅನ್ನು ತೃಪ್ತಿಪಡಿಸಿ ದೂರದ ಜಾಲದೊಂದಿಗೆ ಘರ್ಷಿಸುವ ಪ್ರಿಫಿಕ್ಸ್ ನಿಮಗೆ ಸ್ವಚ್ಛವಾಗಿ ಪ್ರಾರಂಭವಾಗಿ ಸುರಂಗ ಏರಿದ ಕ್ಷಣ ತಲುಪಲಾಗದಂತಾಗುವ ಕಂಟೇನರ್ ನೀಡುತ್ತದೆ. ಇದು ಈ ಲೇಖನದ ಎರಡನೇ ದೋಷ, ಮತ್ತು ಈಗ ತಪ್ಪಿಸುವುದಕ್ಕಿಂತ ನಂತರ ಅದನ್ನು ನಿದಾನ ಮಾಡುವುದು ಬಹಳ ಕಷ್ಟ.

ಆಯ್ದ ಶ್ರೇಣಿಗಳನ್ನು ಮುಂದಿನ ಪ್ರಾಜೆಕ್ಟ್ ಓದಬಹುದಾದ ಸ್ಥಳದಲ್ಲಿ ಬರೆಯಿರಿ. ಹಂಚಿದ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳ ಒಂದು ಸಾಲಿನ ನೋಂದಣಿ ವಿವರಣೆ ಇಲ್ಲದ ಒಂದು ವಾರದ ಟೈಮೌಟ್‌ಗಳಿಗಿಂತ ಅಗ್ಗ.

ಜಾಲವನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ನಿವೃತ್ತಿಗೊಳಿಸಿ ಅಥವಾ ಬದಲಿಸಿ

ಹೊಸ Compose ಜಾಲಕ್ಕೆ, ಜಾಲದ IPAM ಸಂರಚನೆಯಲ್ಲಿ ಬಳಸದ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಹೊಂದಿಸಿ. ಇರುವ ಪ್ರಾಜೆಕ್ಟ್‌ಗೆ, ಮರುಸಂಖ್ಯೀಕರಣವನ್ನು ಯೋಜಿಸಿ: ಸ್ಥಿರ ವಿಳಾಸಗಳು, ಅವಲಂಬಿತ ಸೇವೆಗಳು ಮತ್ತು ಜಾಲವನ್ನು ಮತ್ತೆ ರಚಿಸುವ ಹಂತ ಎಲ್ಲವನ್ನೂ ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕು, ಏಕೆಂದರೆ YAML ಸಂಪಾದಿಸುವುದು ಚಾಲ್ತಿಯಲ್ಲಿರುವ ಜಾಲವನ್ನು ಮರುಸಂಖ್ಯೀಕರಿಸುವುದಿಲ್ಲ.

ಹಳೆಯ ಜಾಲವು ಘರ್ಷಣೆಯ ಹಂಚಿಕೆಯನ್ನು ಹೊಂದಿದ್ದರೆ, ಅದನ್ನು ತೆಗೆಯುವ ಮೊದಲು ಯಾರು ಸಂಪರ್ಕಗೊಂಡಿದ್ದಾರೆ ಎಂದು ಪರಿಶೀಲಿಸಿ. docker network rm ಸಕ್ರಿಯ endpoint ಗಳು ಇರುವವರೆಗೆ ನಿರಾಕರಿಸುತ್ತದೆ, ಮತ್ತು docker stop ಜಾಲದ ಹೆಸರಿನ ಬದಲು ಕಂಟೇನರ್ ಹೆಸರುಗಳು ಅಥವಾ ID ಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಕಂಟೇನರ್ ನಿಲ್ಲಿಸುವುದು pool ಹಿಡಿದಿಟ್ಟುಕೊಂಡಿರುವ ಜಾಲದ ವ್ಯಾಖ್ಯಾನವನ್ನೂ ತೆಗೆಯುವುದಿಲ್ಲ.

ವಿಶಾಲ prune ನಿದಾನ ಸಾಧನವಲ್ಲ. ಅದು ಸಂಬಂಧವಿಲ್ಲದ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳನ್ನು ತಲುಪಿ ನೀವು ಸಂಗ್ರಹಿಸಲಿದ್ದ ಸಾಕ್ಷ್ಯವನ್ನು ನಾಶಮಾಡುತ್ತದೆ.

ಡಿಫಾಲ್ಟ್ pool ಗಳು ಮುಂದಿನ ಹಂಚಿಕೆಗೆ ಮಾತ್ರ ಸಹಾಯ ಮಾಡುತ್ತವೆ

ಡೀಮನ್‌ನ ಡಿಫಾಲ್ಟ್ ವಿಳಾಸ pool ಸೆಟ್ಟಿಂಗ್ ಭವಿಷ್ಯದ ಸ್ವಯಂಚಾಲಿತ ಹಂಚಿಕೆಗಳನ್ನು ನೀವು ಕಾಯ್ದಿರಿಸಿದ ಶ್ರೇಣಿಗಳ ಹೊರಗೆ ಇಡುವ ಮೂಲಕ ಸುಧಾರಿಸುತ್ತದೆ. ಅದು ಈಗಾಗಲೇ ಇರುವ ಜಾಲಗಳಿಗೆ ಹಿಂದಿನಿಂದ ಮರುವಿಳಾಸ ನೀಡುವುದಿಲ್ಲ, ಮತ್ತು ಇನ್ನೊಂದು ಸ್ಪಷ್ಟ ಉಪಜಾಲದೊಂದಿಗೆ ಓವರ್‌ಲ್ಯಾಪ್ ಆಗುವ ಸ್ಪಷ್ಟ ಉಪಜಾಲವನ್ನು ಪರಿಹರಿಸುವುದಿಲ್ಲ.

ಆ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ತನ್ನದೇ ಮರುಪ್ರಾರಂಭದೊಂದಿಗೆ ಪ್ರತ್ಯೇಕ, ಯೋಜಿತ ಬದಲಾವಣೆಯಾಗಿ ಪರಿಗಣಿಸಿ, ಒಂದು ಪ್ರಾಜೆಕ್ಟ್‌ನ ದುರಸ್ತಿಯ ಭಾಗವಾಗಿ ಅಲ್ಲ. ಎರಡನ್ನೂ ಬೆರೆಸುವುದು ಎಂದರೆ ಡೀಮನ್ ಮರುಪ್ರಾರಂಭ ಸಂಬಂಧವಿಲ್ಲದ ತನಿಖೆಯ ಮಧ್ಯದಲ್ಲಿ ಬೀಳುತ್ತದೆ. ಅದನ್ನು ತನ್ನದೇ ಕಿಟಕಿಯಲ್ಲಿ ನಿಗದಿಪಡಿಸಿ. ನಂತರ ಒಂದು ಹೊಸ ಸ್ವಯಂಚಾಲಿತ ಹಂಚಿಕೆ ನಿಜವಾಗಿಯೂ ನೀವು ಕಾಯ್ದಿರಿಸಿದ ಶ್ರೇಣಿಗಳ ಹೊರಗೆ ಬೀಳುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ.

ರಚನೆ ಯಶಸ್ವಿಯಾದ ನಂತರ, ನಿಜವಾಗಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಉಪಜಾಲವನ್ನು ಪರಿಶೀಲಿಸಿ ಮತ್ತು ನಂತರ VPN ಅನ್ನು ಅದರ ಉದ್ದೇಶಿತ ಸ್ಥಿತಿಯಲ್ಲಿ ಇಟ್ಟುಕೊಂಡು ಒಂದು ನಿಜವಾದ ಅಪ್ಲಿಕೇಶನ್ ವಿನಂತಿಯನ್ನು ಮಾಡಿ. pool ಮಾನ್ಯವಾಗಿದ್ದರೂ ಪ್ರವೇಶ ಇನ್ನೂ ವಿಫಲವಾದರೆ, ಉಳಿದ ಕೆಲಸ ರೂಟ್ ಆಯ್ಕೆ, ಫಿಲ್ಟರಿಂಗ್ ಮತ್ತು ಮರಳು ಮಾರ್ಗ. ಅದು ರನ್‌ಟೈಮ್ ತನಿಖೆ, ಮತ್ತು ಅದು ಹಂಚಿಕೆಯ ದೋಷವನ್ನು ಹಿಂದಿನಿಂದ ಅರ್ಥಹೀನಗೊಳಿಸುವುದಿಲ್ಲ.

ಕೆಲಸದ ಕ್ರಮ: ಹಂಚಿದ pool ಗಳನ್ನು ಓದಿ, Docker ಮತ್ತು VPN ಗಮ್ಯಸ್ಥಾನಗಳೆರಡನ್ನೂ ತಪ್ಪಿಸುವ ಪ್ರಿಫಿಕ್ಸ್ ಆಯ್ಕೆಮಾಡಿ, ಜಾಲವನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಮತ್ತೆ ರಚಿಸಿ, ನಂತರ ಸುರಂಗ ಏರಿಸಿದ ಸ್ಥಿತಿಯಲ್ಲಿ ಒಂದು ವಿನಂತಿಯನ್ನು ಪರೀಕ್ಷಿಸಿ.