कन्टेनर 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 मा लेख्नुहोस्। नत्र यो समय सीमासँग भेट्ने अर्को व्यक्तिले पनि टनेल होस्टमा बस्छ भनी फेरि पत्ता लगाउँदै त्यही दिउँसो बिताउनेछ।