कंटेनर 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 मध्ये लिहा. नाहीतर ही वेळमर्यादा भेटणारी पुढील व्यक्ती टनेल होस्टवर राहते हे पुन्हा शोधण्यात तोच दुपार घालेल.