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 के विरुद्ध लिखी गई कोई भी प्रोब अब वर्कलोड के बजाय टनल कंटेनर से पूछती है।
पैटर्न लिख लें, जिसमें यह भी शामिल हो कि कौन सा कंटेनर नेमस्पेस रखता है और कौन से पोर्ट उसके हैं। अगला व्यक्ति एक सेवा जोड़ेगा, गलत ब्लॉक कॉपी करेगा और इस लेख की पहली विफलता दोहराएगा।