في يناير 2026، كان بإمكان المستخدمين الذين ثبّتوا تطبيقًا من متجر تطبيقات ZimaOS تغيير الإعدادات المكشوفة مثل المنافذ ومتغيرات البيئة ووحدات التخزين، لكن لم تكن لديهم صلاحيات التحكم نفسها على مستوى Compose التي تتوفر في حزمة يملكونها بأنفسهم. وأصبح ذلك مشكلة عند التعامل مع الإعدادات المتقدمة مثل تسميات Traefik، والشبكات المشتركة، والبرمجيات الوسيطة، أو نظام DNS الخاص بكل حاوية.
التحديث المهم هو أن خارطة طريق النقاش لم تعد تتحدث عن المستقبل فقط. فقد ذكرت IceWhale أنها تعيد هيكلة متجر التطبيقات لإضافة إمكانية تحرير ملفات Docker Compose بصيغة YAML، ثم أضاف ZimaOS 1.7.0 لاحقًا دعم YAML الأصلي.
لماذا كان تعديل تطبيقات متجر التطبيقات صعبًا في أوائل 2026
كان التفسير الذي قدّمه المجتمع هو أن التطبيقات المثبّتة من المتجر تُدار بواسطة ZimaOS. وقد تؤدي عملية تعديل ملف Compose المُنشأ خارج مسار الإدارة هذا إلى الكتابة فوق التغييرات عند إعادة النشر أو الترقية.
أما الحل العملي المؤقت للمستخدمين المتقدمين، فكان تثبيت الخدمة كحزمة Compose مخصصة، والاحتفاظ بمجلدات AppData الدائمة نفسها، ثم إدارة حزمة Compose بأنفسهم باستخدام أداة مثل Dockge أو Portainer.
تحتاج إعدادات الوكيل العكسي المتقدمة إلى تحكم على مستوى Compose
كان المستخدم الأصلي يريد تحديد تسميات Traefik، إضافة إلى طريقة لإجبار حاويات معيّنة على استخدام DNS الخاص بـ Cloudflare بدلًا من Pi-hole. وهذه أمور اعتيادية في Docker Compose، وليست مجرد إعدادات بسيطة لعنوان التطبيق أو منافذه.
وتوضح مواصفات متجر تطبيقات ZimaOS الحالية هذا الحد بوضوح: يجب وضع إعدادات التشغيل القياسية في Docker Compose، بينما توضع البيانات الوصفية الخاصة بمتجر ZimaOS في x-casaos.
أكدت IceWhale التخطيط لإضافة محرر YAML
أوضح Zima-Jerry أن الفريق يعيد هيكلة متجر التطبيقات وتجربة التثبيت بحيث يمكن أن يتعايش مسار تثبيت بسيط مع إمكانية تحرير ملفات Docker Compose بصيغة YAML تحريرًا متقدمًا.
ويُعد هذا الرد الرسمي أكثر موثوقية من الافتراض السابق الذي شاع بين أفراد المجتمع بأن تطبيقات المتجر لا يمكن تعديلها مباشرةً مطلقًا.
أضاف ZimaOS 1.7.0 دعم YAML الأصلي
بحلول يوليو 2026، أطلق متجر تطبيقات ZimaOS 2.0 إعادة تصميم لإدارة التطبيقات، إلى جانب دعم YAML الأصلي لتوفير إعداد أكثر مرونة للتطبيقات. كما يركّز ZimaOS الحالي حالة التطبيقات المثبّتة وتحديثاتها وإعداداتها الشائعة في صفحة إدارة التطبيقات.
يوضح العرض العام الحالي لمتجر التطبيقات كيفية إدارة التطبيقات المثبّتة الآن من واجهة تطبيقات ZimaOS المعاد تصميمها.
لا يعني دعم YAML الأصلي أن كل حزمة خارجية ستُدار تلقائيًا
يحسّن المحرر الجديد التحكم في التطبيقات التي يديرها ZimaOS، لكن لا ينبغي الخلط بين ذلك وبين امتلاك كامل الصلاحيات على حزم Compose العشوائية التي شُغّلت خارج نظام تطبيقات ZimaOS. ولا تزال تقارير الإصدار 1.7.x الحالية تميّز بين مجموعات Compose التي شُغّلت يدويًا والتطبيقات التي يديرها ZimaOS بنفسه.
حافظ على AppData عند تغيير نموذج الإدارة
إذا قررت نقل تطبيق عمدًا من حزمة مُدارة من المتجر إلى حزمة Compose تديرها بنفسك، فعادةً ما تكون البيانات المهمة موجودة في مجلداته الدائمة على المضيف. أنشئ نسخة احتياطية منها أولًا، ثم أعد إنشاء تعيينات وحدات التخزين والمنافذ وقيم البيئة وتبعيات قواعد البيانات نفسها قبل إزالة الحاوية القديمة.
لا تفترض أن إعادة إنشاء حاوية تنقل تلقائيًا كل إعداد أو سر خاص بـ ZimaOS.
الأسئلة الشائعة حول تعديل YAML لتطبيقات ZimaOS
هل كان تعديل Compose مباشرةً متاحًا عند نشر النقاش؟
ليس بالطريقة التي أرادها المستخدم. كان الحل البديل الذي اقترحه المجتمع هو استخدام Compose مخصص، بينما ذكرت IceWhale أن تطوير تعديل YAML مباشرةً جارٍ.
هل أضاف ZimaOS في النهاية إمكانية تعديل YAML أصليًا؟
نعم. أعلن ZimaOS 1.7.0 عن دعم YAML الأصلي ضمن إعادة تصميم متجر التطبيقات 2.0.
هل لا يزال ينبغي لي استخدام Dockge؟
قد يظل ذلك مناسبًا عندما تريد عمدًا امتلاك حزمة Compose مستقلة بدلًا من ترك ZimaOS يدير التطبيق.
هل يمكنني الاحتفاظ ببيانات التطبيق الحالية عند التبديل إلى Compose مخصص؟
غالبًا نعم، إذا حوفظ على المجلدات الدائمة للمضيف وأُعيد تعيينها بشكل صحيح، لكن احرص أولًا على نسخ البيانات احتياطيًا وتسجيل إعدادات الحاوية الأصلية.
