ما الذي يتسبب في امتلاء قرص النظام بسبب حاوية بينما توجد بياناتها في مكان آخر؟

يمكن للحاوية أن تملأ قرص النظام عندما تبقى السجلات أو ذاكرات التخزين المؤقت أو الملفات المؤقتة أو عمليات الكتابة غير المقصودة داخل وحدة التخزين المحلية لـ Docker.

إن نقل مكتبة وسائط أو وحدة تخزين قاعدة بيانات إلى تجمّع آخر لا ينقل صورة الحاوية أو طبقة الكتابة أو سجل JSON أو ذاكرة التخزين المؤقت لـ BuildKit أو البيانات الوصفية أو أي مسار لم يُدرج في قائمة نقاط الربط. كما يمكن أن يؤدي فشل نقطة ربط خارجية إلى ترك دليل المضيف المتوقع فارغًا، ما يتسبب في كتابة التطبيق لبيانات جديدة على قرص النظام من دون ظهور خطأ واضح.

قِس جذر Docker قبل فحص بيانات التطبيق

تحقق من نظام الملفات الذي يحتوي على جذر بيانات Docker، وقارن أحجام أدلة المضيف مع إحصاءات Docker الخاصة بالصور والحاويات ووحدات التخزين وذاكرة التخزين المؤقت للبناء. سجّل الاستخدام قبل حذف أي شيء.

اكتشف أحد مستخدمي Cloudron أن /var/lib/docker/overlay2 يستهلك مساحة أكبر من جميع بيانات التطبيقات الظاهرة، ما يوضح سبب ضرورة قياس جذر تخزين Docker بشكل مستقل عن المكتبات الخارجية.

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

تحقق من سجلات JSON غير المحدودة للحاويات

افحص برنامج تشغيل السجلات وحجم ملف سجل كل حاوية. يمكن للخدمة أن تخزن بياناتها الأساسية في مكان آخر، بينما يستمر stdout وstderr في النمو بلا حدود داخل دليل الحاوية المحلي لدى Docker.

يوثّق Code Maven حالة لم يكشف فيها docker system df عن المشكلة الرئيسية، لأن ملف السجل الافتراضي ظل ينمو خارج ذلك الملخص. وكان المستهلك الخفي هو سجل الحاوية المتنامي باستمرار.

اعثر على خطأ التطبيق المزعج وأصلحه قبل تدوير السجلات أو اقتطاعها. اضبط تدويرًا محدودًا للسجلات في الحاويات المستقبلية، وتحقق من توقف الملفات الجديدة عن النمو عند الحد المتوقع.

اعثر على البيانات المكتوبة داخل طبقة الكتابة في الحاوية

قارن المسارات الدائمة المقصودة مع أدلة ذاكرة التخزين المؤقت والتحويل والتنزيل وقاعدة البيانات والصور المصغرة والنسخ الاحتياطية والملفات المؤقتة الفعلية في التطبيق. تبقى أي عملية كتابة غير مرتبطة بنقطة ربط في طبقة الكتابة الخاصة بالحاوية على قرص النظام.

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

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

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

تحقق من وجود نقطة الربط الخارجية عند بدء الحاوية

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

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

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

افحص طبقات الصور وذاكرة التخزين المؤقت للبناء والكائنات المهجورة

راجع الصور غير المستخدمة والحاويات المتوقفة ووحدات التخزين المجهولة وذاكرة التخزين المؤقت لـ BuildKit. يمكن للتحديثات المتكررة أو عمليات البناء المحلية أن تراكم طبقات كثيرة حتى عندما تكون بيانات التطبيق الدائمة مرتبطة بشكل صحيح في مكان آخر.

يوضح شرح في منتدى مشروع Moby أن نقاط ربط overlay قد تجعل أرقام القرص مربكة، وأنه يجب تفسير استخدام نظام الملفات الأساسي بعناية. كما أظهرت حالة منفصلة في Home Assistant نمو overlay2 الناتج عن السجلات والطبقات بمرور الوقت.

أزل الكائنات التي تأكد فقط من عدم استخدامها في مشاريع Compose الحالية والنسخ الاحتياطية. لا تحذف أدلة overlay2 الفردية يدويًا مطلقًا، لأن مراجع البيانات الوصفية في Docker قد تصبح غير متسقة.

تحقق من الإصلاح باستخدام خط أساس للنمو

بعد تصحيح المسار المسؤول، سجّل استخدام جذر Docker وأحجام السجلات وأحجام الكتابة الخاصة بالحاويات واستخدام التجمّع الخارجي على فترات منتظمة أثناء تشغيل الحمل الذي تسبب سابقًا في النمو.

يوفر سير عمل ZimaSpace الخاص بـ تجهيز عملية نقل كبيرة إلى NAS حملًا قابلًا للتكرار للتأكد من وصول البيانات إلى التجمّع المقصود.

لا تُعد المشكلة محلولة إلا عندما يتوافق نمو قرص النظام مع سلوك الصور والسجلات المتوقع، وتنمو بيانات التطبيق الدائمة على التجمّع الخارجي، ويؤدي غياب نقطة الربط الخارجية إلى فشل آمن عند بدء التشغيل بدلًا من الكتابة الصامتة إلى نظام ملفات الجذر.