ಟರ್ಮಿನಲ್‌ನಲ್ಲಿ ಡೌನ್‌ಲೋಡ್‌ಗಳು ಕೆಲಸ ಮಾಡುತ್ತವೆ, ಆದರೆ VPN‌ನಲ್ಲಿ VS Code ವಿಸ್ತರಣೆಗಳು ವಿಫಲವಾಗುತ್ತವೆ

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

ಎರಡು ಪರಿಸರಗಳು ಸಾಮಾನ್ಯವಾಗಿ ನಿಖರವಾಗಿ ಒಂದು ಅಂಶದಲ್ಲಿ ಭಿನ್ನವಾಗಿರುತ್ತವೆ. ಆ ಅಂಶವನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಪ್ರಾಕ್ಸಿ ದಾಖಲೆಗಳನ್ನು ಎರಡು ಬಾರಿ ಓದುವುದಕ್ಕಿಂತ ವೇಗವಾಗಿದೆ.

ಯಾವ ಪ್ರಕ್ರಿಯೆ ವಿಫಲ ವಿನಂತಿ ಮಾಡಿತು

ಒಂದೇ ಸ್ಥಾಪನೆಯಲ್ಲಿ ಮೂರು ವಿನಂತಿಗಳು ವಿಫಲವಾಗಬಹುದು, ಮತ್ತು ಪ್ರತಿಯೊಂದಕ್ಕೂ ತನ್ನದೇ ನೆಟ್‌ವರ್ಕ್ ಗುರುತು ಇರುತ್ತದೆ. ಎಡಿಟರ್ Marketplace ಬಳಿ ಮೆಟಾಡೇಟಾ ಮತ್ತು ಪ್ಯಾಕೇಜ್ URL ಕೇಳುತ್ತದೆ, ನಂತರ ಪ್ಯಾಕೇಜ್ ಡೌನ್‌ಲೋಡ್ ಮಾಡುತ್ತದೆ. ಅದರ ನಂತರವೇ ವಿಸ್ತರಣೆ ಹೋಸ್ಟ್ ಭಾಷಾ ಸರ್ವರ್ ಅಥವಾ ತನ್ನದೇ ಬೈನರಿ ಪಡೆಯಬಹುದಾದ ಕೋಡ್ ಚಲಾಯಿಸುತ್ತದೆ. ಯಾವ ಹಂತ ಮುರಿಯಿತು ಎಂಬುದು ಯಾವ ಪ್ರಕ್ರಿಯೆಗೆ ಪ್ರಾಕ್ಸಿ ಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ, ಮತ್ತು ದೋಷದ ಮೇಲ್ಮೈ ಆ ಹಂತವನ್ನು ಅಪರೂಪವಾಗಿ ಹೆಸರಿಸುತ್ತದೆ.

ಕೆಲಸ ಮಾಡುವ ಟರ್ಮಿನಲ್ ಕಂಟೇನರ್ ಇಂಟರ್ನೆಟ್ ತಲುಪಬಲ್ಲದು ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಎಡಿಟರ್ ತಲುಪಬಲ್ಲದು ಎಂದಲ್ಲ. ವಿಸ್ತರಣೆ ಲಾಗ್‌ನಲ್ಲಿ ಅದು ಪ್ರಯತ್ನಿಸಿದ ಕೊನೆಯ URL ಓದಿ. ಅಲ್ಲಿ ಹೆಸರಿಸಿದ ಹೋಸ್ಟ್ ಪ್ರಕ್ರಿಯೆ ಮತ್ತು ಅದಕ್ಕೆ ಅನ್ವಯಿಸುವ ನೀತಿಯನ್ನು ಗುರುತಿಸುತ್ತದೆ.

ಸ್ಥಳೀಯ ಎಡಿಟರ್ ಮತ್ತು ದೂರದ ಕಂಟೇನರ್ ಎರಡು ಪರಿಸರಗಳು

ದೂರದ ಕಾರ್ಯಕ್ಷೇತ್ರದಲ್ಲಿ ವಿಸ್ತರಣೆ ತನ್ನ ಪ್ರಕಾರ ಘೋಷಿಸುವ ಬದಿಯಲ್ಲಿ ಚಲಿಸುತ್ತದೆ. ಇಂಟರ್‌ಫೇಸ್ ವಿಸ್ತರಣೆಗಳು ಸ್ಥಳೀಯ ಎಡಿಟರ್‌ನೊಂದಿಗೆ ಉಳಿಯುತ್ತವೆ, ಮತ್ತು ಕಾರ್ಯಕ್ಷೇತ್ರ ವಿಸ್ತರಣೆಗಳು ಕಂಟೇನರ್‌ನಲ್ಲಿ ಚಲಿಸುತ್ತವೆ. ಒಂದರಲ್ಲಿ ಸೆಟ್ ಮಾಡಿದ ಪ್ರಾಕ್ಸಿ ಇನ್ನೊಂದಕ್ಕೆ ಅಗೋಚರ, ಮತ್ತು ಮರುನಿರ್ಮಾಣವು ಕಂಟೇನರ್ ಪರಿಸರವನ್ನು ಅದರ ಸಂರಚನಾ ಫೈಲ್‌ನಿಂದ ಮರುಸೃಷ್ಟಿಸುತ್ತದೆ, ನೀವು ಶೆಲ್‌ನಲ್ಲಿ ರಫ್ತು ಮಾಡಿದ್ದರಿಂದ ಅಲ್ಲ. ಆ ವಿಭಜನೆ ಏಕೆ ಅದೇ ವಿಸ್ತರಣೆ ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಲ್ಲಿ ಸ್ಥಾಪನೆಯಾಗಿ SSH ಮೂಲಕ ಅದೇ ಯೋಜನೆಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ.

