لا تؤمّن HTTPS الخاص بلوحة تحكم ZimaOS كل تطبيقات Docker تلقائيًا. تحتاج التطبيقات التي تستمع على منافذها الخاصة إلى HTTPS أصلي أو وكيل عكسي. كما أن عنوان URL عشوائيًا لمستودع GitHub ليس مصدرًا صالحًا لمتجر تطبيقات ZimaOS؛ إذ يجب أن يتبع المستودع بروتوكول المتجر الحالي.
جمع نقاش المصدر في أبريل 2026 بين هذين السؤالين للمبتدئين. والإجابة الواضحة هي الفصل بينهما: استخدم وكيلًا عكسيًا لتوفير TLS للتطبيق، ومتجرًا متوافقًا أو Compose مخصصًا للبرامج غير المتاحة.
لماذا لا يؤمّن HTTPS الخاص بلوحة التحكم التطبيقات
يحمي إعداد HTTPS في ZimaOS اسم مضيف لوحة التحكم. أما تطبيق Docker الموجود على http://SERVER:8080 فيبقى خدمة منفصلة. يشرح دليل الوكيل العكسي لـ HTTPS هذا الحد الفاصل.
استخدم وكيلًا عكسيًا لتوفير HTTPS للتطبيق
https://app.example.com
↓
الوكيل العكسي / TLS
↓
http://app-container:portيمكن لـ Nginx Proxy Manager أو Caddy إنهاء اتصال TLS وإعادة توجيهه إلى تطبيق.
يختلف HTTPS المحلي عن HTTPS العام
للاستخدام داخل الشبكة المحلية فقط، يمكن أن يعمل DNS الداخلي مع مرجع تصديق محلي. أما النطاقات العامة فتحتاج إلى شهادات صالحة وقواعد مدروسة للوصول عن بُعد والأمان.
لماذا يعرض عنوان URL خام من GitHub خطأً
يتوقع متجر التطبيقات مخرجات متجر متوافقة، وليس شفرة مصدر عشوائية لتطبيق.
بروتوكول متجر تطبيقات ZimaOS الحالي
يعرّف دليل مطوّري متجر تطبيقات ZimaOS الحالي متجرًا من الإصدار v2 يتضمن store-config.json وsupported-languages.json وشجرة Apps/ ومخرجات dist/ المُنشأة.
لتطبيق واحد، استخدم Compose مخصصًا
إذا كنت تحتاج إلى مشروع واحد فقط، فلا داعي لإنشاء متجر كامل. استورد Docker Compose أو أنشئه مع المنافذ ووحدات التخزين الصحيحة والبيانات الوصفية x-casaos. يوثّق مرجع Docker Compose وx-casaos الحالي هذا التنسيق.
انتبه إلى المنفذين 80 و443
تحتاج الوكلاء العكسية عادةً إلى المنفذين 80 و443، وقد يكون ZimaOS يستخدمهما بالفعل. تحقق من الجهة المالكة للمنفذين قبل النشر.
اختر اسم الوكيل العكسي قبل إعداد TLS
حدّد ما إذا كان المستخدمون سيفتحون app.home.arpa أو نطاقًا خاصًا أو نطاقًا عامًا. تتحقق الشهادات من الأسماء، لذا فإن إعداد TLS قبل تحديد أسماء DNS غالبًا ما يؤدي إلى تحذيرات وإدخالات مكررة للوكيل.
لا توجّه تطبيقًا لا يمكنك الوصول إليه مباشرةً
قبل إضافة مضيف وكيل، افتح التطبيق الخلفي على عنوان HTTP المعتاد الخاص به. إذا كان http://SERVER:PORT معطّلًا أصلًا، فلن تؤدي إضافة HTTPS إلا إلى إخفاء المشكلة الأصلية خلف خطأ في الوكيل.
استخدم حزمة تطبيق واحدة قبل إنشاء متجر كامل
يفيد متجر تابع لجهة خارجية عندما تدير العديد من التطبيقات للتثبيت المتكرر. أما بالنسبة إلى تطبيق واحد غير متاح، فإن Compose المخصص أبسط للاختبار والتحديث والمراجعة. أنشئ مستودعًا فقط عندما تحتاج إلى توزيع الكتالوج والبيانات الوصفية والأصول والتحديثات القابلة للتكرار.
تحقق من Compose قبل النشر
تتوقع وثائق مطوّري ZimaOS الحالية ملف Docker Compose صالحًا بالإضافة إلى البيانات الوصفية x-casaos في المستوى الأعلى. اختبر حزمة Compose أولًا، ثم أضف البيانات الوصفية للكتالوج؛ ولا تحاول تصحيح بيئة تشغيل الحاويات وتغليف المتجر في الوقت نفسه.
أبقِ واجهة إدارة الوكيل خاصة
إذا نشّرت Nginx Proxy Manager أو وكيلًا عكسيًا آخر، فيجب أن تبقى واجهة الإدارة على الشبكة المحلية أو شبكة VPN خاصة. ينبغي ألا تصل حركة المرور العامة إلا إلى مستمعي HTTP/HTTPS المقصودين للوكيل، لا إلى منفذ الإدارة.
وبالمثل، لا تكشف تطبيقًا خاصًا للعامة لمجرد أن لديك الآن شهادة صالحة. يحمي TLS البيانات أثناء النقل، لكنه لا يحل محل المصادقة أو التحكم في الوصول إلى الشبكة.
الأسئلة الشائعة
هل يغطي HTTPS الخاص بـ ZimaOS جميع التطبيقات؟
لا. تحتاج كل نقطة نهاية لتطبيق إلى HTTPS خاص بها أو إلى وكيل عكسي.
هل يمكنني إضافة أي مستودع GitHub إلى متجر التطبيقات؟
لا. يجب أن يكون متجرًا متوافقًا أو تطبيقًا مُغلّفًا بصيغة Compose.
هل أحتاج إلى نطاق عام لاستخدام HTTPS محليًا؟
لا. يمكن أن يعمل DNS الداخلي مع شهادات محلية موثوقة.
ما أسهل طريقة لتثبيت تطبيق واحد غير متاح؟
استخدم تطبيق Docker Compose مخصصًا وفق الصيغة الحالية.
