ಕಂಟೇನರ್ VPN-only API ತಲುಪುತ್ತಿಲ್ಲವೇ? ಅದನ್ನು ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಪ್ರಾಕ್ಸಿ ಮಾಡಿ

ಟನೆಲ್ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ವಾಸಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಕಂಟೇನರ್‌ಗೆ ಖಾಸಗಿ ವಿಳಾಸಕ್ಕೆ ಮಾರ್ಗವಿಲ್ಲ. ಕಿರಿದಾದ ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿ ಪ್ರಕಟಿಸಿ ಮತ್ತು ಅದನ್ನು host.docker.internal ಎಂದು ಕರೆಯಿರಿ.

ಒಂದೇ ಯಂತ್ರದ ಬ್ರೌಸರ್ ಯಾವುದೇ ದೂರಿಲ್ಲದೆ ತೆರೆಯುವ API ವಿರುದ್ಧ ನಿಮ್ಮ Compose ಸೇವೆ ಸಮಯ ಮೀರಿ ಹೋಗುತ್ತದೆ. ಆ ವ್ಯತ್ಯಾಸವೇ ಸುಳಿವು: ಕೆಲಸ ಮಾಡುವ ವಿನಂತಿ VPN ಟನೆಲ್ ಇರುವ ಹೋಸ್ಟ್‌ನಿಂದ ಹೊರಡುತ್ತದೆ, ಮತ್ತು ನೇತಾಡುವ ವಿನಂತಿ ತನ್ನದೇ ನೆಟ್‌ವರ್ಕ್ ಸ್ಟ್ಯಾಕ್ ಇರುವ ಕಂಟೇನರ್‌ನಿಂದ ಹೊರಡುತ್ತದೆ. ಕಂಟೇನರ್ ಒಳಗೆ ಯಾವುದೂ ಟನೆಲ್‌ನ ಮಾರ್ಗಗಳನ್ನು ತಿಳಿದಿಲ್ಲ, ಆದ್ದರಿಂದ ಹೆಸರನ್ನು ಹೇಗೆ ಬರೆದರೂ ಖಾಸಗಿ ಗಮ್ಯಸ್ಥಾನ ತಲುಪಲಾಗದಂತೆ ಉಳಿಯುತ್ತದೆ. ಪರಿಹಾರವೆಂದರೆ ಹೋಸ್ಟ್ ಮೂಲಕ ಉದ್ದೇಶಪೂರ್ವಕವಾದ ನೆಗೆತ, ಹೆಚ್ಚು ಬುದ್ಧಿವಂತ ಮಾರ್ಗ ಕೋಷ್ಟಕವಲ್ಲ.

ಎರಡು ಮಾರ್ಗಗಳು ಏಕೆ ಭಿನ್ನ ಎಂಬುದರಿಂದ ಪ್ರಾರಂಭಿಸಿ, ನಂತರ ಟನೆಲ್ ಎಲ್ಲಿ ಇರಬೇಕೆಂದು ನಿರ್ಧರಿಸಿ.

ಹೋಸ್ಟ್ ಏಕೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ಕಂಟೇನರ್ ಏಕೆ ಇಲ್ಲ

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

ಆದ್ದರಿಂದ ಲಕ್ಷಣಗಳು ಕೇವಲ ಮುರಿದಂತೆ ಅಲ್ಲ, ಅಸಂಗತವಾಗಿ ಕಾಣುತ್ತವೆ. ಹೋಸ್ಟ್ ಖಾಸಗಿ ಹೆಸರನ್ನು ಪರಿಹರಿಸಿ ಸಂಪರ್ಕಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಅಲ್ಲಿ ಹೆಸರು ಮತ್ತು ಮಾರ್ಗ ಎರಡೂ ಇವೆ. ಕಂಟೇನರ್ ತನ್ನ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಸೇತುವೆ ಮಾರ್ಗದಲ್ಲಿ ಯಾವುದೂ ತಲುಪಲಾಗದ ಖಾಸಗಿ ವಿಳಾಸಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ, ಮತ್ತು ವಿನಂತಿ ಸಮಯ ಮೀರುತ್ತದೆ. ಕಂಟೇನರ್‌ನ hosts ಕಡತಕ್ಕೆ ಹೆಸರನ್ನು ಸೇರಿಸುವುದರಿಂದ ಏನೂ ಬದಲಾಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ವಿಳಾಸವೇ ಕಂಟೇನರ್ ಇರುವ ಸ್ಥಳದಿಂದ ತಲುಪಲಾಗದ್ದು.