ಏನನ್ನಾದರೂ ಸಂಪಾದಿಸುವ ಮೊದಲು ಸ್ಥಾಪನಾ ಸ್ಥಳವನ್ನು ಓದಿ. ಲಾಗ್ ದೂರದ ಸ್ಥಾಪನೆಯನ್ನು ವರದಿ ಮಾಡಿದಾಗ, ಕಂಟೇನರ್‌ನ ಪರಿಸರವೇ ಮುಖ್ಯ.

ವಿನಂತಿ ಪ್ರಾರಂಭವಾಗುವಲ್ಲಿ ಪ್ರಾಕ್ಸಿ ಇರಿಸಿ

ನಿಜವಾಗಿಯೂ HTTP ಪ್ರಾಕ್ಸಿ ಬೇಕಾದ Dev Container‌ಗೆ, ಚರಾಂಶವು ಕಂಟೇನರ್ ಸಂರಚನೆಯಲ್ಲಿರಬೇಕು, ಇದರಿಂದ ಮರುನಿರ್ಮಾಣ ಅದನ್ನು ಮರುಸೃಷ್ಟಿಸುತ್ತದೆ. ಕೆಳಗಿನ ತುಣುಕು ಅದನ್ನು ಆ ಪರಿಸರಕ್ಕೆ ಸೆಟ್ ಮಾಡುತ್ತದೆ. ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್ ವಿಳಾಸ ನಿಮ್ಮ ಸ್ವಂತ ಗೇಟ್‌ವೇಯನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ, ಮತ್ತು ಹೊರತುಪಡಿಸುವಿಕೆಗಳು ಐಚ್ಛಿಕ ತುಂಬುವಿಕೆ ಅಲ್ಲ.

"containerEnv": {
  "HTTP_PROXY": "http://proxy.corp.example:8080",
  "HTTPS_PROXY": "http://proxy.corp.example:8080",
  "NO_PROXY": "localhost,127.0.0.1,.internal.example"
}

ಚರಾಂಶದ ಹೆಸರು ಗಮ್ಯಸ್ಥಾನ ಪ್ರೋಟೋಕಾಲ್ ವಿವರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ HTTPS_PROXY ಮೌಲ್ಯ ಕಾನೂನುಬದ್ಧವಾಗಿ http ನಿಂದ ಪ್ರಾರಂಭವಾಗಬಹುದು. ಬೆಂಬಲಿತ ಮರುನಿರ್ಮಾಣ ಮಾರ್ಗದ ಮೂಲಕ ಬದಲಾವಣೆ ಅನ್ವಯಿಸಿ ಮತ್ತು ಹೊರತುಪಡಿಸುವಿಕೆಗಳನ್ನು ಉಳಿಸಿ, ಏಕೆಂದರೆ ಆಂತರಿಕ ಹೋಸ್ಟ್‌ಗಳನ್ನು ಪ್ರತಿಬಂಧಿಸುವ ಪ್ರಾಕ್ಸಿ ಕಂಟೇನರ್‌ಗೆ ಬೇಕಾದ ಸೇವೆಗಳನ್ನು ಮುರಿಯುತ್ತದೆ.

ನಂಬಿಕೆಯ ವೈಫಲ್ಯಗಳನ್ನು ತಲುಪುವಿಕೆಯಿಂದ ಬೇರ್ಪಡಿಸಿ

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

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

env | grep -iE '^(http|https|no)_proxy='
code --install-extension ms-python.python --force

ಕಾರ್ಯಕ್ಷೇತ್ರದ ಯಾವ ಬದಿ ಆ URL ಉತ್ಪಾದಿಸಿತು ಎಂಬುದನ್ನು ದಾಖಲಿಸಿ. ಹಂತ, ಹೋಸ್ಟ್ ಮತ್ತು ಬದಿಯನ್ನು ಹೆಸರಿಸುವ ಸಣ್ಣ ಟಿಪ್ಪಣಿ ಯಾರೋ ಬದಲಿಸಿದ ಸೆಟ್ಟಿಂಗ್‌ಗಳ ಪಟ್ಟಿಗಿಂತ ಹೆಚ್ಚು ಮೌಲ್ಯದ್ದು, ಏಕೆಂದರೆ ಮುಂದಿನ ವ್ಯಕ್ತಿ ಮರುಸೃಷ್ಟಿಸಬಹುದಾದದ್ದು ಅದೇ ಟಿಪ್ಪಣಿಯನ್ನು.