VPN ಸಂಪರ್ಕವಾದ ನಂತರ Docker ವಾಲ್ಯೂಮ್ ಮೌಂಟ್ ವಿಫಲವಾಗುತ್ತದೆ: daemon ಪರಿಶೀಲಿಸಿ

ಈ ಸಮಸ್ಯೆಯ ಬಗ್ಗೆ ಬಹುತೇಕ ಪ್ರತಿಯೊಂದು ಬರಹವೂ ವಾಲ್ಯೂಮ್ ಅನ್ನು ದೂಷಿಸುತ್ತದೆ, ಮತ್ತು ಸರಿಪಡಿಸಲು ಇಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುವುದಕ್ಕೆ ಅದೇ ಕಾರಣ. ನಿಮ್ಮ ಬಳಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದ bind mount ಇತ್ತು, ಕಾರ್ಪೊರೇಟ್ VPN ಸಂಪರ್ಕಗೊಂಡಿತು, ಮತ್ತು docker compose up ಈಗ ಕಾಣೆಯಾದ source path, ಖಾಲಿ ಡೈರೆಕ್ಟರಿ, ಅಥವಾ ಎಂಜಿನ್ ರಚಿಸಲು ನಿರಾಕರಿಸುವ mount ನೊಂದಿಗೆ ವಿಫಲವಾಗುತ್ತದೆ. ನಾನು ಸ್ವಚ್ಛಗೊಳಿಸಿದ ಪರಿಸರಗಳಲ್ಲಿ Compose ಫೈಲ್ ಬದಲಾಗಿರಲಿಲ್ಲ ಮತ್ತು ಪಥ ಸರಿಯಾಗಿತ್ತು. ಬದಲಾದದ್ದು ಯಾವ daemon ಗೆ ವಿನಂತಿ ತಲುಪಿತು ಎಂಬುದು, ಮತ್ತು mount ದೋಷವು ಆ ವ್ಯತ್ಯಾಸ ಮೊದಲು ಕಾಣಿಸಿಕೊಂಡ ಮೊದಲ ಸ್ಥಳ ಮಾತ್ರ.

ವಾಲ್ಯೂಮ್ ಎಂದೂ ಚಲಿಸಲಿಲ್ಲ; ವಿನಂತಿ ಚಲಿಸಿತು

ಒಂದು -v /srv/app:/app ಫ್ಲ್ಯಾಗ್ ನಿಮ್ಮ shell ಮಾಡುವ ಡೈರೆಕ್ಟರಿ ನಕಲಲ್ಲ. ಕ್ಲೈಂಟ್ ಅದನ್ನು API ವಿನಂತಿಯಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ, ಮತ್ತು ಉತ್ತರಿಸುವ daemon /srv/app ಅನ್ನು ತನ್ನದೇ ಫೈಲ್‌ಸಿಸ್ಟಮ್ ವಿರುದ್ಧ ಪರಿಹರಿಸುತ್ತದೆ. ಎರಡೂ ಬದಿಗಳು ಒಂದೇ ಕರ್ನೆಲ್‌ನಲ್ಲಿ ಚಲಿಸಿದಾಗ, ಆ ಪಥವೇ ನಿಮ್ಮ ಫೈಲ್ ಮ್ಯಾನೇಜರ್‌ನಲ್ಲಿ ಕಾಣುವುದು. endpoint ಬದಲಾದಾಗ, ಅದೇ ಸ್ಟ್ರಿಂಗ್ ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್ ಡೈರೆಕ್ಟರಿ ಬಗ್ಗೆ ಎಂದೂ ಕೇಳದ ಯಂತ್ರದಲ್ಲಿ ಹುಡುಕಲಾಗುತ್ತದೆ, ಮತ್ತು daemon ಮೂಲವನ್ನು ಕಾಣೆಯಾಗಿದೆ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ ಅಥವಾ ಸದ್ದಿಲ್ಲದೆ ಅದರ ಜಾಗದಲ್ಲಿ ಖಾಲಿ ಡೈರೆಕ್ಟರಿ ರಚಿಸುತ್ತದೆ.

