الإجابة المختصرة: إذا ظهر في CasaOS فجأة «فشل تحميل التطبيقات» بعد تحديث Docker، فتحقق من إصدار واجهة برمجة تطبيقات محرك Docker قبل إعادة تثبيت CasaOS. رفع Docker 29.0 الحد الأدنى لواجهة برمجة التطبيقات في البرنامج الخادم إلى v1.44، مما عطّل عملاء إدارة التطبيقات الأقدم في CasaOS الذين ما زالوا يطلبون إصدارًا أقدم من واجهة برمجة التطبيقات. ثم خفّض Docker 29.3 الحد الأدنى مجددًا إلى v1.40، لذا يعتمد الحل الصحيح على إصدار Docker المثبّت لديك فعليًا.
تحقق من إصدار Docker أولًا
شغّل:
إصدار Dockerاطّلع على إصدار الخادم وحقول إصدار واجهة برمجة التطبيقات. تتيح آلية تفاوض Docker على واجهة برمجة التطبيقات للعملاء والبرامج الخادمة الاتفاق على إصدار مشترك لواجهة برمجة التطبيقات، ولكن فقط ضمن الإصدارات التي لا يزال البرنامج الخادم يقبلها.
تغيّر هذا الحد في Docker 29. رفع Docker 29.0 الحد الأدنى لواجهة برمجة تطبيقات البرنامج الخادم إلى v1.44. وفي Docker 29.3.0، خُفّض الحد الأدنى إلى v1.40. لذلك يعتمد الحد الأدنى لواجهة برمجة تطبيقات Docker 29 على الإصدار.
| إصدار Docker | الحد الأدنى لواجهة برمجة تطبيقات المحرك | ما يعنيه ذلك بالنسبة إلى CasaOS |
|---|---|---|
| 29.0.x–29.2.x | v1.44 | قد يرفض العميل الأقدم لإدارة التطبيقات في CasaOS لأنه قديم جدًا. |
| 29.3.0+ | v1.40 | لم يعد الحد الأدنى الأصلي v1.44 هو العائق نفسه، لذا تحقّق من السجلات قبل تطبيق حل قديم. |
تأكد من أن عدم تطابق واجهة برمجة التطبيقات هو الخطأ الفعلي
لا تفترض أن كل متجر تطبيقات فارغ يمثل مشكلة توافق مع Docker 29. تحقق من سجل الخدمة:
journalctl -u casaos-app-management --no-pager -n 100يبدو الفشل الأساسي كما يلي:
إصدار العميل 1.43 قديم جدًا.
الحد الأدنى لإصدار واجهة برمجة التطبيقات المدعوم هو 1.44تُعدّ تلك الرسالة دليلًا قويًا على أن فشل واجهة المستخدم ناتج عن عدم توافق واجهة برمجة تطبيقات Docker، وليس عن مشكلة في كتالوج متجر التطبيقات. وقد أعادت تقارير متعددة عن CasaOS إنتاج العَرَض نفسه بعد ترقية Docker، بما في ذلك فشل تحديث Docker الأصلي.
لماذا قد يتعطل CasaOS بينما يظل Docker يعمل
لا يحل CasaOS محل Docker Engine. إذ تتصل خدمة إدارة التطبيقات فيه بـ Docker عبر Engine API. وقد تستمر حاويات Docker في العمل بصورة طبيعية بينما تفقد واجهة CasaOS القدرة على الاستعلام عنها أو إنشائها أو إدارتها.
ولهذا السبب قد تعمل أوامر مثل:
docker ps
docker imagesقد تظل تعمل حتى عندما يقول CasaOS إنه لا يستطيع تحميل التطبيقات. يُعد Docker CLI وخدمة إدارة التطبيقات في CasaOS عميلَي API منفصلين، ولا يطلبان بالضرورة إصدار API نفسه.
يُشرح الارتباط الأوسع بين CasaOS وDocker في إدارة CasaOS لـ Docker، حيث يُستخدم CasaOS كطبقة مرئية فوق التطبيقات القائمة على Docker.
إصلاح عمليات تثبيت Docker 29 الأقدم باستخدام تجاوز لـ API
بالنسبة إلى إصدارات Docker 29 التي لا تزال تتطلب API v1.44، يتمثل أحد الحلول البديلة المختبرة في خفض الحد الأدنى المقبول من البرنامج الخفي عبر systemd. ويستخدم إصلاح توافق CasaOS المُبلّغ عنه ما يلي:
sudo systemctl edit docker.serviceأضف:
[Service]
Environment=DOCKER_MIN_API_VERSION=1.24ثم أعد تشغيل Docker:
sudo systemctl daemon-reload
sudo systemctl restart dockerتحقّق من التجاوز:
systemctl show docker | grep DOCKER_MIN_API_VERSIONهذا تجاوز للتوافق، وليس سببًا للإبقاء على الخادم ضمن حزمة تطبيقات قديمة إلى أجل غير مسمى. فهو يسمح عمدًا لعملاء API الأقدم بالتواصل مع البرنامج الخفي.
تحقّق مما إذا كان المثبّت الحالي يعالج المشكلة بالفعل
أفاد مسؤولو صيانة CasaOS لاحقًا بأن برنامج التثبيت النصي قد حُدّث لتثبيت إصدار حالي من Docker Engine وتطبيق تجاوز لتوافق Docker API مع الإصدارات الأحدث. يظهر تحديث الصيانة هذا في تحديث توافق المثبّت.
إذا كان تثبيت CasaOS لديك أقدم من هذا التغيير، فقد يكون من الأنظف إعادة تشغيل المثبّت الرسمي الحالي بدلًا من الاستمرار في صيانة تجاوز يدوي إلى الأبد. انسخ بيانات التطبيقات المهمة والإعدادات المخصصة احتياطيًا قبل تغيير خادم موجود.
متى لا تستخدم الحل البديل القديم
إذا إصدار Docker إذا كان يعرض Docker 29.3 أو أحدث، وكان الحد الأدنى لواجهة برمجة التطبيقات هو v1.40 بالفعل، فلا تفرضه بشكل أعمى DOCKER_MIN_API_VERSION=1.24. افحص أولًا سجل إدارة تطبيقات CasaOS. فالخطأ المختلف يتطلب إصلاحًا مختلفًا.
فعلى سبيل المثال، يمكن أن تؤدي أعطال DNS، أو تعطل الوصول إلى السجل، أو تلف بيانات تعريف التطبيق، أو توقف خدمة CasaOS، إلى ظهور متجر التطبيقات فارغًا من دون أن تكون المشكلة متعلقة بإصدار واجهة برمجة التطبيقات.
تحقّق من CasaOS بعد الإصلاح
بعد إعادة تشغيل Docker، تحقّق من الطبقات الثلاث جميعها:
-
Docker: يُرجع الأمر
docker psالنتائج بشكل طبيعي. -
خدمة CasaOS: تكون
systemctl status casaos-app-managementنشطة، ولا تسجّل بعد الآن عدم تطابق في واجهة برمجة التطبيقات. - واجهة الويب: تُحمّل التطبيقات المثبتة ومتجر التطبيقات مجددًا.
إذا كان Docker يعمل لكن إدارة تطبيقات CasaOS لا تزال متوقفة، فأعد تشغيل تلك الخدمة بعد Docker:
sudo systemctl restart casaos-app-managementبالنسبة إلى المستخدمين الذين يقارنون حِزم التطبيقات، تعرض منصة تطبيقات ZimaOS الحالية نموذج التطبيقات بنقرة واحدة. إذا كنت تريد جهازًا صغيرًا بمعمارية x86 لاختبار Docker وCasaOS، فإن ZimaBoard 2 يدرج رسميًا CasaOS ضمن أنظمة التشغيل المتوافقة معه.
الأسئلة الشائعة
هل يتسبب Docker 29 دائمًا في تعطيل CasaOS؟
لا. رفع Docker 29.0 الحد الأدنى لواجهة Engine API إلى v1.44، لكن Docker 29.3.0 خفّضه إلى v1.40. تحقّق من إصدار Docker الدقيق ومن سجل CasaOS قبل اختيار حل بديل.
لماذا لا تزال حاوياتي قيد التشغيل؟
تتم إدارة الحاويات بواسطة Docker Engine. أما إدارة تطبيقات CasaOS فهي عميل منفصل. قد يفشل اتصال واجهة برمجة التطبيقات الخاصة بها بينما يستمر البرنامج الخفي والحاويات الحالية في العمل.
هل ينبغي أن أخفض إصدار Docker؟
ليس تلقائيًا. كان تجاوز إصدار واجهة برمجة التطبيقات حلًا ناجحًا لتثبيتات Docker 29 المتأثرة، وقد غيّرت إصدارات Docker اللاحقة الحد الأدنى المطلوب لواجهة برمجة التطبيقات مرة أخرى. لا يُعد خفض الإصدار إلا أحد الخيارات عندما يتعذر استعادة التوافق بطريقة سليمة.
ما السجل الذي يثبت أن هذه هي المشكلة نفسها؟
ابحث عن خطأ يفيد بأن واجهة برمجة تطبيقات عميل Docker قديمة جدًا، وأن البرنامج الخفي يتطلب واجهة برمجة التطبيقات v1.44 أو أحدث. من دون هذا الدليل، واصل استكشاف الأخطاء وإصلاحها بدلًا من افتراض أن المشكلة هي مشكلة Docker 29.
