Docker: एउटा कन्टेनरलाई VPN मार्फत पठाउनुहोस् र अर्कोलाई सिधै राख्नुहोस्
टनेललाई यसको आफ्नै कन्टेनर दिनुहोस्, यसलाई आवश्यक पर्ने सेवाहरूलाई मात्र त्यो नेमस्पेस साझा गर्न दिनुहोस्, त्यसपछि मालिकपछि के आउँछ त्यसको हिसाब गर्नुहोस्: पोर्टहरू, localhost, DNS.
एउटा होस्ट, दुई कार्यभार र तिनलाई छुट्याउने एउटा आवश्यकता: व्यावसायिक VPN बाट बाहिर निस्कनुपर्ने डाउनलोड क्लाइन्ट र होस्टको जडान प्रयोग गरिरहनुपर्ने व्यवस्थापन इन्टरफेस। होस्टमा VPN क्लाइन्ट स्थापना गर्दा आवश्यकता तुरुन्तै असफल हुन्छ, किनकि त्यसपछि दुवै कार्यभार एउटै निकास साझा गर्छन्। वास्तवमै काम गर्ने ढाँचा भनेको टनेललाई यसको आफ्नै कन्टेनरमा सार्नु र यसलाई आवश्यक पर्ने कार्यभारहरूलाई मात्र त्यो कन्टेनरको नेटवर्क नेमस्पेसमा सामेल हुन दिनु हो. बाँकी सबै सामान्य Docker मार्ग राख्छ, र अब आउने विवरणहरू नेमस्पेस कसको हो भन्ने परिणाम हुन्।
साझा नेमस्पेसले नियम किन बदल्छ
अर्काको नेमस्पेसमा सामेल हुने कन्टेनरले आफ्नै नेटवर्क स्ट्याक पाउँदैन। यसले सामेल भएको कन्टेनरकै जस्तै इन्टरफेस, त्यही राउटिङ तालिका र त्यही loopback देख्छ, र यसैकारण यो ढाँचा उपयोगी छ: कार्यभार सामान्य रूपमा रिजोल्व गरी जोडिन्छ, र तलको टनेलले अनुप्रयोगलाई थाहा नदिई ट्राफिक समात्छ। मूल्य भनेको प्रत्येक नेटवर्कसम्बन्धी सेटिङको अब एउटै मालिक हुन्छ, र सामेल हुने कन्टेनर त्यो होइन।
यो स्वामित्व नियमले अधिकांश कन्फिगरेसन प्रश्नको उत्तर ती सोधिनुअघि नै दिन्छ। सेटिङ नेटवर्क स्ट्याकमा बस्छ भने त्यो साइडकारको हो। यसले प्रक्रियाको वर्णन गर्छ भने त्यो कार्यभारसँगै रहन्छ।
loopback मानिसहरूलाई अचम्म लगाउने भाग हो। सामेल हुने कन्टेनरभित्र, localhost साइडकारको loopback मा रिजोल्व हुन्छ, आफ्नै निजी एउटामा होइन, त्यसैले 127.0.0.1 मा बाँधिएर अलगावको अपेक्षा गर्ने सेवाले अब त्यो ठेगाना टनेल कन्टेनरसँग साझा गर्छ।
नेमस्पेस भएको कन्टेनरमा पोर्टहरू प्रकाशित गर्नुहोस्
पोर्ट म्यापिङ नेमस्पेसको मालिकको हो, सुन्ने प्रक्रिया अर्को कन्टेनरमा चले पनि। म्यापिङ साइडकारमा घोषणा गर्नुहोस्, र कार्यभारले आफ्नो प्रक्रिया कन्फिगरेसन अछुतो राखोस्। सामेल हुने सेवामा म्यापिङ लागू हुन सक्दैन, इन्जिनले अस्वीकार गरे पनि वा कन्टेनर कसरी सुरु हुन्छ भन्ने आधारमा चुपचाप बेवास्ता गरे पनि, र त्यसैकारण क्षणअघि पुग्न सकिने इन्टरफेस ढाँचा लागू हुनासाथ हराउँछ।
services:
gluetun:
image: qmcgaw/gluetun
cap_add: [NET_ADMIN]
ports: ["8080:8080"]
client-vpn:
image: example/client
network_mode: "service:gluetun"
client-direct:
image: example/client
ports: ["8081:8080"]यो ब्लकलाई तीन सेवा नभई तीन निर्णयका रूपमा पढ्नुहोस्। साइडकारले टनेल र प्रकाशित पोर्टको स्वामित्व लिन्छ; सामेल हुने क्लाइन्टले कुनै नेटवर्क घोषणा गर्दैन; सिधा क्लाइन्टले पूर्वनिर्धारित नेटवर्कमा आफ्नै म्यापिङ राख्छ। क्षमताले NET_ADMIN साइडकारलाई इन्टरफेस बनाउन र मार्ग बदल्न दिन्छ, र त्यही कारण यो कन्टेनरलाई यसले सेवा गर्ने कार्यभारभन्दा बढी विशेषाधिकार चाहिन्छ।
सिधा रहने सेवाले आफ्नै नेटवर्क राख्छ
टनेलबाट जानु नहुने कार्यभारले पूर्वनिर्धारित ब्रिज वा आफ्नै प्रयोगकर्ता-परिभाषित नेटवर्क आफ्नै प्रकाशित पोर्ट र आफ्नै निकाससहित राख्छ। दुई कन्टेनरले नामबाट कुरा गर्न सकून् भनेर यसलाई साइडकार नेटवर्कमा जोड्ने प्रलोभन हुन्छ, तर त्यो एउटै कदमले यसको ट्राफिक चुपचाप टनेलमा सार्छ। यिनीहरूले एकअर्कासम्म पुग्नुपर्ने भए अलग प्रयोगकर्ता-परिभाषित नेटवर्क बनाउनुहोस्, दुवैलाई त्यसमा जोड्नुहोस्, र साइडकारलाई बाहिर जाने एकमात्र बाटो राख्नुहोस्।
दुई प्रश्न अलग राख्नुहोस्: कुन कन्टेनरहरू एकअर्कासम्म पुग्न सक्छन्, र कुन कहाँबाट बाहिर जान्छ। यिनलाई मिलाउनु नै यो डिजाइन फेरि पूरै होस्ट-व्यापी VPN बन्ने सबैभन्दा सामान्य तरिका हो।
पहिलो घण्टाका लागि असफलता म्याट्रिक्स
अधिकांश पहिलो प्रयास चारमध्ये एउटा तरिकाले असफल हुन्छन्, र प्रत्येकको कारण फरक हुन्छ। यिनलाई यही क्रममा जाँच्नुहोस्, किनकि पहिलो दुईले लगभग सबै प्रतिवेदन व्याख्या गर्छन्।
| Symptom | Likely cause |
|---|---|
| Web UI unreachable after the change | Port mapping declared on the joining container instead of the sidecar |
| Both containers show the provider's exit address | The direct service was attached to the sidecar network |
| Internal names stop resolving | Resolver settings live on the host, not in the shared namespace |
| Health check fails but the app works | The check probes localhost, which now means the sidecar |
चौथो पङ्क्ति त्यो हो जसलाई मानिसहरूले गल्तीले अनुप्रयोगको बग ठान्छन्। कार्यभारको आफ्नै loopback विरुद्ध लेखिएको जाँचले अब टनेल कन्टेनर परीक्षण गरिरहेको छ, त्यसैले यो या त असफल हुन्छ वा पूर्ण रूपमा गलत सेवाको रिपोर्ट गर्छ।
जब एउटै होस्टनामलाई टनेल चाहिन्छ
कहिलेकाहीँ पूरा टनेल धेरै हुन्छ: एउटा आन्तरिक नाम कर्पोरेट VPN बाट जानुपर्छ जबकि स्थानीय सकेट वा डिस्प्ले जडान चलिरहन्छ। कन्टेनरभित्रको पूरा टनेलले त्यो मार्ग र होस्टलाई सम्बोधित सबै कुरा तोड्छ, त्यसैले आवश्यक पर्ने प्रिफिक्स मात्र रुट गर्नुहोस्। क्लाइन्टवरिपरिको विभाजित राउटिङ र्यापरले त्यो गर्छ, नाम दिइएको होस्टलाई टनेलबाट पठाउँछ र बाँकी सबैका लागि अघिल्लो मार्ग अछुतो राख्छ।
तपाईंले एउटै सेवासम्म पुग्नुपर्ने र कन्टेनरको सबै ट्राफिक सार्न नखोजेको अवस्थामा यो छान्नुहोस्। यो साइडकारभन्दा फरक उपकरण हो र फरक प्रश्नको उत्तर दिन्छ।
प्रमाणित गर्नुहोस्, अनि यसलाई पुनःसुरुवातमा टिक्ने बनाउनुहोस्
प्रत्येक कन्टेनरलाई सोध्नुहोस् कि यो कुन ठेगानाबाट आएको देखिन्छ। टनेलमा भएकोले प्रदायकको ठेगाना छाप्नुपर्छ र सिधा भएकोले होस्टको निकास। एउटै जवाफको अर्थ सिधा सेवाले गलत नेमस्पेस विरासतमा पायो वा होस्ट-स्तरीय VPN अझै सबै समातिरहेको छ, र ती दुई सुधार फरक हुन्। प्रत्येक compose सम्पादनपछि जाँच फेरि चलाउनुहोस्, किनकि एउटा प्रतिलिपि गरिएको सेवा ब्लकले समस्या फर्काउन पर्याप्त हुन्छ।
तीन कुरा पछि बिग्रने प्रवृत्ति हुन्छ। DNS नेमस्पेसको मालिकलाई पछ्याउँछ, त्यसैले रिजोल्भर र खोज डोमेनका सेटिङ होस्टमा नभई साइडकारमा हुनुपर्छ। पोर्ट-फर्वार्ड गरिएको VPN ले पुनःजडानमा आफ्नो सुन्ने पोर्ट बदल्छ, त्यसैले प्रदायकको फर्वार्ड गरिएको पोर्ट र कन्टेनरतर्फको सुन्ने पोर्ट क्लाइन्ट कन्फिगरेसन वा पोर्ट म्यापिङमा फेरि लेख्नुपर्छ, सामान्यतया प्रदायकको API पढ्ने सानो अद्यावधिककर्ताद्वारा। र localhost विरुद्ध लेखिएको कुनै पनि जाँचले अब कार्यभारलाई नभई टनेल कन्टेनरलाई सोध्छ।
ढाँचा लेख्नुहोस्, कुन कन्टेनरले नेमस्पेस राख्छ र कुन पोर्ट यसका हुन् भन्नेसमेत समावेश गरेर। अर्को व्यक्तिले सेवा थप्नेछ, गलत ब्लक प्रतिलिपि गर्नेछ र यस लेखको पहिलो असफलता पुनःउत्पादन गर्नेछ।