هل ينبغي لـ Immich استخدام شبكة المضيف أم شبكة الجسر؟

بالنسبة إلى معظم عمليات نشر Immich المعتمدة على Docker، تُعدّ شبكة الجسر التي يعرّفها المستخدم الخيار الافتراضي الأنظف؛ أما شبكة المضيف فهي حل موجّه لمشكلة محددة، وليست ترقية عامة للأداء.

يحتاج Immich أساسًا إلى مسارات موثوقة بين العميل والخادم، والخادم وقاعدة البيانات، والخادم وRedis، وخادم التعلّم الآلي، والوكيل العكسي. ويمكن لكلا نمطي الشبكة توفير هذه المسارات. ينبغي اتخاذ القرار من خلال إعادة إنتاج العطل أو متطلب الوصول الفعلي، واختبار نمط واحد في كل مرة، والإبقاء على الإعداد الأسهل في المراقبة والاسترداد.

ابدأ بالمسارات التي يحتاج إليها Immich فعلًا

ارسم المكدس على شكل اتصالات بدلًا من حاويات: يصل العملاء إلى نقطة نهاية Immich العامة أو المحلية؛ ويصل الوكيل إلى خادم Immich؛ ويصل التطبيق إلى PostgreSQL وRedis؛ ويتصل الخادم بالتعلّم الآلي. حدّد أي الاتصالات يبقى داخل Docker وأيها يعبر حدود المضيف.

تمنح شبكة الجسر التي يعرّفها المستخدم الحاويات مساحة أسماء شبكية خاصة بها، مع السماح للخدمات الموجودة على الشبكة نفسها بحلّ أسماء بعضها بعضًا باستخدام اسم الخدمة. ويوضح العرض العام لشبكات Docker هذا الفرق: فالمنافذ المنشورة تخدم العملاء على المضيف أو خارجه، بينما يتولى DNS الخاص بالحاويات حركة المرور بين الخدمات.

إذا كان كل مسار مطلوب يعمل بالفعل عبر شبكة الجسر، فلم تحلّ شبكة المضيف مشكلة مثبتة. احتفظ بشبكة الجسر ووثّق أسماء الخدمات والشبكات والمنافذ المنشورة، حتى يمكن مقارنة أي تغيير لاحق في الوكيل أو Compose بطوبولوجيا معروفة.

فضّل شبكة الجسر التي يعرّفها المستخدم عندما تكون العزلة وأسماء الخدمات المستقرة مهمة

يسمح نمط الجسر لخدمات Immich بالتواصل عبر شبكة تطبيق صريحة من دون كشف منافذ كل حاوية على المضيف. ويكون ذلك مفيدًا خصوصًا عندما يشارك الوكيل العكسي الشبكة، إذ يمكنه استهداف اسم خدمة Immich مباشرةً، مما يقلل الاعتماد على عنوان IP للحاوية الذي قد يتغير بعد إعادة إنشائها.

يشير تحليل مختبرات المنزل لمفاضلات شبكات المضيف إلى أن إزالة NAT الخاص بـDocker نادرًا ما تحقق مكسبًا مهمًا في الأداء لحركة مرور الويب المعتادة في مختبرات المنزل. وتتمثل الفروقات الأهم في عزل مساحة الأسماء، ونشر المنافذ، وكيفية اكتشاف الخدمات بعضها بعضًا.

يفشل نمط الجسر كتصميم فقط عندما يتعذر التعبير عن مسار مطلوب أو يظل غير موثوق بعد تصحيح الشبكة وDNS والجدار الناري وعضوية الوكيل. لا تبدّل النمط لمجرد أن عميلًا أبلغ عن «تعذر الوصول إلى الخادم»؛ أثبت أولًا أن الطلب يتوقف عند حدود Docker.

استخدم شبكة المضيف فقط لمتطلب محدد يمكن إعادة إنتاجه

يضع نمط المضيف الحاوية في مساحة أسماء شبكة المضيف، ما يلغي ترجمة منافذ Docker ويمنح الخدمة سياق شبكة المضيف. قد يبسّط ذلك بعض حالات الاكتشاف أو التوجيه غير المعتادة، لكنه يلغي أيضًا حدود المنافذ على مستوى الحاوية ويزيد احتمال تعارض منافذ المضيف.

