فسّر المستخدم المصدر الفشل على أنه «لا يستطيع Docker تثبيت صورة بعد إعادة تثبيت نظيفة»، لكن مخرجات الطرفية أظهرت فعليًا مشكلتين منفصلتين. إن تشغيل docker info فشل تشغيله دون صلاحيات مرتفعة بسبب مقبس Docker، بينما أدى تشغيل حاوية Mosquitto بامتيازات Docker إلى سحب eclipse-mosquitto:latestثم فشلت الحاوية لسبب مختلف: إذ حاول الربط المباشر التعامل مع مسار على المضيف ومسار في الحاوية على أنهما من نوعين غير متوافقين، ملف ودليل.
هذا التمييز بالغ الأهمية. لن تؤدي إعادة تثبيت Debian أو CasaOS أو Docker إلى إصلاح ربط مباشر يشير إلى نوع خاطئ من كائنات نظام الملفات.
المشكلة 1: تعذّر على المستخدم العادي الوصول إلى مقبس Docker
كان أول docker info وكان الناتج:
تم رفض الإذن أثناء محاولة الاتصال بمقبس خدمة Docker الخفية
unix:///var/run/docker.sockيعني ذلك أن مستخدم الصدفة لم يكن يملك الإذن للتواصل مباشرةً مع خدمة Docker الخفية. وقد نجح الأمر نفسه باستخدام sudo، مما يثبت أن الخدمة الخفية نفسها كانت قابلة للوصول.
وهذا منفصل عن خطأ بدء تشغيل Mosquitto اللاحق.
تم تنزيل صورة Mosquitto بنجاح
أبلغ Docker بما يلي:
الحالة: تم تنزيل صورة أحدث من eclipse-mosquitto:latestلذلك لم يكن السجل، أو اسم الصورة، أو اتصال الإنترنت هو المشكلة المباشرة. حدث الفشل فقط عندما حاول Docker إنشاء نظام ملفات الحاوية وتطبيق الربط المباشر.
كان الخطأ الحقيقي هو تركيب ملف مقابل دليل
حاول الأمر تعيين:
/etc/mosquitto/mosquitto.conf
→ /mosquitto/config/mosquitto.confثم أبلغ Docker بما يلي:
ليس دليلًا
هل تحاول تركيب دليل على ملف (أو العكس)؟يجب أخذ هذه الرسالة حرفيًا. كان أحد طرفي الربط من نوع مختلف عن النوع الذي يتوقعه الأمر.
لماذا يمكن لـ -v إنشاء النوع الخطأ تلقائيًا
توضح وثائق Docker الحالية فخًا سهل الوقوع فيه مع -v/--volume: إذا لم يكن المسار المصدر موجودًا، ينشئه Docker تلقائيًا على شكل دليل.
لذلك إذا /etc/mosquitto/mosquitto.conf لم يكن موجودًا مسبقًا كملف حقيقي، إذ كان بإمكان Docker إنشاء دليل باسم mosquitto.confإن تركيب ذلك الدليل على ملف الإعدادات المتوقع في الحاوية ينتج بعد ذلك الخطأ نفسه تمامًا الظاهر في سلسلة النقاش المصدرية.
استخدم سلوك الربط المباشر الحالي في Docker للتحقق مما إذا كان المصدر ملفًا أم دليلًا قبل بدء الحاوية.
انتقل المجتمع إلى تعيين مجلدات Mosquitto
شارك أحد المشاركين تعريف Compose يعيّن ثلاثة مجلدات دائمة:
- مجلد الإعداد على المضيف →
/mosquitto/config - مجلد البيانات على المضيف →
/mosquitto/data - مجلد السجل على المضيف →
/mosquitto/log
يؤدي هذا إلى تجنب نقطة الربط الهشة لملف واحد قد لا يكون موجودًا بعد، ويوفر لـ Mosquitto تخطيطًا عاديًا دائمًا.
لا يزال يتعين وجود ملف الإعداد داخل مجلد الإعداد
لا يؤدي تعيين المجلد إلى إنشاء إعداد صالح لـ Mosquitto تلقائيًا. أخبر المُجيب المستخدمَ بأن يضع mosquitto.conf داخل مجلد الإعداد المعين قبل بدء تشغيل الوسيط.
عند إجراء نشر جديد، أنشئ الإعداد كملف حقيقي أولًا، ثم اربط دليله الأب أو استخدم خيار Docker الأكثر وضوحًا --mount الصياغة، التي تفشل بدلًا من إنشاء مجلد مصدر مفقود بصمت.
يمكن للتثبيت المخصص في CasaOS التعبير عن التخطيط نفسه دون أمر docker run خام
أرشد المجتمع المستخدم خلال استيراد تعريف Compose عبر سير عمل التطبيقات المخصصة في CasaOS. ثبّت المستخدم لاحقًا حزمة Mosquitto من متجر تطبيقات مجتمعي وأفاد بأنها عملت فورًا.
تؤكد هذه النتيجة أن مضيف Docker نفسه كان قادرًا على تشغيل Mosquitto؛ وكانت المشكلة السابقة في الإعداد، لا في فشل إعادة تثبيت CasaOS.
لا يزال الوسيط قيد التشغيل بحاجة إلى مصادقة MQTT وإعداد المستمع
سأل المستخدم بعد ذلك عن سبب عدم اتصال Node-RED وما إذا كان Mosquitto سيستخدم اسم المستخدم/كلمة المرور الخاصين بالطرفية تلقائيًا. لا يفعل ذلك. تُضبط مصادقة MQTT بواسطة Mosquitto نفسه من خلال ملف الإعداد وملفات كلمات المرور.
لا تفترض أن ظهور حالة الحاوية باللون الأخضر يعني أن الوسيط جاهز للعملاء غير المصادق عليهم.
كانت المنطقة الزمنية تفصيلًا نهائيًا في إعداد الحاوية
بعد تثبيت حزمة مجتمعية عاملة، ظل المستخدم بحاجة إلى إضافة قيمة المنطقة الزمنية المناسبة في متغيرات البيئة. وهذا تفصيل متعلق بالتطبيق/وقت التشغيل، وليس دليلًا على فشل آخر في تثبيت Docker.
الأسئلة الشائعة حول خطأ Mosquitto في Docker
هل فشل Docker في تنزيل eclipse-mosquitto؟
لا. يُظهر ناتج المصدر أنه تم تنزيل الصورة بنجاح.
لماذا فشلت الحاوية في البدء؟
كان هناك عدم تطابق بين ملف ومجلد في نقطة الربط حول mosquitto.conf.
لماذا يمكن أن يتحول ملف مضيف مفقود إلى مجلد عند استخدام docker -v؟
الخاص بـ Docker --volume يؤدي هذا السلوك إلى إنشاء مصدر مضيف مفقود على شكل مجلد، مما قد يؤدي إلى تعطيل ربط من ملف إلى ملف.
هل أدت إعادة تثبيت CasaOS إلى حل المشكلة؟
لا. نجح المستخدم في النهاية بعد استخدام إعداد صحيح للتطبيق/الحاوية.
