కంటైనర్ VPN-మాత్రమే APIని చేరుకోలేకపోతున్నారా? దాన్ని హోస్ట్‌పై ప్రాక్సీ చేయండి

అదే మెషీన్‌లోని బ్రౌజర్ ఎలాంటి ఫిర్యాదు లేకుండా తెరిచే 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లో రాయండి. లేకపోతే ఈ సమయ మితిని ఎదుర్కొనే తదుపరి వ్యక్తి టన్నెల్ హోస్ట్‌పై నివసిస్తుందని మళ్లీ కనుగొనడంలో అదే మధ్యాహ్నాన్ని గడుపుతారు.