تؤطر مقارنة حديثة بين شبكتي الجسر والمضيف الاختيارَ حول الأداء والعزلة وكشف الخدمات وتصحيح الأخطاء. طبّق هذه الأبعاد على مسار Immich بدل افتراض أن نمط المضيف أكثر موثوقية بطبيعته.

إذا أصلح نمط المضيف عرضًا واحدًا، فأعد الاختبار مرتين واشرح السبب. على سبيل المثال، تحقّق من أن اسم المضيف والحساب والوكيل والعميل نفسها تفشل عبر الجسر وتنجح عبر المضيف، مع بقاء سجلات التطبيق سليمة بخلاف ذلك. وإذا تعذر تكرار النتيجة، فقد يكون تغيير النمط قد أخفى فقط حالة DNS أو شبكة قديمة.

Featured

ZimaCube 2 سحابة شخصية منزلية NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

أبقِ الوكيل العكسي على مسار صريح قابل للاسترداد

ينبغي أن يصل الوكيل العكسي إلى Immich عبر تعريف ثابت للجهة الخلفية بعد إعادة تشغيل أي من الحاويتين. في شبكة الجسر، فضّل شبكة مشتركة يعرّفها المستخدم وتعريفًا للجهة الخلفية باستخدام اسم الخدمة بدلًا من عنوان IP للحاوية المنسوخ يدويًا. وفي نمط المضيف، وجّه الوكيل إلى عنوان المضيف والمنفذ المقصودين مع التحقق من عدم وجود تعارضات.

يستخدم نمط اختبار المضيف مقابل الجسر من ZimaSpace قاعدة شرطية مماثلة: قد تبرر بساطة الاكتشاف استخدام نمط المضيف، بينما تفضّل العزلة والتكامل الصريح مع الوكيل استخدامَ شبكة الجسر. لدى Immich بروتوكولات مختلفة، لذا أعد استخدام طريقة اتخاذ القرار بدل افتراضات المنافذ الخاصة بـPlex.

أعد تشغيل الوكيل وحده، ثم Immich وحده، ثم المكدس كاملًا. يعيد التصميم الناجح المسارات المحلية والبعيدة نفسها في كل مرة من دون تحرير عناوين IP. أما الطوبولوجيا التي تحتاج إلى إعادة توصيل يدوية بعد إعادة الإنشاء فليست مستقرة بما يكفي، بغض النظر عن استخدامها شبكة المضيف أو الجسر.

اختر النمط الذي ينجح في اختبار القبول نفسه بأقل قدر من المخاطر

اختبر تسجيل الدخول إلى الويب محليًا، واتصال تطبيق الهاتف المحمول، ورفع ملف صغير، ورفع ملف كبير، والوصول عبر الوكيل العكسي، وصحة الاتصال بين الخدمات، وإعادة تشغيل كاملة واحدة. سجّل زمن الاستجابة وحالات الفشل، لكن لا تعطِ فروقات الإنتاجية الطفيفة وزنًا مبالغًا فيه إذا ظل كلا النمطين بعيدين كثيرًا عن الحد الأقصى للشبكة.

اختر شبكة الجسر عندما تنجح جميع الوظائف وتستفيد من التعرض الصريح، وDNS الحاويات، والعزلة. واختر شبكة المضيف عندما يفشل مسار مطلوب بصورة قابلة لإعادة الإنتاج عبر شبكة جسر مُهيّأة بشكل صحيح، ويصلح نمط المضيف المشكلة من دون إنشاء تعارضات في المنافذ أو توسيع نطاق التعرض بما يتجاوز ما تقبله.

إذا فشل كلا النمطين بالطريقة نفسها، فتوقف عن تبديل إعدادات الشبكة. من المرجح أن يكون السبب في DNS أو TLS أو ترويسات الوكيل أو المصادقة أو الجدار الناري أو التخزين أو التطبيق نفسه. احتفظ بالطلب الفاشل والسجلات، ثم عد إلى الطوبولوجيا الأبسط والمعروفة بسلامتها، وشخّص الحدّ التالي.