الخلاصة: كان التطبيق سليمًا، لكن Docker حاول كتابة إعدادات واجهة سطر الأوامر في الجذر للقراءة فقط ضمن ZimaOS
كان مكدس Compose يعمل بالفعل على جهاز آخر. لكنه فشل على ZimaOS مع ظهور الخطأ mkdir /root/.docker: read-only file system. وقد أدّى توجيه DOCKER_CONFIG إلى موقع قابل للكتابة إلى حل المشكلة الفعلية.
لتطبيق يُشغَّل لمرة واحدة، استخدم مسار إعدادات Docker قابلًا للكتابة
sudo -i
mkdir -p /var/lib/docker/.docker
export DOCKER_CONFIG=/var/lib/docker/.docker
docker compose up -dنجح الأمر في الحالة الفعلية لأن Docker لم يعد يحاول إنشاء /root/.docker على نظام ملفات الجذر الخاص بالجهاز. توثّق Docker متغير البيئة DOCKER_CONFIG في إعدادات Docker CLI.
لتطبيق ZimaOS قابل للتكرار، أدرج ملف Compose ضمن حزمة بطريقة صحيحة
يستخدم ZimaOS الحالي Docker Compose المعتاد لإعدادات التشغيل، وكتلة x-casaos في المستوى الأعلى لبيانات تعريف متجر التطبيقات. تحدد بيانات تعريف تطبيقات ZimaOS حقول الإصدار 2 الحالية.
يبقى مخطط Docker Compose المرجع الأساسي لإعدادات التشغيل.
لماذا تعذّر على واجهة المستخدم استخدام الصورة المحمّلة محليًا
يتوقع مسار تثبيت متجر التطبيقات مرجع صورة يمكنه حله عبر تعريف التطبيق. قد تكون الصورة المحلية المحمّلة يدويًا موجودة في Docker، ومع ذلك لا تستوفي متطلبات مسار تثبيت المتجر. بالنسبة إلى تطبيق منزلي خاص، يكون Compose المباشر أبسط؛ أما للتوزيع، فانشر الصورة في سجل أو أنشئ حزمة تطبيق ZimaOS مناسبة.
احتفظ ببيانات التطبيق على وحدة تخزين قابلة للكتابة
اربط قواعد البيانات والتحميلات وملفات الإعدادات بمسارات مضيف مستمرة. وتُعد متطلبات Portainer بديلًا لأحمال Docker التي تُدار يدويًا.
استخدم بروتوكول المتجر فقط عند الحاجة إلى وظائف المتجر
إذا كان الهدف تطبيقًا عائليًا واحدًا لقائمة التسوق، فإن Compose المباشر كافٍ. أما إذا كان الهدف توزيعًا عبر كتالوج قابل للتثبيت مع الأيقونات وبيانات التعريف والتحديثات، فاستخدم بنية متجر تطبيقات ZimaOS v2 الحالية. وتوفّر متطلبات تطبيقات ZimaOS سياق النشر.
