لماذا تُرفق حزمة Compose وحدة تخزين مُسمّاة جديدة وفارغة بعد إعادة النشر؟
يمكن لمكدس Compose إرفاق وحدة تخزين مسماة جديدة وفارغة عندما تؤدي إعادة النشر إلى تغيير اسم وحدة التخزين المرتبط بالمشروع أو يتعذر عليها العثور على وحدة التخزين الأصلية.
قد تظل البيانات القديمة موجودة في وحدة تخزين Docker أخرى، بينما تقوم الخدمة المُعاد إنشاؤها بتركيب وحدة تخزين جديدة مُنشأة تلقائيًا في المسار نفسه داخل الحاوية. تشمل الأسباب الشائعة تغيّر اسم المكدس أو المشروع، أو إعادة تسمية مفتاح وحدة التخزين، أو إزالة الوحدة باستخدام أمر يحذف وحدات التخزين، أو فقدان تعريف وحدة تخزين خارجية، أو النشر عبر مدير آخر، أو تغيّر طريقة حل اسم صريح لوحدة التخزين. افحص كلًا من وحدة التخزين المركبة والمرشحين المتروكين قبل استعادة البيانات أو تهيئة التطبيق.
حدّد وحدة التخزين الدقيقة المركبة بواسطة الحاوية الجديدة
افحص عمليات التركيب في الحاوية قيد التشغيل، وسجّل اسم وحدة التخزين، والمشغّل، ونقطة التركيب، والتسميات، ووقت الإنشاء، ووجهة الحاوية، ووضع القراءة والكتابة. قارن هذه البيانات بسجلات ما قبل إعادة النشر.
يتيح أمر docker volume inspect في Ubuntu مراجعة هوية وحدة التخزين، مما يساعد على تمييز وحدة التخزين الجديدة الفارغة من وحدة تخزين أقدم غير مركبة تحمل اسمًا مشابهًا.
لا تنسخ البيانات إلى وحدة التخزين الجديدة قبل العثور على الأصلية. فقد يؤدي تشغيل التطبيق إلى إنشاء قاعدة بيانات جديدة وجعل الوجهة تبدو مهيأة عمدًا.
تحقق مما إذا كان اسم مشروع Compose قد تغيّر
قارن بين اسم المشروع القديم والجديد، واسم المكدس، ودليل Compose، وخيار -p، والمتغير COMPOSE_PROJECT_NAME، والقيمة العليا name:، ومدير النشر.
توضح Docker أن Compose يحدد نطاق وحدة التخزين عادةً باستخدام اسم المشروع مضافًا إلى مفتاح وحدة التخزين، ما لم يُضبط اسم صريح أو يُجرَ البحث عن وحدة تخزين خارجية.
لذلك، قد يؤدي نقل ملف Compose نفسه إلى دليل آخر إلى إنشاء مشروع ثانٍ ووحدة تخزين ثانية، حتى إذا بقيت مفاتيح الخدمة ووحدة التخزين دون تغيير.
تحقق من إعدادات الاسم الثابت ووحدة التخزين الخارجية
قارن تعريف وحدة التخزين في المستوى الأعلى قبل إعادة النشر وبعدها. تحقق من name: وexternal: وخيارات المشغّل ومتغيرات الاستبدال وما إذا كانت وحدة التخزين المتوقعة موجودة.
يشير البرنامج التعليمي لـ Docker Compose من Microsoft إلى أن وحدات التخزين المسماة تستمر مستقلّة عن استبدال الحاويات، لذا فإن ظهور حالة جديدة فارغة يعني عادةً إرفاق وحدة تخزين مختلفة أو إزالة وحدة التخزين القديمة.
اجعل وحدة التخزين خارجية فقط عندما تكون دورة حياتها مُدارة عمدًا خارج المكدس. يجب أن يفشل Compose بوضوح عند غياب وحدة تخزين خارجية، بدلًا من إنشاء بديل بصمت.
تحقق مما إذا كانت عملية تنظيف قد أزالت وحدة التخزين الأصلية
راجع سجلات النشر، والبرامج النصية، وإجراءات واجهة المستخدم، ومهام التنظيف، والأوامر التي تحذف وحدات التخزين. قارن وقت إنشاء وحدة التخزين بحدث إعادة النشر.
توثق Red Hat أن وحدات التخزين المسماة التي تديرها الحاويات لها مواقع تخزين منفصلة عن طبقات الكتابة القابلة للتعديل الخاصة بالحاويات، ولذلك فإن إزالة حاوية وإزالة وحدة تخزينها المسماة حدثان مختلفان في دورة الحياة.
إذا كانت وحدة التخزين الأصلية مفقودة، فأوقف عمليات التشغيل التلقائي واستعد البيانات فقط من نسخة احتياطية تم التحقق منها. لا تفترض أن وحدة التخزين البديلة الفارغة تحتوي على طبقة محذوفة قابلة للاسترداد.
قارن هوية مدير المكدس وطريقة النشر
سجّل ما إذا كان المكدس قد شُغّل عبر CLI أو Portainer أو متجر تطبيقات NAS أو نشر Git أو أداة أتمتة أخرى. قارن اسم المكدس وقيم البيئة المخزنة لدى ذلك المدير.
يتطلب Portainer اسم مكدس وصفيًا عند النشر، وقد تختلف الهوية التي يديرها هذا المدير عن اسم المشروع المستند إلى الدليل والمستخدم في أمر Compose اليدوي.
لذلك، قد يؤدي تشغيل يدوي طارئ إلى إنشاء الموارد تحت بادئة مشروع أخرى. اختر جهة واحدة مسؤولة عن النشر ووثّق أسماء وحدات التخزين الفعلية التي تنشئها.
استبعد احتمال إخفاء البيانات أسفل تركيب وحدة التخزين الجديدة
أوقف الحاوية وافحص الصورة أو مسار الربط من دون إرفاق وحدة التخزين المسماة، وذلك في اختبار مؤقت. حدّد ما إذا كان بدء التشغيل قد كتب بيانات في طبقة الحاوية قبل تركيب وحدة التخزين.
يوضح دليل تركيب Linux أن التركيب يخفي محتويات الدليل الموجودة مسبقًا، لذلك قد تبدو البيانات مفقودة عندما تغطي وحدة تخزين جديدة فارغة الملفات التي أُنشئت في الصورة أو طبقة الكتابة القابلة للتعديل.
لا تدمج الطبقة المخفية ووحدة التخزين الدائمة القديمة بشكل عشوائي. حدّد أي حالة هي المعتمدة واستخدم طريقة الاسترداد المدعومة من التطبيق.
أعد توصيل وحدة التخزين الأصلية باختبار مضبوط
أوقف المكدس، وأنشئ نسخة احتياطية من وحدتي التخزين المرشحتين، وأرفق الوحدة الأصلية بحاوية مؤقتة أو بمسار خدمة مؤقت، وتحقق من ملفات التطبيق، وهوية قاعدة البيانات، والملكية، والطوابع الزمنية.
يوفر دليل ZimaSpace حول نقل بيانات الحاويات دون كسر عمليات التركيب سير العمل المرتبط بتعيين المسارات؛ بينما يركّز هذا المقال على هوية وحدات التخزين المسماة المرتبطة بالمشروع.
تُحل المشكلة عندما تُركّب وحدة التخزين القديمة المقصودة باستخدام اسم صريح ثابت أو اسم خارجي، وتعيد عمليات النشر المتكررة استخدامها دون إنشاء مرشح فارغ آخر.
الأسئلة الشائعة
هل تعني وحدة التخزين المسماة الفارغة أن البيانات القديمة حُذفت؟
ليس بالضرورة. قد تظل وحدة التخزين القديمة موجودة تحت بادئة مشروع أخرى أو اسم صريح آخر، بينما تستخدم الحاوية الجديدة وحدة تخزين فارغة مختلفة.
هل يمكن أن يؤدي تغيير اسم مجلد Compose إلى إنشاء وحدة تخزين جديدة؟
نعم. عندما لا يكون اسم المشروع ثابتًا، يمكن لـ Compose اشتقاقه من دليل المشروع وإنشاء موارد ذات بادئات مختلفة.
هل ينبغي وضع علامة «خارجية» على وحدات التخزين المهمة؟
يمكن لوحدات التخزين الخارجية أن تمنع إزالة المكدس من إدارة دورة حياتها، لكنها تتطلب إنشاءً وتسميةً ونسخًا احتياطيًا وفحوصات نشر مقصودة.
المنتجات الموصى بها
الدعم والنصائح
المزيد للقراءة
لماذا تؤدي استعادة وحدة تخزين Docker إلى إعادة إنشاء محتويات الملفات مع فقدان السمات الموسّعة؟
تشخيص لاستعادة وحدة تخزين يغطي جرد السمات الموسَّعة (xattr)، وخيارات tar وRsync، ومساحات الأسماء، ودعم الوجهة، والامتيازات، والتسميات، والبيانات الوصفية للتطبيق، والاختبارات.
لماذا يحتفظ الحاوي قيد التشغيل بحد الذاكرة القديم بعد تغيير ملف Compose؟
تشخيص لحدود الذاكرة يغطي مجموعات cgroups النشطة، وإعادة التشغيل مقابل إعادة الإنشاء، وحقول Compose، والحدود الصارمة والمرنة، والنطاقات الأصلية، وذاكرة التبديل، وأكوام الذاكرة في...
لماذا يؤدي إعادة تشغيل وكيل عكسي إلى إبطال كل جلسة في تطبيق مستضاف ذاتيًا واحد؟
تشخيص لفقدان الجلسة يشمل نطاق إعادة التشغيل، وملكية ملفات تعريف الارتباط، وتدوير الأسرار، والجلسات المدعومة بالتخزين المؤقت، والتوجيه الثابت، وبوابات المصادقة، والاسترداد.