ಹೆಸರಿನ ವಾಲ್ಯೂಮ್ ಕೆಲಸ ಮಾಡುತ್ತಲೇ ಇರುವುದಕ್ಕೂ bind mount ಮಾಡದಿರುವುದಕ್ಕೂ ಇದೇ ಕಾರಣ. -v appdata:/app daemon ಒಡೆತನದ ಸಂಗ್ರಹಣೆಗೆ ಹೆಸರು ಕೊಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಯಾವುದೇ host path ನಿರ್ದಿಷ್ಟ ಸ್ಥಳದಲ್ಲಿ ಇರಬೇಕಿಲ್ಲ. ಒಂದು ಸೇವೆಯನ್ನು bind mount ನಿಂದ ಹೆಸರಿನ ವಾಲ್ಯೂಮ್‌ಗೆ ಬದಲಿಸುವುದರಿಂದ ದೋಷ ಮಾಯವಾದರೆ, ನೀವು ಸಮಸ್ಯೆಯನ್ನು ಸರಿಪಡಿಸಿಲ್ಲ. ಕ್ಲೈಂಟ್ ಮತ್ತು daemon ಪಥ ಯಾವ ಫೈಲ್‌ಸಿಸ್ಟಮ್‌ಗೆ ಸೇರುತ್ತದೆ ಎಂಬುದರಲ್ಲಿ ಒಪ್ಪುವುದಿಲ್ಲ ಎಂದು ನೀವು ಖಚಿತಪಡಿಸಿದ್ದೀರಿ, ಮತ್ತು ನಿಮಗೆ ಮತ್ತೆ ನಿಜವಾದ host ಡೈರೆಕ್ಟರಿ ಬೇಕಾದ ಕ್ಷಣ ಆ ಭಿನ್ನಾಭಿಪ್ರಾಯ ಮರಳುತ್ತದೆ.

ಮೌಂಟ್ ಮುಟ್ಟುವ ಮೊದಲು endpoint ಮುದ್ರಿಸಿ

ಹಲವು ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಕ್ಲೈಂಟ್ ಅನ್ನು endpoint ಗೆ ತೋರಿಸಬಹುದು, ಮತ್ತು ಅವು ಯಾವಾಗಲೂ ಒಪ್ಪುವುದಿಲ್ಲ: --context ಫ್ಲ್ಯಾಗ್, DOCKER_CONTEXT, DOCKER_HOST ಪ್ರಸ್ತುತ shell ನಲ್ಲಿ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ಉಳಿಸಿದ context. ಆದ್ಯತೆಯ ಬಗ್ಗೆ ಯೋಚಿಸುವ ಬದಲು, ಎಲ್ಲವನ್ನೂ ಮುದ್ರಿಸಿ ಮತ್ತು ಉತ್ತರಗಳನ್ನು ಹೋಲಿಸಿ.

docker context show
docker context ls
docker version
docker info --format "{{.Name}} {{.OperatingSystem}} {{.ServerVersion}}"

ಕ್ಲೈಂಟ್ ಕಾನ್ಫಿಗ್ ಇರುವುದು ~/.docker/config.json Linux ಮತ್ತು macOS ನಲ್ಲಿ, ಮತ್ತು %USERPROFILE%\.docker\config.json Windows ನಲ್ಲಿ, ಮತ್ತು ಪ್ರಸ್ತುತ ಟರ್ಮಿನಲ್‌ನಲ್ಲಿ export ಮಾಡಿದ ಮೌಲ್ಯವು ಉಳಿಸಿದ ಮೌಲ್ಯವನ್ನು ಆ ಅಧಿವೇಶನಕ್ಕೆ ಮಾತ್ರ ಮೀರುತ್ತದೆ. endpoint ಸ್ಥಳೀಯ socket ಬದಲು hostname ಆಗಿದ್ದರೆ, ಹೆಸರು ಪರಿಹಾರ ಮತ್ತು ಮಾರ್ಗಗಳು ಅದು ಎಲ್ಲಿ ಇಳಿಯುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ, ಮತ್ತು VPN ಕ್ಲೈಂಟ್ ಸರಿಯಾಗಿ ಅವನ್ನೇ ಮತ್ತೆ ಬರೆಯುತ್ತದೆ. ಮಾರ್ಗ ಸೇರಿಸುವ ಅಥವಾ resolver ಬದಲಿಸುವ tunnel ಒಂದು ಕಾಲದಲ್ಲಿ ಈ ಲ್ಯಾಪ್‌ಟಾಪ್ ಎಂದು ಅರ್ಥವಿದ್ದ ಹೆಸರನ್ನು ಕಾರ್ಪೊರೇಟ್ ನೆಟ್‌ವರ್ಕ್ ಒಳಗಿನ ವಿಳಾಸಕ್ಕೆ ಕಳುಹಿಸಬಹುದು.

ಕಾನ್ಫಿಗರೇಶನ್ ಬದಲು ಸ್ಥಿತಿಯನ್ನು ಹೋಲಿಸಿ. tunnel ಮುಚ್ಚಿದಾಗ docker ps -a ಮತ್ತು docker images ರನ್ ಮಾಡಿ, ನಂತರ tunnel ತೆರೆದಾಗ ಮತ್ತೊಮ್ಮೆ. ಬೇರೆ ಕಂಟೇನರ್ ಪಟ್ಟಿ ಯಾವುದೇ ಕಾನ್ಫಿಗ್ ಫೈಲ್‌ಗಿಂತ ಬಲವಾದ ಸಾಕ್ಷ್ಯ, ಏಕೆಂದರೆ ನಿಮ್ಮ ವಿನಂತಿಗೆ ಬೇರೆ daemon ಉತ್ತರಿಸಿತು ಎಂದು ತೋರಿಸುತ್ತದೆ.

