Docker: ಒಂದು ಕಂಟೇನರ್ ಅನ್ನು VPN ಮೂಲಕ ಕಳುಹಿಸಿ, ಇನ್ನೊಂದನ್ನು ನೇರವಾಗಿ ಇರಿಸಿ
ಸುರಂಗಕ್ಕೆ ಅದರದೇ ಆದ ಕಂಟೇನರ್ ನೀಡಿ, ಅದು ಬೇಕಾದ ಸೇವೆಗಳಿಗೆ ಮಾತ್ರ ಆ ನೇಮ್ಸ್ಪೇಸ್ ಹಂಚಿಕೊಳ್ಳಲು ಬಿಡಿ, ನಂತರ ಮಾಲೀಕನ ನಂತರ ಬರುವುದನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಿ: ಪೋರ್ಟ್ಗಳು, localhost, DNS.
ಒಂದು ಹೋಸ್ಟ್, ಎರಡು ವರ್ಕ್ಲೋಡ್ಗಳು ಮತ್ತು ಅವುಗಳನ್ನು ಬೇರ್ಪಡಿಸುವ ಅಗತ್ಯ: ವಾಣಿಜ್ಯ VPN ನಿಂದ ಹೊರಬರಬೇಕಾದ ಡೌನ್ಲೋಡ್ ಕ್ಲೈಂಟ್, ಮತ್ತು ಹೋಸ್ಟ್ನ ಸಂಪರ್ಕವನ್ನು ಬಳಸುವುದನ್ನು ಮುಂದುವರಿಸಬೇಕಾದ ನಿರ್ವಹಣಾ ಇಂಟರ್ಫೇಸ್. VPN ಕ್ಲೈಂಟ್ ಅನ್ನು ಹೋಸ್ಟ್ನಲ್ಲಿ ಸ್ಥಾಪಿಸಿದರೆ ಅಗತ್ಯವು ತಕ್ಷಣ ವಿಫಲವಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಆಗ ಎರಡೂ ವರ್ಕ್ಲೋಡ್ಗಳು ಒಂದೇ ನಿರ್ಗಮನವನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತವೆ. ನಿಜವಾಗಿ ಕೆಲಸ ಮಾಡುವ ಮಾದರಿ ಎಂದರೆ ಸುರಂಗವನ್ನು ಅದರದೇ ಕಂಟೇನರ್ಗೆ ಸ್ಥಳಾಂತರಿಸುವುದು ಮತ್ತು ಅದು ಬೇಕಾದ ವರ್ಕ್ಲೋಡ್ಗಳಿಗೆ ಮಾತ್ರ ಆ ಕಂಟೇನರ್ನ ನೆಟ್ವರ್ಕ್ ನೇಮ್ಸ್ಪೇಸ್ಗೆ ಸೇರಲು ಅನುಮತಿಸುವುದು. ಉಳಿದೆಲ್ಲವೂ ಸಾಮಾನ್ಯ Docker ಮಾರ್ಗವನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಮುಂದಿನ ವಿವರಗಳು ನೇಮ್ಸ್ಪೇಸ್ ಯಾರಿಗೆ ಸೇರಿದೆ ಎಂಬುದರ ಪರಿಣಾಮಗಳು.
ಹಂಚಿದ ನೇಮ್ಸ್ಪೇಸ್ ನಿಯಮಗಳನ್ನು ಏಕೆ ಬದಲಿಸುತ್ತದೆ
ಇನ್ನೊಂದರ ನೇಮ್ಸ್ಪೇಸ್ಗೆ ಸೇರುವ ಕಂಟೇನರ್ ತನ್ನದೇ ನೆಟ್ವರ್ಕ್ ಸ್ಟ್ಯಾಕ್ ಪಡೆಯುವುದಿಲ್ಲ. ಅದು ಸೇರಿದ ಕಂಟೇನರ್ನಂತೆಯೇ ಅದೇ ಇಂಟರ್ಫೇಸ್ಗಳು, ಅದೇ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕ ಮತ್ತು ಅದೇ loopback ಅನ್ನು ನೋಡುತ್ತದೆ, ಮತ್ತು ಅದಕ್ಕಾಗಿಯೇ ಈ ಮಾದರಿ ಉಪಯುಕ್ತ: ವರ್ಕ್ಲೋಡ್ ಸಾಮಾನ್ಯವಾಗಿ ಪರಿಹರಿಸಿ ಸಂಪರ್ಕಿಸುತ್ತದೆ, ಮತ್ತು ಕೆಳಗಿನ ಸುರಂಗ ಅಪ್ಲಿಕೇಶನ್ಗೆ ತಿಳಿಯದೆ ಸಂಚಾರವನ್ನು ಹಿಡಿಯುತ್ತದೆ. ಬೆಲೆ ಎಂದರೆ ಪ್ರತಿ ನೆಟ್ವರ್ಕ್ ಸಂಬಂಧಿ ಸೆಟ್ಟಿಂಗ್ಗೆ ಈಗ ಒಬ್ಬನೇ ಮಾಲೀಕ, ಮತ್ತು ಸೇರುವ ಕಂಟೇನರ್ ಅಲ್ಲ.
ಈ ಮಾಲೀಕತ್ವದ ನಿಯಮವು ಹೆಚ್ಚಿನ ಕಾನ್ಫಿಗರೇಶನ್ ಪ್ರಶ್ನೆಗಳಿಗೆ ಅವು ಕೇಳುವ ಮೊದಲೇ ಉತ್ತರಿಸುತ್ತದೆ. ಸೆಟ್ಟಿಂಗ್ ನೆಟ್ವರ್ಕ್ ಸ್ಟ್ಯಾಕ್ನಲ್ಲಿ ವಾಸಿಸಿದರೆ, ಅದು ಸೈಡ್ಕಾರ್ಗೆ ಸೇರಿದ್ದು. ಅದು ಪ್ರಕ್ರಿಯೆಯನ್ನು ವಿವರಿಸಿದರೆ, ಅದು ವರ್ಕ್ಲೋಡ್ ಜೊತೆ ಉಳಿಯುತ್ತದೆ.
loopback ಎಂಬುದು ಜನರನ್ನು ಬೆಚ್ಚಿಬೀಳಿಸುವ ಭಾಗ. ಸೇರುವ ಕಂಟೇನರ್ ಒಳಗೆ, localhost ಸೈಡ್ಕಾರ್ನ loopback ಗೆ ಪರಿಹಾರವಾಗುತ್ತದೆ, ತನ್ನದೇ ಖಾಸಗಿ ಒಂದಕ್ಕಲ್ಲ, ಹಾಗಾಗಿ 127.0.0.1 ಗೆ ಬಂಧಿಸಿ ಪ್ರತ್ಯೇಕತೆಯನ್ನು ನಿರೀಕ್ಷಿಸುವ ಸೇವೆ ಈಗ ಆ ವಿಳಾಸವನ್ನು ಸುರಂಗ ಕಂಟೇನರ್ ಜೊತೆ ಹಂಚಿಕೊಳ್ಳುತ್ತದೆ.
ನೇಮ್ಸ್ಪೇಸ್ ಹೊಂದಿರುವ ಕಂಟೇನರ್ನಲ್ಲಿ ಪೋರ್ಟ್ಗಳನ್ನು ಪ್ರಕಟಿಸಿ
ಪೋರ್ಟ್ ಮ್ಯಾಪಿಂಗ್ ನೇಮ್ಸ್ಪೇಸ್ ಮಾಲೀಕನದು, ಕೇಳುವ ಪ್ರಕ್ರಿಯೆ ಇನ್ನೊಂದು ಕಂಟೇನರ್ನಲ್ಲಿ ಓಡುತ್ತಿದ್ದರೂ ಸಹ. ಮ್ಯಾಪಿಂಗ್ ಅನ್ನು ಸೈಡ್ಕಾರ್ನಲ್ಲಿ ಘೋಷಿಸಿ, ಮತ್ತು ವರ್ಕ್ಲೋಡ್ ತನ್ನದೇ ಪ್ರಕ್ರಿಯೆ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಬದಲಾಗದೆ ಇಟ್ಟುಕೊಳ್ಳಲಿ. ಸೇರುವ ಸೇವೆಯ ಮೇಲಿನ ಮ್ಯಾಪಿಂಗ್ ಜಾರಿಗೆ ಬರಲಾರದು, ಎಂಜಿನ್ ಅದನ್ನು ತಿರಸ್ಕರಿಸಿದರೂ ಅಥವಾ ಕಂಟೇನರ್ ಹೇಗೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ ಸದ್ದಿಲ್ಲದೆ ನಿರ್ಲಕ್ಷಿಸಿದರೂ, ಮತ್ತು ಅದಕ್ಕಾಗಿಯೇ ಕ್ಷಣದ ಹಿಂದೆ ತಲುಪಬಹುದಾಗಿದ್ದ ಇಂಟರ್ಫೇಸ್ ಮಾದರಿ ಅನ್ವಯವಾದ ಕೂಡಲೇ ಮಾಯವಾಗುತ್ತದೆ.
services:
gluetun:
image: qmcgaw/gluetun
cap_add: [NET_ADMIN]
ports: ["8080:8080"]
client-vpn:
image: example/client
network_mode: "service:gluetun"
client-direct:
image: example/client
ports: ["8081:8080"]ಈ ಬ್ಲಾಕ್ ಅನ್ನು ಮೂರು ಸೇವೆಗಳಲ್ಲ, ಮೂರು ನಿರ್ಧಾರಗಳಾಗಿ ಓದಿ. ಸೈಡ್ಕಾರ್ ಸುರಂಗ ಮತ್ತು ಪ್ರಕಟಿತ ಪೋರ್ಟ್ ಹೊಂದಿದೆ; ಸೇರುವ ಕ್ಲೈಂಟ್ ಯಾವುದೇ ನೆಟ್ವರ್ಕ್ ಘೋಷಿಸುವುದಿಲ್ಲ; ನೇರ ಕ್ಲೈಂಟ್ ಡಿಫಾಲ್ಟ್ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ತನ್ನದೇ ಮ್ಯಾಪಿಂಗ್ ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ. ಸಾಮರ್ಥ್ಯ NET_ADMIN ಸೈಡ್ಕಾರ್ಗೆ ಇಂಟರ್ಫೇಸ್ಗಳನ್ನು ರಚಿಸಲು ಮತ್ತು ಮಾರ್ಗಗಳನ್ನು ಬದಲಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ, ಮತ್ತು ಅದಕ್ಕಾಗಿಯೇ ಈ ಕಂಟೇನರ್ ತಾನು ಸೇವೆ ಸಲ್ಲಿಸುವ ವರ್ಕ್ಲೋಡ್ಗಳಿಗಿಂತ ಹೆಚ್ಚು ಸವಲತ್ತುಗಳನ್ನು ಬೇಡುತ್ತದೆ.
ನೇರವಾಗಿ ಉಳಿಯುವ ಸೇವೆ ತನ್ನದೇ ನೆಟ್ವರ್ಕ್ ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ
ಸುರಂಗದ ಮೂಲಕ ಹೋಗಬಾರದ ವರ್ಕ್ಲೋಡ್ ಡಿಫಾಲ್ಟ್ ಬ್ರಿಡ್ಜ್ ಅಥವಾ ತನ್ನದೇ ಬಳಕೆದಾರ-ವ್ಯಾಖ್ಯಾನಿತ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ತನ್ನದೇ ಪ್ರಕಟಿತ ಪೋರ್ಟ್ ಮತ್ತು ತನ್ನದೇ ನಿರ್ಗಮನದೊಂದಿಗೆ ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ. ಎರಡೂ ಕಂಟೇನರ್ಗಳು ಹೆಸರಿನಿಂದ ಮಾತನಾಡಲು ಅದನ್ನು ಸೈಡ್ಕಾರ್ ನೆಟ್ವರ್ಕ್ಗೆ ಜೋಡಿಸುವುದು ಪ್ರಲೋಭನೆಯಾಗಿದೆ, ಆದರೆ ಆ ಒಂದೇ ಹೆಜ್ಜೆ ಅದರ ಸಂಚಾರವನ್ನು ಸದ್ದಿಲ್ಲದೆ ಸುರಂಗಕ್ಕೆ ಸ್ಥಳಾಂತರಿಸುತ್ತದೆ. ಅವು ಒಂದನ್ನೊಂದು ತಲುಪಬೇಕಿದ್ದರೆ, ಪ್ರತ್ಯೇಕ ಬಳಕೆದಾರ-ವ್ಯಾಖ್ಯಾನಿತ ನೆಟ್ವರ್ಕ್ ನಿರ್ಮಿಸಿ, ಎರಡನ್ನೂ ಅದಕ್ಕೆ ಜೋಡಿಸಿ, ಮತ್ತು ಸೈಡ್ಕಾರ್ ಅನ್ನು ಹೊರಹೋಗುವ ಏಕೈಕ ಮಾರ್ಗವಾಗಿ ಬಿಡಿ.
ಎರಡು ಪ್ರಶ್ನೆಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ: ಯಾವ ಕಂಟೇನರ್ಗಳು ಒಂದನ್ನೊಂದು ತಲುಪಬಲ್ಲವು, ಮತ್ತು ಯಾವುದು ಎಲ್ಲಿಂದ ಹೊರಹೋಗುತ್ತದೆ. ಅವುಗಳನ್ನು ವಿಲೀನ ಮಾಡುವುದೇ ಈ ವಿನ್ಯಾಸ ಮತ್ತೆ ಇಡೀ ಹೋಸ್ಟ್-ವ್ಯಾಪಿ VPN ಆಗುವ ಸಾಮಾನ್ಯ ದಾರಿ.
ಮೊದಲ ಗಂಟೆಗೆ ವೈಫಲ್ಯ ಮ್ಯಾಟ್ರಿಕ್ಸ್
ಹೆಚ್ಚಿನ ಮೊದಲ ಪ್ರಯತ್ನಗಳು ನಾಲ್ಕರಲ್ಲಿ ಒಂದು ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ, ಮತ್ತು ಪ್ರತಿಯೊಂದಕ್ಕೂ ಬೇರೆ ಕಾರಣವಿದೆ. ಅವುಗಳನ್ನು ಈ ಕ್ರಮದಲ್ಲಿ ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಮೊದಲ ಎರಡು ಬಹುತೇಕ ಎಲ್ಲ ವರದಿಗಳನ್ನು ವಿವರಿಸುತ್ತವೆ.
| Symptom | Likely cause |
|---|---|
| Web UI unreachable after the change | Port mapping declared on the joining container instead of the sidecar |
| Both containers show the provider's exit address | The direct service was attached to the sidecar network |
| Internal names stop resolving | Resolver settings live on the host, not in the shared namespace |
| Health check fails but the app works | The check probes localhost, which now means the sidecar |
ನಾಲ್ಕನೇ ಸಾಲು ಜನರು ತಪ್ಪಾಗಿ ಅಪ್ಲಿಕೇಶನ್ ದೋಷ ಎಂದು ನಿರ್ಣಯಿಸುವ ಸಾಲು. ವರ್ಕ್ಲೋಡ್ನ ತನ್ನದೇ loopback ವಿರುದ್ಧ ಬರೆದ ಪರೀಕ್ಷೆ ಈಗ ಸುರಂಗ ಕಂಟೇನರ್ ಅನ್ನು ಪರೀಕ್ಷಿಸುತ್ತಿದೆ, ಹಾಗಾಗಿ ಅದು ವಿಫಲವಾಗುತ್ತದೆ ಅಥವಾ ಸಂಪೂರ್ಣ ತಪ್ಪು ಸೇವೆಯನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ.
ಒಂದೇ ಹೋಸ್ಟ್ಹೆಸರಿಗೆ ಸುರಂಗ ಬೇಕಾದಾಗ
ಕೆಲವೊಮ್ಮೆ ಪೂರ್ಣ ಸುರಂಗ ತುಂಬಾ ಹೆಚ್ಚು: ಒಂದು ಆಂತರಿಕ ಹೆಸರು ಕಾರ್ಪೊರೇಟ್ VPN ಮೂಲಕ ಹೋಗಬೇಕು, ಆದರೆ ಸ್ಥಳೀಯ ಸಾಕೆಟ್ ಅಥವಾ ಡಿಸ್ಪ್ಲೇ ಸಂಪರ್ಕ ಕೆಲಸ ಮುಂದುವರಿಸುತ್ತದೆ. ಕಂಟೇನರ್ ಒಳಗಿನ ಪೂರ್ಣ ಸುರಂಗ ಆ ಮಾರ್ಗವನ್ನೂ ಹೋಸ್ಟ್ಗೆ ಉದ್ದೇಶಿಸಿದ ಎಲ್ಲವನ್ನೂ ಮುರಿಯುತ್ತದೆ, ಹಾಗಾಗಿ ಬೇಕಾದ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಮಾತ್ರ ರೂಟ್ ಮಾಡಿ. ಕ್ಲೈಂಟ್ ಸುತ್ತಲಿನ ವಿಭಜಿತ ರೂಟಿಂಗ್ ರ್ಯಾಪರ್ ಅದನ್ನು ಮಾಡುತ್ತದೆ, ಹೆಸರಿಸಿದ ಹೋಸ್ಟ್ ಅನ್ನು ಸುರಂಗದ ಮೂಲಕ ಕಳುಹಿಸಿ ಉಳಿದೆಲ್ಲಕ್ಕೂ ಹಿಂದಿನ ಮಾರ್ಗವನ್ನು ಬದಲಾಗದೆ ಬಿಡುತ್ತದೆ.
ನೀವು ಒಂದೇ ಸೇವೆಯನ್ನು ತಲುಪಬೇಕಾದರೆ ಮತ್ತು ಕಂಟೇನರ್ನ ಎಲ್ಲ ಸಂಚಾರವನ್ನು ಸ್ಥಳಾಂತರಿಸಲು ಪ್ರಯತ್ನಿಸದಿದ್ದರೆ ಇದನ್ನು ಆರಿಸಿ. ಇದು ಸೈಡ್ಕಾರ್ಗಿಂತ ಬೇರೆ ಸಾಧನ ಮತ್ತು ಬೇರೆ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ.
ಪರಿಶೀಲಿಸಿ, ನಂತರ ಅದನ್ನು ಮರುಪ್ರಾರಂಭಕ್ಕೆ ಒಡ್ಡಿಕೊಳ್ಳದಂತೆ ಮಾಡಿ
ಪ್ರತಿ ಕಂಟೇನರ್ಗೆ ಅದು ಯಾವ ವಿಳಾಸದಿಂದ ಬರುತ್ತಿರುವಂತೆ ಕಾಣುತ್ತದೆ ಎಂದು ಕೇಳಿ. ಸುರಂಗದಲ್ಲಿರುವುದು ಪೂರೈಕೆದಾರರ ವಿಳಾಸವನ್ನು ಮುದ್ರಿಸಬೇಕು ಮತ್ತು ನೇರವಾದದ್ದು ಹೋಸ್ಟ್ನ ನಿರ್ಗಮನವನ್ನು. ಒಂದೇ ರೀತಿಯ ಉತ್ತರಗಳೆಂದರೆ ನೇರ ಸೇವೆ ತಪ್ಪು ನೇಮ್ಸ್ಪೇಸ್ ಅನ್ನು ವಾರಸುದಾರರಾಗಿ ಪಡೆದಿದೆ ಅಥವಾ ಹೋಸ್ಟ್-ಮಟ್ಟದ VPN ಇನ್ನೂ ಎಲ್ಲವನ್ನೂ ಹಿಡಿಯುತ್ತಿದೆ, ಮತ್ತು ಆ ಎರಡು ಸರಿಪಡಿಸುವಿಕೆಗಳು ಬೇರೆ. ಪ್ರತಿ compose ಸಂಪಾದನೆಯ ನಂತರ ಪರಿಶೀಲನೆಯನ್ನು ಮತ್ತೆ ಚಲಾಯಿಸಿ, ಏಕೆಂದರೆ ಒಂದು ನಕಲಿಸಿದ ಸೇವಾ ಬ್ಲಾಕ್ ಸಮಸ್ಯೆಯನ್ನು ಮರಳಿ ತರಲು ಸಾಕು.
ಮೂರು ವಿಷಯಗಳು ನಂತರ ಮುರಿಯುವ ಪ್ರವೃತ್ತಿ ಹೊಂದಿವೆ. DNS ನೇಮ್ಸ್ಪೇಸ್ ಮಾಲೀಕನನ್ನು ಅನುಸರಿಸುತ್ತದೆ, ಹಾಗಾಗಿ ರಿಜಾಲ್ವರ್ ಮತ್ತು ಹುಡುಕಾಟ ಡೊಮೇನ್ ಸೆಟ್ಟಿಂಗ್ಗಳು ಹೋಸ್ಟ್ನಲ್ಲಿ ಅಲ್ಲ, ಸೈಡ್ಕಾರ್ನಲ್ಲಿ ಇರಬೇಕು. ಪೋರ್ಟ್-ಫಾರ್ವರ್ಡೆಡ್ VPN ಮರುಸಂಪರ್ಕದಲ್ಲಿ ತನ್ನ ಕೇಳುವ ಪೋರ್ಟ್ ಅನ್ನು ಬದಲಿಸುತ್ತದೆ, ಹಾಗಾಗಿ ಪೂರೈಕೆದಾರರ ಫಾರ್ವರ್ಡ್ ಮಾಡಿದ ಪೋರ್ಟ್ ಮತ್ತು ಕಂಟೇನರ್-ಬದಿಯ ಕೇಳುವ ಪೋರ್ಟ್ ಅನ್ನು ಕ್ಲೈಂಟ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅಥವಾ ಪೋರ್ಟ್ ಮ್ಯಾಪಿಂಗ್ಗೆ ಮತ್ತೆ ಬರೆಯಬೇಕು, ಸಾಮಾನ್ಯವಾಗಿ ಪೂರೈಕೆದಾರರ API ಓದುವ ಸಣ್ಣ ನವೀಕರಣಕಾರನಿಂದ. ಮತ್ತು localhost ವಿರುದ್ಧ ಬರೆದ ಯಾವುದೇ ಪರೀಕ್ಷೆ ಈಗ ವರ್ಕ್ಲೋಡ್ ಬದಲು ಸುರಂಗ ಕಂಟೇನರ್ ಅನ್ನು ಕೇಳುತ್ತದೆ.
ಮಾದರಿಯನ್ನು ಬರೆಯಿರಿ, ಯಾವ ಕಂಟೇನರ್ ನೇಮ್ಸ್ಪೇಸ್ ಹೊಂದಿದೆ ಮತ್ತು ಯಾವ ಪೋರ್ಟ್ಗಳು ಅದಕ್ಕೆ ಸೇರಿವೆ ಎಂಬುದೂ ಸೇರಿದಂತೆ. ಮುಂದಿನ ವ್ಯಕ್ತಿ ಸೇವೆಯನ್ನು ಸೇರಿಸುತ್ತಾನೆ, ತಪ್ಪು ಬ್ಲಾಕ್ ನಕಲಿಸುತ್ತಾನೆ ಮತ್ತು ಈ ಲೇಖನದ ಮೊದಲ ವೈಫಲ್ಯವನ್ನು ಮರುಸೃಷ್ಟಿಸುತ್ತಾನೆ.