Docker: توجيه حاوية واحدة عبر VPN وإبقاء أخرى مباشرة
امنح النفق حاوية خاصة به، واسمح فقط للخدمات التي تحتاجه بمشاركة مساحة الأسماء تلك، ثم احسب ما يتبع المالك: المنافذ وlocalhost وDNS.
مضيف واحد، وحملان عمل، وشرط يفرّقهما: عميل تنزيل يجب أن يخرج من VPN تجاري، وواجهة إدارة يجب أن تبقى تستخدم اتصال المضيف. تثبيت عميل VPN على المضيف يفشل الشرط فورًا، لأن حملَي العمل يتشاركان عندئذ مخرجًا واحدًا. النمط الذي ينجح فعلًا هو نقل النفق إلى حاوية خاصة به والسماح فقط لأحمال العمل التي تحتاجه بالانضمام إلى مساحة أسماء الشبكة لتلك الحاوية. كل ما عدا ذلك يبقى على مسار Docker العادي، والتفاصيل التي تلي هي نتائج لمن يملك مساحة الأسماء.
لماذا تغيّر مساحة الأسماء المشتركة القواعد
الحاوية التي تنضم إلى مساحة أسماء حاوية أخرى لا تحصل على حزمة شبكة خاصة بها. إنها ترى نفس الواجهات ونفس جدول التوجيه ونفس الاسترجاع المحلي الذي تراه الحاوية التي انضمت إليها، وهذا بالضبط سبب فائدة النمط: يحل حمل العمل ويتصل بشكل طبيعي، بينما يلتقط النفق تحته حركة المرور دون أن يعرف التطبيق. الثمن أن كل إعداد ذي طابع شبكي صار له مالك واحد، والحاوية المنضمة ليست هي.
قاعدة الملكية هذه تجيب عن معظم أسئلة الإعداد قبل طرحها. إذا كان الإعداد يعيش في حزمة الشبكة، فهو يخص الحاوية المرافقة. وإذا كان يصف العملية، فهو يبقى مع حمل العمل.
الاسترجاع المحلي هو الجزء الذي يفاجئ الناس. داخل الحاوية المنضمة، يُحلّ localhost إلى استرجاع الحاوية المرافقة المحلي، لا إلى استرجاع خاص به، لذا فخدمة تربط على 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 |
الصف الرابع هو ما يشخصه الناس خطأً كخلل في التطبيق. المسبار الذي كُتب ضد استرجاع حمل العمل المحلي صار يختبر حاوية النفق، لذا إما يفشل أو يبلّغ عن الخدمة الخطأ تمامًا.
عندما يحتاج اسم مضيف واحد إلى النفق
أحيانًا يكون النفق الكامل أكثر من اللازم: اسم داخلي واحد يجب أن يمر عبر VPN مؤسسي بينما يبقى مقبس محلي أو اتصال عرض يعمل. النفق الكامل داخل الحاوية يكسر ذلك المسار وأي شيء موجه إلى المضيف، لذا وجّه فقط البادئة التي تحتاجه. غلاف توجيه منقسم حول العميل يفعل ذلك، بإرسال المضيف المسمى عبر النفق وترك المسار السابق دون تغيير لكل شيء آخر.
اختر هذا عندما تحتاج فقط إلى الوصول إلى خدمة واحدة ولا تحاول نقل كل حركة الحاوية. إنه أداة مختلفة عن الحاوية المرافقة ويجيب عن سؤال مختلف.
تحقق، ثم اجعله ينجو من إعادة التشغيل
اسأل كل حاوية عن العنوان الذي تبدو قادمة منه. يجب أن تطبع حاوية النفق عنوان المزود، ويجب أن تطبع الحاوية المباشرة مخرج المضيف. الإجابات المتطابقة تعني أن الخدمة المباشرة ورثت مساحة الأسماء الخطأ أو أن VPN على مستوى المضيف ما زال يلتقط كل شيء، وهذان الإصلاحان مختلفان. أعد الفحص بعد كل تعديل على compose، لأن كتلة خدمة منسوخة واحدة تكفي لإعادة المشكلة.
ثلاثة أشياء تنكسر عادة لاحقًا. يتبع DNS مالك مساحة الأسماء، لذا فإعدادات المحلّل ونطاق البحث تخص الحاوية المرافقة لا المضيف. VPN مع إعادة توجيه منافذ يغيّر منفذ استماعه عند إعادة الاتصال، لذا يجب كتابة المنفذ المعاد توجيهه من المزود ومنفذ الاستماع على جانب الحاوية مرة أخرى في إعداد العميل أو في تعيين المنافذ، عادة عبر محدِّث صغير يقرأ واجهة برمجة المزود. وأي مسبار مكتوب ضد localhost صار يسأل حاوية النفق لا حمل العمل.
اكتب النمط، بما في ذلك أي حاوية تملك مساحة الأسماء وأي المنافذ تخصها. سيضيف الشخص التالي خدمة، وينسخ الكتلة الخطأ، ويعيد إنتاج أول عطل في هذا المقال.