ಪಥ ಅಲ್ಲಿ ಇದೆಯೇ ಎಂದು daemon ಅನ್ನು ಕೇಳಿ

ನೀವು ಯಾವ daemon ತಲುಪಿದಿರಿ ಎಂದು ತಿಳಿದ ನಂತರ, ಅದನ್ನು ಡೈರೆಕ್ಟರಿ ನೋಡಲು ಹೇಳಿ. --mount ರೂಪವು ಚಿಕ್ಕ ಫ್ಲ್ಯಾಗ್‌ಗಿಂತ ಸ್ಪಷ್ಟ ಸಂದೇಶದೊಂದಿಗೆ ವಿಫಲವಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಅದು ಕಂಟೇನರ್ ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು ಮೂಲವನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ:

docker run --rm --mount type=bind,source=/srv/app,target=/app alpine ls -la /app

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

ಇನ್ನೊಂದು ಪಥ ಸಂಪೂರ್ಣ ಬೇರೆಡೆ ಚಲಿಸುತ್ತದೆ: image ಎಳೆಯುವುದು daemon ನ ಕೆಲಸ, ಕ್ಲೈಂಟ್‌ನದಲ್ಲ. ಯಶಸ್ವಿ ಎಳೆಯುವಿಕೆ daemon registry ತಲುಪಬಲ್ಲದು ಎಂದು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಮತ್ತು ಕೆಲಸ ಮಾಡುವ bind mount ಪಥ ಪರಿಹಾರವಾಯಿತು ಎಂದು ಮಾತ್ರ. ಪ್ರತಿ ಪಥವನ್ನು ಅದು ನಿಜವಾಗಿ ಚಲಿಸುವಲ್ಲೇ ಪರೀಕ್ಷಿಸಿ, ಇಲ್ಲದಿದ್ದರೆ ತಪ್ಪಾದದ್ದಕ್ಕೆ ಮಧ್ಯಾಹ್ನ ಕಳೆಯುತ್ತೀರಿ.

ಇಂಟ್ರಾನೆಟ್ ಹೆಸರುಗಳು ಬೇರೆ ಕಾರಣಕ್ಕೆ ವಿಫಲವಾಗುತ್ತವೆ

ಅದೇ ವರದಿಯ ಎರಡನೇ ಅರ್ಧ ಸಾಮಾನ್ಯವಾಗಿ ಕಂಟೇನರ್ intranet.corp.exampleಗೆ ತಲುಪಲಾಗದಿರುವುದು. ಅದು ಪ್ರತ್ಯೇಕ ಕಾರ್ಯವಿಧಾನ, ಎರಡನೇ ವಾಲ್ಯೂಮ್ ಸಮಸ್ಯೆ ಅಲ್ಲ. ಕಂಟೇನರ್ ತನ್ನ /etc/resolv.conf ಅನ್ನು ಪ್ರಾರಂಭದಲ್ಲಿ ಪಡೆಯುತ್ತದೆ, ಅದು daemon resolver ಸೆಟ್ಟಿಂಗ್‌ಗಳಿಂದ ರಚನೆಯಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಕಂಟೇನರ್ ರಚಿಸಿದ ನಂತರ VPN ಸೇರಿಸಿದ DNS ಸರ್ವರ್ ಕಂಟೇನರ್ ಮತ್ತೆ ರಚನೆಯಾಗುವವರೆಗೆ ಅಲ್ಲಿ ಕಾಣಿಸುವುದಿಲ್ಲ.

ಬಳಕೆದಾರ-ವ್ಯಾಖ್ಯಾನಿತ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ Docker ನ ಒಳಗೊಂಡಿರುವ resolver ಬಾಹ್ಯ ಪ್ರಶ್ನೆಗಳನ್ನು host ನ ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ ಸರ್ವರ್‌ಗಳಿಗೆ ರವಾನಿಸುತ್ತದೆ, ಇದು VPN host resolver ಅನ್ನು ಮತ್ತೆ ಬರೆಯುವಾಗ ಸಹಾಯ ಮಾಡುತ್ತದೆ ಮತ್ತು split DNS ಆಂತರಿಕ ವಲಯವನ್ನು daemon ಇನ್ನು ಮುಂದೆ ನೋಡದ ಸರ್ವರ್‌ಗೆ ಕಳುಹಿಸಿದಾಗ ಹಾನಿ ಮಾಡುತ್ತದೆ. ಸಂಕುಚಿತ, ಸ್ಪಷ್ಟ ಮ್ಯಾಪಿಂಗ್ ಎಂದೂ ಬದಲಾಗದ ಹೆಸರುಗಳಿಗಾಗಿ ಈ ಚರ್ಚೆಯನ್ನು ತಪ್ಪಿಸುತ್ತದೆ:

