لماذا يتوقف اسم مستعار لشبكة Compose عن الحل بعد إعادة إنشاء الحزمة باسم مشروع جديد؟
قد يتوقف الاسم المستعار في Compose عن العمل بعد إعادة الإنشاء عندما تنضم الخدمة إلى شبكة مختلفة خاصة بالمشروع، أو عندما لا يعود الاسم المستعار مرتبطًا بتلك الشبكة.
الأسماء المستعارة في Docker مرتبطة بالشبكة وليست أسماء عامة. قد يؤدي إعادة إنشاء حزمة تحت مجلد جديد، أو باستخدام اسم مشروع صريح، أو اسم حزمة في Portainer، أو مشروع Compose مختلف، إلى إنشاء شبكة افتراضية جديدة بينما يظل تطبيق آخر على الشبكة القديمة. قد تكون الخدمة سليمة ويمكن الوصول إليها عبر المنفذ المنشور، ومع ذلك يفشل الاسم المستعار الداخلي لأن المستدعي والهدف لم يعودا يشتركان في الشبكة نفسها، أو لأن وكيلًا عكسيًا اختار ارتباطًا مختلفًا.
قارن اسمي مشروع Compose القديم والجديد
سجّل اسم المشروع السابق والحالي، ومجلد العمل، واسم الحزمة، وأسماء الشبكات، وتسميات الحاويات. قارن بين خدمة المستدعي والخدمة الهدف بعد إعادة الإنشاء.
يستخدم Docker Compose اسم المشروع لتجميع الموارد وتسميتها. توضّح أولوية اسم المشروع في Docker Compose سبب إمكانية أن يؤدي تغيير المجلد أو اسم النشر إلى إنشاء شبكة جديدة بدلًا من إعادة استخدام شبكة المشروع القديمة.
إذا ظل المستدعي مرتبطًا بـ oldproject_default بينما انضم الهدف إلى newproject_default، فلن يعود للاسم المستعار السابق نطاق DNS مشترك.
تحقق من الاسم المستعار على الشبكة المشتركة المحددة
افحص الحاويتين وسجّل كل شبكة مرتبطة، ونقطة النهاية، وعنوان IPv4 أو IPv6، والاسم المستعار. اختبر DNS من داخل حاوية المستدعي.
تعرّف مواصفة Compose الأسماء المستعارة على أنها أسماء مرتبطة بالشبكة، لذلك لا يظهر الاسم المستعار المُعلن ضمن شبكة ما تلقائيًا على ارتباط آخر.
انقل تعريف الاسم المستعار إلى الشبكة التي تشترك فيها الخدمات فعليًا. لا تعتمد على container_name بديلًا عن اكتشاف الخدمات المقصود.
تحقق من أسماء الشبكات الخارجية والاستبدال أثناء النشر
قارن مفتاح شبكة Compose المنطقي مع قيمة name الخارجية الصريحة. وتحقق من استبدال المتغيرات والبيانات التي تستخدمها واجهة الحزمة أثناء النشر.
توضح وثائق Portainer أن الحزم يمكنها استخدام شبكات Docker الموجودة، والتي يجب اختيارها باستمرار عندما تحتاج الحزم المنشورة بشكل مستقل إلى التواصل فيما بينها.
لا تمنع الشبكة الخارجية تغيّر بادئة المشروع إلا عندما تشير كل حزمة إلى اسم الشبكة الفعلي نفسه. قد يؤدي خطأ مطبعي إلى إنشاء شبكة مختلفة أو اختيارها دون تغيير المنفذ المنشور للخدمة.
تأكد من أن المستدعي يستخدم DNS الخاص بـ Docker بدلًا من عنوان مخزن مؤقتًا
أجرِ بحثًا جديدًا من المستدعي، وافحص إعدادات محلّل الأسماء لديه، وأعد تشغيل العملية التي تخزن DNS مؤقتًا عند الحاجة. قارن حل الاسم بالبحث المباشر عن اسم الخدمة.
يعزل نموذج مساحة أسماء الشبكة في Linux موارد الشبكة، ولهذا لا يثبت نجاح DNS على المضيف أن حاوية المستدعي تشترك في شبكة Docker الخاصة بالهدف.
لا تضف عنوان IP الحالي للحاوية الهدف إلى /etc/hosts. فقد تحصل الحاويات المُعاد إنشاؤها على عنوان مختلف، مما يترك تبعية قديمة أخرى.
تحقق من الشبكة التي يستخدمها الوكيل العكسي
افحص ارتباطات شبكة الوكيل والتطبيق، وتسميات المزوّد، والشبكة المحددة لتوجيه الواجهة الخلفية. اختبر الاسم المستعار من داخل حاوية الوكيل.
يتيح مزوّد Docker في Traefik تحديد شبكة Docker المستخدمة للاتصالات بالواجهات الخلفية.
إذا كان الوكيل مرتبطًا بعدة شبكات، فقد يختلف الاختيار التلقائي بعد إعادة الإنشاء. عيّن الشبكة المشتركة المطلوبة صراحةً، وحافظ على ثبات اسمها الفعلي.
أزل نقاط النهاية القديمة دون حذف الشبكة الخطأ
اعرض الحاويات المتصلة بالشبكتين القديمة والجديدة. حدّد نقاط النهاية المتيمة، والحاويات المتوقفة، والخدمات النشطة التي لا تزال تعتمد على شبكة المشروع القديمة.
يوضح دليل شبكات الحاويات من Red Hat أن ارتباط الحاوية بشبكة يحددها المستخدم يُعد جزءًا من حالة وقت تشغيل الحاوية، وليس من محتوى ملفات التطبيق.
لا تزل الشبكة القديمة إلا بعد إثبات عدم استخدام أي حزمة نشطة لها. إن حذف الشبكتين وإعادة إنشاء كل شيء دفعة واحدة يدمّر الأدلة التي توضّح أي ارتباط كان خاطئًا.
أعد إنشاء خدمة واحدة وتحقق من DNS من كل مستدعٍ
وحّد اسم المشروع أو الشبكة الخارجية، وأعد إنشاء الخدمة المتأثرة فقط، ثم اختبر اسم الخدمة والاسم المستعار من كل حاوية تعتمد عليها.
تقدم مقالة ZimaSpace حول تبعيات وقت تشغيل الحاوية القاعدة ذات الصلة: لا يثبت اختبار الاتصال على مستوى المضيف مساحة الأسماء ومسار اكتشاف الخدمة داخل الحاوية.
تُحل المشكلة عندما يُحل الاسم المستعار إلى نقطة النهاية الحالية من كل مستدعٍ مقصود بعد إعادة إنشاء الحزمة وإعادة التشغيل، من دون استخدام عناوين IP ثابتة ضمن الشيفرة.
الأسئلة الشائعة
هل الأسماء المستعارة لشبكات Docker عامة؟
لا. يوجد الاسم المستعار فقط على الشبكة التي تم تكوينه عليها، ولا يفيد إلا الحاويات التي تشترك في تلك الشبكة.
هل يمكن أن يؤدي تغيير اسم مجلد Compose إلى تعطيل DNS؟
نعم. قد يؤثر المجلد في اسم المشروع الافتراضي، مما يؤثر في أسماء الشبكات المُنشأة، ما لم يتم تثبيت اسم المشروع أو الشبكة الخارجية.
هل ينبغي أن أستخدم container_name للحفاظ على ثبات DNS؟
عادةً لا. تحافظ أسماء الخدمات الثابتة والشبكات المشتركة الصريحة على قابلية توسعة Compose، وتتجنب تعارضات الأسماء العامة.
المنتجات الموصى بها
الدعم والنصائح
المزيد للقراءة
دليل تخزين تسجيلات التلفزيون المباشر للسعة والاحتفاظ والتنظيف
قِس التسجيلات الفعلية، واترك هامشًا احتياطيًا، واجمع بين حدود العمر والسعة، وأثبت إزالة أقدم برنامج مؤهل قبل امتلاء مساحة التخزين.
سير عمل استعادة البيانات الوصفية للوسائط المنزلية بعد استعادة قاعدة البيانات
احمِ الحالة المستعادة، وتحقق من هوية الوسائط ومساراتها، ثم أصلح الأعمال الفنية أو المطابقات المفقودة في مكتبة تجريبية قبل إجراء تغييرات واسعة على البيانات...
قائمة التحقق من توافق عميل Jellyfin مع الصوت والفيديو والترجمات المصاحبة
اختبر ملفات تمثيلية مع تغيير متغير واحد في كل مرة، وسجّل التشغيل المباشر، أو إعادة التغليف، أو تحويل الصوت، أو تحويل الفيديو، أو الفشل...