ಕಂಟೇನರ್ ಒಳಗಿನಿಂದ ಹೋಸ್ಟ್ ತಲುಪಿ

ಕಂಟೇನರ್‌ನಲ್ಲಿರುವ ಪ್ರಕ್ರಿಯೆ localhost ಡಯಲ್ ಮಾಡಿದರೆ ಅದು ಕಂಟೇನರ್ ಅನ್ನೇ ಡಯಲ್ ಮಾಡುತ್ತದೆ. Docker Desktop host.docker.internal ಅನ್ನು ಎಂಜಿನ್ ಚಲಾಯಿಸುವ ಯಂತ್ರದ ಕಡೆ ಹಿಂತಿರುಗಿ ತೋರಿಸುವ ಹೆಸರಾಗಿ ಪ್ರಕಟಿಸುತ್ತದೆ; Linux ಎಂಜಿನ್‌ಗಳು ಸೇವೆ ಕೇಳದಿದ್ದರೆ ಅದನ್ನು ಅನಿರ್ದಿಷ್ಟವಾಗಿ ಬಿಡುತ್ತವೆ, ಮತ್ತು ಕೆಳಗಿನ ಮ್ಯಾಪಿಂಗ್ ಅದನ್ನೇ ಮಾಡುತ್ತದೆ. ಅದರಿಂದ ಅಪ್ಲಿಕೇಶನ್ ಖಾಸಗಿ ವಿಳಾಸದ ಬದಲು ಹೆಸರು ಮತ್ತು ಪೋರ್ಟ್ ಅನ್ನು ಗುರಿಯಾಗಿಸುತ್ತದೆ.

services:
  app:
    extra_hosts:
      - "host.docker.internal:host-gateway"
    environment:
      INTERNAL_API_HOST: "host.docker.internal:8666"

ಟನೆಲ್ ನೆಗೆತದ ಹೋಸ್ಟ್ ಬದಿಯಲ್ಲೇ ಉಳಿಯುತ್ತದೆ, ಮತ್ತು ಆ ಚರಾಕ್ಷರದಲ್ಲಿನ ಪೋರ್ಟ್ ಪ್ರಾಕ್ಸಿ ಕೇಳಿಸಿಕೊಳ್ಳುವ ಪೋರ್ಟ್. ಟನೆಲ್ ಕಳೆದುಕೊಂಡ ಕಂಟೇನರ್ ಈಗ ಎಂದೂ ಇಲ್ಲದ ಮಾರ್ಗವನ್ನು ಪ್ರಯತ್ನಿಸುವ ಬದಲು ಒಂದು ತಿಳಿದ ನೆಗೆತದಲ್ಲೇ ವಿಫಲವಾಗುತ್ತದೆ.

ಟನೆಲ್ ಎಲ್ಲಿ ವಾಸಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಆಯ್ಕೆಮಾಡಿ

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

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

ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಒಂದೇ ಕಿರಿದಾದ ಮಾರ್ಗ ಪ್ರಕಟಿಸಿ

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