services:
  web:
    extra_hosts:
      - "intranet.corp.example:10.20.30.40"

ಇದು ಕಂಟೇನರ್‌ನ hosts ಫೈಲ್‌ಗೆ ನಮೂದನ್ನು ಬರೆಯುತ್ತದೆ, ಆದ್ದರಿಂದ ಕಂಟೇನರ್ tunnel ಬಗ್ಗೆ ಏನನ್ನೂ ಕಲಿಯುವುದಿಲ್ಲ, ಮತ್ತು ವಿಳಾಸವನ್ನೂ ಸ್ಥಿರಗೊಳಿಸುತ್ತದೆ. ಆಂತರಿಕ host ಚಲಿಸಿದಾಗ, ಯಾರಾದರೂ Compose ಫೈಲ್ ಸಂಪಾದಿಸುವವರೆಗೆ ನಮೂದು ತಪ್ಪಾಗಿಯೇ ಇರುತ್ತದೆ. ಸ್ಥಿರ ಸಾಧನ ಅಥವಾ ಪಿನ್ ಮಾಡಿದ ಡೇಟಾಬೇಸ್‌ಗೆ ಇದನ್ನು ಬಳಸಿ, ಮತ್ತು ಚಲಿಸುವ ಹೆಸರುಗಳನ್ನು DNS ಗೆ ಬಿಡಿ.

ಮರುಸ್ಥಾಪನೆ ನಿಜವಾಗಿ ಏನನ್ನು ಬದಲಿಸುತ್ತದೆ

Docker Desktop ಅನ್ನು ಮರುಸ್ಥಾಪಿಸುವುದರಿಂದ VM, socket ಮತ್ತು context ಪಟ್ಟಿ ಮತ್ತೆ ರಚನೆಯಾಗುತ್ತವೆ, ಮತ್ತು ಮೌಂಟ್ ಮತ್ತೆ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಆ ಫಲಿತಾಂಶ ನಿಜವಾದದ್ದು ಮತ್ತು ಅದು ಏನನ್ನೂ ಕಲಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಮುಂದಿನ VPN ನವೀಕರಣದ ನಂತರ ಅದೇ ವೈಫಲ್ಯ ಮರಳುತ್ತದೆ. ಮರುಸ್ಥಾಪನೆ ಕ್ಲೈಂಟ್ ಬಳಸುತ್ತಿದ್ದ endpoint ಅನ್ನು ಬದಲಿಸಿತು; ಅದು ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್ ಹೆಸರಿಸುವ ಪಥವನ್ನು daemon ನಿಜವಾಗಿ ಓದುವ ಫೈಲ್‌ಸಿಸ್ಟಮ್‌ನೊಂದಿಗೆ ಹೊಂದಿಸಲಿಲ್ಲ.

ನನ್ನ ಕೆಲಸದ ಕ್ರಮ ಚಿಕ್ಕದು. ಕ್ಲೈಂಟ್ ಯಾವ endpoint ಬಳಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ಕಂಟೇನರ್ ಪಟ್ಟಿಗಳನ್ನು ಹೋಲಿಸಿ ಯಾವ daemon ಉತ್ತರಿಸಿತು ಎಂದು ಖಚಿತಪಡಿಸಿ. ಆ daemon ಗೆ source path ಪಟ್ಟಿ ಮಾಡಲು ಹೇಳಿ. ನಂತರವೇ ಮೌಂಟ್ ಸಂಪಾದಿಸಿ, hosts ನಮೂದು ಸೇರಿಸಿ, ಅಥವಾ ವಾಲ್ಯೂಮ್ ಪ್ರಕಾರ ಬದಲಿಸಿ. ನೀವು VPN ಮೇಲೆ ಕೆಲಸ ಮಾಡುವ ತಂಡಕ್ಕಾಗಿ Compose ಫೈಲ್ ನಿರ್ವಹಿಸುತ್ತಿದ್ದರೆ, daemon ಒಡೆತನದಲ್ಲಿರಬೇಕಾದ ಡೇಟಾಗೆ ಹೆಸರಿನ ವಾಲ್ಯೂಮ್‌ಗಳನ್ನು ಆದ್ಯತೆ ನೀಡಿ, ಇದರಿಂದ host path ಎಂದೂ ಒಪ್ಪಂದದ ಭಾಗವಾಗದಿರುತ್ತದೆ.