كتابة ubuntu:latest إلى حقل «تثبيت تطبيق مخصّص» في ZimaOS لا ينشئ تلقائيًا خادم Ubuntu صغيرًا يعمل دائمًا. فالصورة هي نظام ملفات حاوية Ubuntu مصغّر، وليست آلة افتراضية مُهيّأة مسبقًا بتسلسل إقلاع كامل، وعفريت SSH، ومدير خدمات، وتطبيق خلفي يعمل بالفعل.
يوضح هذا التمييز حالة المصدر في أكتوبر 2025. كان من الممكن سحب الصورة وإنشاء حاوية، لكنها لم تستمر في العمل بالطريقة التي توقعها المستخدم. ويعتمد الحل الصحيح على الهدف الفعلي: تشغيل تطبيق واحد في حاوية، أو تشغيل نظام تشغيل Debian/Ubuntu كامل وعام الأغراض داخل آلة افتراضية.
حاوية Docker ليست آلة افتراضية صغيرة
تحاكي الآلة الافتراضية بيئة حاسوب كاملة وتُقلع مكدس نظام التشغيل الخاص بها. أما الحاوية فتشارك نواة Linux الخاصة بالمضيف وتشغّل عملية واحدة أو أكثر معزولة في مساحة المستخدم الخاصة بها.
يرتكز نموذج Docker على العملية الرئيسية للحاوية. فإذا انتهت العملية الأمامية، تنتهي الحاوية التي تعمل في الخلفية أيضًا. لذلك تُبنى الحاويات عادةً حول خدمة طويلة الأمد، مثل خادم ويب أو قاعدة بيانات أو عفريت مزامنة أو عامل تطبيق.
صور Ubuntu وDebian الرسمية هي صور أساسية مصغّرة
تُبنى صورة Ubuntu الرسمية الحالية من نظام الملفات الجذري المصغّر الخاص بـ Canonical، ويصفها Docker بأنها تثبيت مصغّر لا جهازًا افتراضيًا كاملًا مُجهّزًا. وتستخدم صورة Debian الرسمية بالمثل نظامًا مصغّرًا minbase نظام الملفات الجذري.
إذا شغّلت إحداهما تفاعليًا باستخدام طرفية، فستبدو كأنها بيئة Linux صغيرة لأنك تحصل على صدفة. وعند خروج تلك الصدفة، قد لا تبقى أي خدمة أمامية تُبقي الحاوية قيد التشغيل.
اطّلع على معلومات صورة Ubuntu الأساسية الرسمية المُصانة أو معلومات صورة Debian الأساسية الرسمية المُصانة قبل التعامل مع أيٍّ منهما على أنه جهاز خادم مُجهّز مسبقًا.
لماذا قد تتوقف ubuntu:latest فورًا
يتوقع ZimaOS أن يحتوي تطبيق Docker المثبّت على عملية مستمرة طويلة الأمد وذات معنى. عادةً ما تكون صورة التوزيعة الأساسية أساسًا لصورة أخرى أو بيئة صدفة تفاعلية. وإذا لم تُهيَّأ أي عملية خدمة للبقاء بوصفها PID 1، فقد تخرج الحاوية بشكل طبيعي بدلًا من أن «تتعطّل».
تحقق من سجل الحاوية وحالة خروجها قبل افتراض أن ZimaOS فشلت في تثبيت الصورة. فالحاوية التي خرجت دون تهيئة أي تطبيق تمثل مشكلة مختلفة عن خدمة تبدأ ثم تطرح خطأ.
إذا كنت تحتاج إلى تطبيق واحد فقط، فابدأ من التطبيق
أوضح المستخدم الأصلي أنه لا يريد في الواقع آلة افتراضية كاملة، بل يريد تطبيقًا واحدًا—iDrive—والوصول إلى تخزين NAS. في هذه الحالة، يكون أفضل تصميم لـ Docker عادةً هو العثور على صورة مُصانة للتطبيق الفعلي أو إنشاء صورة صغيرة تثبّت ذلك التطبيق وتشغّله.
ينبغي أن تكشف الحاوية المنافذ ووحدات التخزين وبيانات الاعتماد والأجهزة التي يحتاج إليها التطبيق فقط. يجب أن توجد الملفات الدائمة في تخزين ZimaOS المعيّن، لا داخل طبقة الحاوية القابلة للتخلص منها فقط.
استخدم Docker Compose لخدمة حاوية حقيقية
اقترح الرد المجتمعي تعريف Compose مناسبًا بدلًا من إدخال ubuntu:latest واسم حاوية. وقد اتجهت ZimaOS الحالية إلى ذلك بشكل أكبر؛ إذ يمكنها استيراد Docker Compose وتحرير YAML وتشغيل مجموعات متعددة الحاويات مع التحكم في دورة حياتها.
تنص إرشادات IceWhale الحالية على أن إعدادات تشغيل الحاويات القياسية تنتمي إلى Docker Compose، بينما تنتمي البيانات الوصفية الخاصة بـ ZimaOS إلى x-casaos.
استخدم نموذج Compose الحالي في ZimaOS للتطبيقات المستضافة ذاتيًا بدلًا من اعتبار اسم صورة التوزيعة تعريفًا كاملًا للتطبيق.
تعيين تخزين NAS إلى الحاوية
إذا كان التطبيق يحتاج إلى الوصول إلى دليل واحد فقط، فعيّن مجلد ZimaOS الحقيقي هذا إلى الحاوية. ينبغي أن يشير جانب المضيف إلى مجلد نسخ احتياطي أو بيانات في مجموعة التخزين المقصودة، بينما يوفّر جانب الحاوية مسارًا بسيطًا يتوقعه التطبيق.
توضح ZimaOS الحالية كيفية تعيين تخزين المضيف إلى مسارات الحاوية. وعادةً ما يكون هذا أخف من تشغيل آلة Debian افتراضية كاملة لمجرد الوصول إلى مجلد واحد.
استخدم ZVM عندما يتوقع البرنامج جهاز Linux كاملًا
تكون الآلة الافتراضية الخيار الأنسب عندما يتوقع مُثبّت التطبيق أمورًا مثل:
- مدير حزم تقليدي ونظام ملفات نظام قابل للتعديل؛
- systemd أو عدة خدمات على مستوى نظام التشغيل؛
- سلوك على مستوى النواة لا يمكن توفيره بأمان عبر حاوية؛
- بيئة خادم Linux تقليدية تُدار عبر SSH؛
- برمجيات من مورّد يدعم صراحةً عمليات التثبيت على Ubuntu/Debian، لكنه لا يدعم Docker.
هذا يتوافق مع الرد الأول في المجتمع: إذا كان الهدف هو نظام تشغيل Debian أو Ubuntu مستقل، فاستخدم ZVM بدلًا من إجبار صورة حاوية أساسية على التصرف كجهاز افتراضي كامل.
بدلًا من ذلك، لا تثبّت التطبيق في نظام ملفات جذر ZimaOS
الانتقال من «تخرج حاوية Ubuntu» إلى «سأثبّت البرنامج باستخدام apt على ZimaOS نفسه» هو عادةً الاتجاه الخاطئ. يحتفظ ZimaOS الحالي بمعظم مجلدات النظام للقراءة فقط عن قصد، وليس مضيف Debian/Ubuntu عامًا مزودًا بـ apt كنموذج إدارة التطبيقات المعتاد.
توجد الحاويات والأجهزة الافتراضية تحديدًا حتى تظل تبعيات التطبيقات منفصلة عن النظام الأساسي لـ ZimaOS.
متى تظل صورة Debian/Ubuntu الأساسية مفيدة؟
هناك أسباب وجيهة للإنشاء انطلاقًا من ubuntu أو debianقد ينشر البرنامج المستهدف خطوات التثبيت لتلك التوزيعات فقط، أو قد تحتاج إلى مستودعات حزمها أثناء إنشاء الصورة.
في هذه الحالة، أنشئ Dockerfile أو صورة مدعومة بـ Compose تثبّت التطبيق وتعرّف أمرًا حقيقيًا يعمل في الواجهة الأمامية. لا تعتمد على الدخول يدويًا إلى طرفية، وتثبيت الحزم تفاعليًا، والأمل في أن تصبح الحاوية المعدّلة تطبيقًا دائمًا. قد تؤدي إعادة إنشاء الحاوية إلى فقدان التغييرات التي لم تُضمَّن في الصورة أو تُخزَّن في وحدات تخزين دائمة.
سياسة إعادة التشغيل لا تعوّض عن غياب العملية الرئيسية
تُعد سياسات إعادة تشغيل Docker مفيدة لخدمة حقيقية ينبغي أن تعود بعد إعادة التشغيل أو الخروج غير المتوقع. لكنها لا تحول جلسة طرفية انتهت بالفعل إلى خادم تطبيقات. إذا كان العمل المقصود من الحاوية قد اكتمل، فإن إعادة تشغيلها مرارًا لا تؤدي إلا إلى إنشاء حلقة.
اختر طبقة العزل الأصغر التي تتوافق مع البرنامج
- لدى التطبيق صورة Docker مُصانة بالفعل: استخدم تلك الصورة.
- يمكن حزم التطبيق باستخدام تبعيات Ubuntu/Debian: أنشئ حاوية تطبيقات مناسبة.
- يحتاج التطبيق إلى مضيف Linux تقليدي كامل: استخدم ZVM.
- تحتاج فقط إلى الوصول إلى التخزين: اربط مجلدات NAS المطلوبة بدلًا من إضفاء الطابع الافتراضي على القرص بأكمله.
الأسئلة الشائعة حول Ubuntu وDebian على ZimaOS
لماذا يُثبَّت ubuntu:latest لكنه لا يظل قيد التشغيل؟
لا تتحول صورة التوزيعة الأساسية تلقائيًا إلى خدمة تعمل دائمًا. تحتاج حاوية Docker إلى عملية رئيسية تظل قيد التشغيل.
هل يُعد ubuntu:latest جهازًا افتراضيًا كاملًا لـ Ubuntu؟
لا. إنها بيئة مستخدم مصغّرة للحاويات تشارك نواة المضيف.
هل ينبغي أن أستخدم ZVM لكل تطبيقات Linux؟
لا. عادةً ما يكون تطبيق Docker الحقيقي أخف وأسهل في الإدارة عندما يدعم البرنامج الحاويات.
متى يكون ZVM هو الخيار الأفضل؟
استخدم جهازًا افتراضيًا عندما يتوقع البرنامج خادم Ubuntu/Debian تقليديًا قابلًا للتعديل، مع خدمات على مستوى النظام أو افتراضات تثبيت لا تناسب الحاوية.