server {
    listen 8666;
    location /search/ {
        proxy_pass http://10.20.30.40:8090/;
        proxy_set_header Host internal-api.example;
        proxy_read_timeout 60s;
    }
}

ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ ಅನ್ನು ತಾತ್ಕಾಲಿಕ ಎಂದು ಪರಿಗಣಿಸಿ, API ನಿಜವಾಗಿ ಕೇಳಿಸಿಕೊಳ್ಳುವ ಜೋಡಿಯನ್ನು ಹಾಕಿ. ಪ್ರತಿ ಹೆಚ್ಚುವರಿ upstream ತನ್ನದೇ location ಬ್ಲಾಕ್ ಪಡೆಯುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿ ಬ್ಲಾಕ್ ಈ ಸೇವೆ ಕರೆಯುವ ಮಾರ್ಗಗಳಿಗೆ ಮಾತ್ರ ಅನುಮತಿ ನೀಡಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಪ್ರಾಕ್ಸಿ ಖಾಸಗಿ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಸಾಮಾನ್ಯ ಬಾಗಿಲಾಗುತ್ತದೆ. host-gateway ಮೂಲಕ ಬರುವ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಶ್ರೋತೃವನ್ನು ಸೇತುವೆ ವಿಳಾಸಕ್ಕೆ, ಕ್ಲೈಂಟ್ ಹೋಸ್ಟ್‌ನ ನೆಟ್‌ವರ್ಕ್ ನಾಮಸ್ಥಳವನ್ನು ಹಂಚಿಕೊಂಡಾಗ ಮಾತ್ರ loopback‌ಗೆ ಬಂಧಿಸಿ, ಮತ್ತು ಎಂದಿಗೂ 0.0.0.0 ಗೆ ಬಂಧಿಸಬೇಡಿ. ಇನ್ನೂ ಮುಕ್ತವಿರುವ ಪೋರ್ಟ್ ಕೂಡ ಆಯ್ಕೆಮಾಡಿ: ಈಗಾಗಲೇ ತೆಗೆದುಕೊಂಡ ಸಂಖ್ಯೆ ಪ್ರಾಕ್ಸಿಯನ್ನು ಕೇಳಿಸಿಕೊಳ್ಳದಂತೆ ಬಿಡುತ್ತದೆ, ಕಂಟೇನರ್ ಸಮಯ ಮೀರುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ, ಮತ್ತು ಇದನ್ನು ನೀವು ಪ್ರಾರಂಭಿಸಿದ ನೆಟ್‌ವರ್ಕ್ ದೋಷದಿಂದ ಬೇರ್ಪಡಿಸಲಾಗದು.

ಪೋರ್ಟ್‌ಗಳು, ಹೆಸರುಗಳು ಮತ್ತು TLS ನಿರ್ಧಾರ

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

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

ಸೇವೆಯ ಒಳಗಿನಿಂದ ಪರಿಶೀಲಿಸಿ

ವಿನಂತಿಯನ್ನು ಹೋಸ್ಟ್‌ನಿಂದಲ್ಲ, ಕಂಟೇನರ್‌ನಿಂದ ಕಳುಹಿಸಿ: ಪ್ರಾಕ್ಸಿ ಮಾರ್ಗಕ್ಕೆ ಸಾಮಾನ್ಯ curl, ನಂತರ ಅಪ್ಲಿಕೇಶನ್‌ನ ಸ್ವಂತ ಆರೋಗ್ಯ ಪರಿಶೀಲನೆ. ಪ್ರಾಕ್ಸಿ ಉತ್ತರಿಸಿದರೂ ಅಪ್ಲಿಕೇಶನ್ ಇನ್ನೂ ವಿಫಲವಾದರೆ, ಮೂರು ವಿಷಯಗಳನ್ನು ಹೋಲಿಸಿ: ಅದು ಕಟ್ಟುವ ಮೂಲ URL, ಅದರ ಪರಿಸರದಲ್ಲಿನ ಯಾವುದೇ ಪ್ರಾಕ್ಸಿ ಚರಾಕ್ಷರ, ಮತ್ತು ಅದು ನಂಬುವ CA. ಎಲ್ಲವೂ ಕಂಟೇನರ್‌ನ ಪರಿಸರ ಮತ್ತು ಲಾಗ್‌ಗಳಲ್ಲಿವೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಯಾವುದನ್ನಾದರೂ ಸರಿಪಡಿಸುವುದು VPN ಅನ್ನು ಅಸ್ಪೃಶವಾಗಿ ಬಿಡುತ್ತದೆ.

ಆಯ್ಕೆ ಮಾಡಿದ ಜೋಡಣೆಯನ್ನು ತಾಜಾ ಇರುವಾಗಲೇ ಯೋಜನೆಯ README ನಲ್ಲಿ ಬರೆಯಿರಿ. ಇಲ್ಲದಿದ್ದರೆ ಈ ಸಮಯ ಮಿತಿಗೆ ಸಿಕ್ಕಿಬೀಳುವ ಮುಂದಿನ ವ್ಯಕ್ತಿ ಟನೆಲ್ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ವಾಸಿಸುತ್ತದೆ ಎಂದು ಮತ್ತೆ ಕಂಡುಕೊಳ್ಳುವುದರಲ್ಲೇ ಅದೇ ಮಧ್ಯಾಹ್ನ ಕಳೆಯುತ್ತಾನೆ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು