إذا كان بإمكان Sonarr أو Radarr أو Lidarr أو Transmission أو غيرها من الحاويات على ZimaOS الوصول إلى بعضها بعضًا عبر عنوان IP، لكن لا يمكنها استخدام أسماء مستقرة مثل transmission:9091، تكون المشكلة عادةً في حلّ الأسماء، لا في اتصال الحاويات الأساسي. وقد أصبح هذا التمييز النتيجة الرئيسية في موضوع مجتمع IceWhale هذا في نوفمبر 2025.
الافتراضي في Docker bridge لا توفّر الشبكة حلّ DNS تلقائيًا لأسماء الحاويات بالطريقة نفسها التي يوفّرها جسر معرّف من المستخدم. ثم كشفت المناقشة عن تعقيد ثانٍ خاص بـ ZimaOS: فقد توجد شبكات جسر أُنشئت يدويًا في Docker قبل أن تظهر بشكل صحيح في واجهة الويب الخاصة بـ ZimaOS، كما قد ترفض الواجهة شبكات Docker الصالحة خلافًا لذلك بسبب توقّعاتها لعلامات Compose.
العَرَض الأساسي: يعمل IP لكن يفشل اسم الحاوية
أراد المستخدم الأصلي أن يصل Radarr إلى Transmission باستخدام:
http://transmission:9091تغيّرت عناوين IP للحاويات بعد عمليات إعادة التشغيل أو التحديث، لذا كان تثبيتها يدويًا غير موثوق. كان بإمكان الحاويات الوصول إلى بعضها بعضًا عبر IP، لكن الاتصالات المعتمدة على اسم المضيف كانت تفشل.
لماذا لا يحلّ جسر Docker الافتراضي هذه المشكلة
توضح وثائق شبكة الجسر الحالية في Docker أن الحاويات على الجسر الافتراضي يمكنها التواصل باستخدام عناوين IP، بينما توفّر الجسور المعرّفة من المستخدم حلّ DNS تلقائيًا بين الحاويات.
لذلك، فإن عبارة «تستخدم جميع التطبيقات bridge» لا تعني بالضرورة أنها تستخدم جسرًا معرّفًا من المستخدم وله اسم، مع DNS المضمّن في Docker.
إنشاء جسر معرّف من المستخدم
sudo -i
docker network create media-netيمكن للحاويات المتصلة بالجسر نفسه المعرّف من المستخدم عادةً حلّ أسماء بعضها بعضًا باستخدام اسم الحاوية أو الاسم المستعار للشبكة.
تستخدم وثائق ZimaOS الحالية النمط نفسه
تستخدم وثائق ZimaSpace الحالية الآن شبكة مخصّصة بشكل صريح في دليل Zabbix، لأن الجسر الافتراضي لا يوفّر سلوك DNS المطلوب للحاويات:
sudo docker network create zabbix-netاطّلع على دليل تثبيت Zabbix الحالي لـ ZimaOS.
المشكلة الخاصة بـ ZimaOS: مزامنة WebUI
في النقاش الأصلي، لم يؤدِّ إنشاء شبكة bridge مخصّصة عبر Docker أو Portainer إلى جعل الشبكة قابلة للاستخدام فورًا من إعدادات تطبيق ZimaOS. وقد شاهد المستخدمون أخطاءً مثل:
تم العثور على الشبكة internal-network، لكنها تحتوي على وسم غير صحيح
تم ضبط com.docker.compose.network على ""بعد الاختبار مع أحد المهندسين، قال Zima-Giorgio إن شبكة Docker نفسها تعمل بشكل طبيعي، لكن WebUI قد تكون غير متزامنة مع الواجهة الخلفية لـ Docker.
الخطوة التي أكّدها المجتمع: إعادة التشغيل بعد إنشاء الشبكة
sudo -i
docker network create net-a
docker network create net-b
إعادة التشغيلبعد إعادة التشغيل، ظهرت الشبكات المُنشأة حديثًا في لوحة إعدادات التطبيق. وأكّد مشارك آخر أن عدم إعادة التشغيل كان الخطوة الأساسية في اختباره، وأن حلّ أسماء النطاقات عمل على شبكة bridge المخصّصة بعد ذلك.
لا يتطلب Docker القياسي عادةً إعادة تشغيل المضيف بالكامل بعد docker network create؛ وكان هذا سلوكًا خاصًا بـ ZimaOS لوحظ في نقاش عام 2025.
مشكلة توافق وسم Compose لا تزال قائمة
حتى بعد أن أوضحت إعادة التشغيل مشكلة المزامنة، وثّق النقاش قيدًا آخر. إذ كان ZimaOS قد يعرض أن شبكة أُنشئت يدويًا تحتوي على com.docker.compose.network وسم.
قال Zima-Giorgio في النهاية إن عدم القدرة على اختيار بعض الشبكات المُنشأة يبدو أنه مشكلة، وسيُحال الأمر إلى الفريق. ولا يتضمن النقاش تأكيدًا لاحقًا بأن كل حالات عدم القدرة على اختيار الشبكات قد أُصلحت.
تحقّق من الشبكة عبر Docker، وليس من واجهة المستخدم فقط
docker network inspect media-net
docker inspect CONTAINER_A
docker inspect CONTAINER_Bفاختبر حلّ الأسماء من حاوية واحدة:
docker exec CONTAINER_A ping -c 2 CONTAINER_Bإذا لم تتضمن الصورة ping، استخدم أداة تشخيص أخرى متاحة أو حاوية اختبار مؤقتة على الشبكة نفسها.
استخدم الأسماء أو الأسماء المستعارة بدلًا من تغيير عناوين IP
بعد أن يعمل DNS في Docker على جسر يحدده المستخدم، اضبط التطبيقات باستخدام نقطة نهاية مستقرة مثل:
http://transmission:9091أو اسم مستعار للشبكة محدد في Compose.
هل كان Cloudflared هو السبب؟
لم تحدد سلسلة النقاش المصدر Cloudflared باعتباره السبب الجذري. كان الاتصال عبر IP يعمل بالفعل، وكان العطل متوافقًا مع سلوك DNS وحلّ أسماء Docker.
حل مؤقت: عنوان IP للمضيف والمنافذ المنشورة
حجز صاحب المنشور الأصلي مؤقتًا عنوان IP ثابتًا على الشبكة المحلية لمضيف ZimaOS، وضبط التطبيقات لاستخدام ذلك العنوان مع المنافذ المنشورة. قد ينجح هذا، لكنه يمر عبر مسار المنافذ المنشورة للمضيف بدلًا من توجيه الخدمة مباشرةً باستخدام اسمها داخل Docker.
قائمة التحقق من حلّ أسماء الحاويات في ZimaOS
- تأكد من أن الاتصال من IP إلى IP يعمل.
- تحقق مما إذا كانت الحاويات موجودة على الجسر الافتراضي أو على جسر مُسمّى يحدده المستخدم.
- أنشئ جسرًا مخصصًا عندما يكون DNS مستقرًا مطلوبًا.
- ألحِق جميع الخدمات المطلوبة بالشبكة المخصصة نفسها.
- في إصدارات ZimaOS المطابقة للإصدار المذكور في سلسلة النقاش المصدر، أعد التشغيل لكي تحدّث واجهة الويب في ZimaOS حالة شبكة Docker.
- تحقق باستخدام
docker inspectوdocker network inspect. - اختبر حلّ اسم الحاوية من داخل حاوية أخرى.
- إذا أبلغ ZimaOS عن عدم تطابق في تسمية Compose، فاعتبر ذلك مشكلة في واجهة المستخدم أو التكامل، وليس دليلًا على أن شبكة Docker غير صالحة.
الأسئلة الشائعة حول جسر حاويات ZimaOS
لماذا يتعذر على الحاويات الموجودة على الجسر حلّ أسماء بعضها بعضًا؟
يتيح جسر Docker الافتراضي الاتصال عبر IP، لكنه لا يوفر DNS تلقائيًا لأسماء الحاويات كما يفعل الجسر الذي يحدده المستخدم.
هل أحتاج إلى إعادة التشغيل بعد تنفيذ docker network create؟
عادةً لا يفعل Docker ذلك. في سلسلة نقاش ZimaOS لعام 2025، كان يلزم إعادة التشغيل لكي تسترجع واجهة الويب في ZimaOS حالة الشبكة الجديدة.
هل يتسبب Cloudflared في تعطيل DNS لجسر Docker؟
لم يثبت ذلك في سلسلة النقاش المصدر.
هل ينبغي أن أعيّن عناوين IP ثابتة لـ Docker؟
عادةً لا. تُعدّ أسماء DNS المستعارة التي يحددها المستخدم في Docker أكثر قابلية للنقل من عناوين IP الثابتة للحاويات.
