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 विरुद्ध लिहिलेली कोणतीही चाचणी आता वर्कलोडऐवजी टनेल कंटेनरला विचारते.
नमुना लिहून ठेवा, ज्यात कोणता कंटेनर नेमस्पेस ठेवतो आणि कोणते पोर्ट त्याचे आहेत याचा समावेश आहे. पुढची व्यक्ती एक सेवा जोडेल, चुकीचा ब्लॉक कॉपी करेल आणि या लेखातील पहिले अपयश पुन्हा तयार करेल.