كانت المشكلة الأصلية حقيقية في نموذج تطبيق ZimaOS لعامَي 2024–2025: إذ كان تثبيت تطبيق باستخدام latest يؤدي إلى حل هذا الوسم وقت التثبيت، لكن ZimaOS كان يحتفظ بعد ذلك بالإصدار الذي تم حله بدلًا من متابعة تغييرات السجل تلقائيًا خلف الوسم نفسه. أوضح Zima-Giorgio أن هذا السلوك كان مقصودًا لتحقيق الاستقرار، وحذّر مرارًا من أن فرض ترقية التطبيق قد يؤدي إلى تعطّله.
وقد تغيّر أمران منذ ذلك الحين. أولًا، قدّم ZimaOS 1.7 متجر التطبيقات 2.0، مع صفحة مخصصة لإدارة التطبيقات المثبتة وحالة التحديثات. ثانيًا، تظل دلالات Docker مهمة: فالحاوية قيد التشغيل لا تتحول تلقائيًا إلى الصورة الجديدة لمجرد أن وسم latest في السجل قد تغيّر. تتطلب الترقية دائمًا اكتشاف صورة متغيّرة وسحبها، ثم إعادة إنشاء الحاوية أو المكدس.
كان تصميم ZimaOS التاريخي يحلّ الوسم ثم يثبّت الإصدار
أوضح Giorgio أن latest كان فعّالًا عند تثبيت التطبيق، وبعد ذلك كان ZimaOS يثبت الإصدار. وكان الهدف من ذلك تقليل الأعطال المفاجئة الناتجة عن تغيّر الصور upstream دون علم المستخدم.
ظهرت المشكلة المجتمعية نفسها لاحقًا مع develop، وعلى الأرجح مع أي وسم مُسمّى قابل للتغيير، وليس latest وحده.
لا يعني latest في Docker مطلقًا «تحديث حاويتي قيد التشغيل تلقائيًا»
الوسم القابل للتغيير ليس سوى مؤشر في السجل. فإذا كان example/app:latest يشير إلى صورة جديدة غدًا، فستواصل الحاوية التي أُنشئت مسبقًا استخدام صورتها الحالية إلى أن تسحب آلية التحديث الصورة الجديدة وتعيد إنشاء الحاوية.
لذلك فإن «latest» و«التحديث التلقائي» مفهومان منفصلان حتى خارج ZimaOS.
استخدم المصدر وسوم إصدارات صريحة كحل بديل
أفاد CogZog بأنه غيّر وسم Immich يدويًا إلى رقم الإصدار المنشور، وتمكن من تحديث التطبيق إلى الإصدار v1.132.3. وقال Giorgio لاحقًا إن المستخدمين الذين يحتاجون إلى إصدار محدد يمكنهم تعديل حقل إصدار التطبيق وحفظه.
كان هذا حلًا بديلًا على مستوى المجتمع أو المستخدم، وليس دليلًا على أن تحديث كل تطبيق بشكل أعمى إلى أحدث صورة upstream آمن.
قد تتعطل التطبيقات متعددة الحاويات عند تحديث صورة واحدة فقط
يُعد Immich مثالًا جيدًا على ذلك: فقد تتطلب مكونات الخادم والتعلّم الآلي وقاعدة البيانات وذاكرة التخزين المؤقت عمليات ترحيل منسّقة. وقد يؤدي تعديل وسم واحد دون اتباع تعليمات الإصدار والترحيل الصادرة عن المشروع upstream إلى إنشاء مكدس مختلط غير متوافق.
أضاف ZimaOS 1.7 إدارة صريحة لتحديثات التطبيقات المثبتة
يعرض متجر تطبيقات ZimaOS الحالي التطبيقات المثبتة في صفحة إدارة واحدة، بما في ذلك حالتها وتوفّر التحديثات لها. وتتضمن حزم متجر التطبيقات 2.0 أيضًا بيانات وصفية للإصدار وتجزئات للمحتوى تُستخدم لاكتشاف تغييرات الحزمة.
راجع تجربة التحديث الحالية في متجر التطبيقات.
تختلف الجهة المسؤولة عن تحديث تطبيقات المتجر وCompose المخصّص
بالنسبة إلى حزمة من متجر التطبيقات، يقرر مشرف المتجر موعد نشر تحديث اختُبر. أما في مكدس Compose مخصّص، فأنت المشرف: تقرر وسم الصورة أو ملخصها، وتقرأ ملاحظات الإصدار upstream، وتسحب الصورة الجديدة، ثم تعيد إنشاء المكدس.
لا تتوقع من المتجر إعادة كتابة ملف Compose مخصّص أو ترحيل قاعدة بيانات مخصّصة تلقائيًا.
غالبًا ما يكون تثبيت إصدار صريح أكثر أمانًا للخدمات المهمة
بالنسبة إلى قواعد البيانات ومديري الصور وأنظمة التشغيل الآلي وغيرها من التطبيقات ذات الحالة، فإن استخدام وسم إصدار مختبَر أو ملخص صورة، إلى جانب نافذة ترقية مخطط لها، يتيح لك إعداد خطة للتراجع ويمنحك وقتًا لقراءة التغييرات التي قد تسبب أعطالًا.
أما الأدوات المؤقتة أو عديمة الحالة، فقد يكون اتباع وسم قابل للتغيير مقبولًا إذا كنت لا تزال تتحكم في توقيت السحب وإعادة الإنشاء.
الأسئلة الشائعة حول تحديث وسوم Docker
هل أساء مستخدم المصدر فهم latest في Docker تمامًا؟
لا. فقد كان ZimaOS يثبت بالفعل إصدار التطبيق الذي تم حله وفق التصميم التاريخي، لكن Docker نفسه يتطلب أيضًا سحب الصورة وإعادة إنشاء الحاوية لتحديث حاوية قيد التشغيل.
هل يتضمن ZimaOS الحالي صفحة لإدارة تحديثات التطبيقات؟
نعم. أضاف متجر التطبيقات 2.0 حالة تحديث التطبيقات المثبتة وإدارتها.
هل ينبغي لكل تطبيق اتباع latest تلقائيًا دائمًا؟
لا. فقد تؤدي التحديثات عبر الوسوم القابلة للتغيير إلى تغييرات معطِّلة، ولا سيما في التطبيقات ذات الحالة أو التطبيقات متعددة الحاويات.
