نعم، من الممكن استخدام وكيل عكسي على ZimaOS. والقيْد الحقيقي في هذا المصدر لا يتعلق بشبكات Docker نفسها، بل بطبقة سهولة الاستخدام المحيطة بالتطبيقات المثبّتة عبر الواجهة الرسومية. يعمل Traefik بأفضل صورة عندما تكون لكل خدمة تسميات محددة، وأسماء خدمات Compose متوقعة، وشبكات Docker مشتركة. وتصبح هذه الضوابط أسهل بكثير عند إنشاء الحزمة باستخدام Compose بدلًا من تثبيت التطبيق عبر نموذج واجهة رسومية مبسّط.
لذلك يوصي الرد الأصلي من المجتمع باستخدام Nginx Proxy Manager لمعظم مستخدمي ZimaOS الذين يفضلون الواجهة الرسومية، واستخدام Traefik للمستخدمين المستعدين لنشر التطبيقات المعنية باستخدام Compose. هذه إرشادات مجتمعية وليست بنية رسمية للوكيل العكسي من IceWhale.
لماذا يبدو Traefik معقدًا مع التطبيقات المثبّتة عبر الواجهة الرسومية
يعتمد سير عمل Traefik الأقوى على الاكتشاف التلقائي عبر Docker باستخدام تسميات مثل أجهزة التوجيه، والخدمات، ونقاط الدخول، وقواعد TLS. وإذا كانت واجهة التطبيق لا تتيح إضافة تسميات مخصصة، أو كانت أسماء الحاويات مُنشأة تلقائيًا أو غير ملائمة، فسيفقد Traefik قدرًا كبيرًا من هذه الأتمتة.
يعيد Compose التحكم الكامل
يدعم متجر تطبيقات ZimaOS 1.7 الحالي الإصدار الأصلي باستخدام YAML، كما تتعامل وثائق مطوري ZimaOS مع Docker Compose القياسي باعتباره نموذج إعداد وقت التشغيل. ويتيح لك Compose تحديد ما يلي:
- أسماء خدمات ثابتة؛
- شبكات مخصصة؛
- تسميات Traefik؛
- منافذ المضيف والحاوية بشكل صريح؛
- وحدات التخزين وسياسة إعادة التشغيل.
استخدم نموذج Compose الحالي في ZimaOS.
لماذا يُعد Nginx Proxy Manager أسهل
لا يتطلب Nginx Proxy Manager أن يحتوي كل تطبيق خلفي على تسميات اكتشاف. يمكنك إنشاء مضيفات وكيلة يدويًا وتوجيهها إلى اسم حاوية أو عنوان IP ثابت، أو إلى مضيف ZimaOS مع المنفذ المنشور للتطبيق.
قد يكون هذا الإعداد اليدوي أقل أناقة على نطاق واسع، لكنه أسهل في بيئة مختلطة تضم تطبيقات متجر التطبيقات وحزم Compose مخصصة.
خطط للمنفذين 80 و443 قبل تشغيل الوكيل
قد تشغل واجهة الويب الخاصة بـ ZimaOS وإعدادات HTTPS المنافذ القياسية للويب. ولا يمكن لوكيل عكسي الارتباط بعنوان IP ومنفذ على المضيف مستخدمين مسبقًا من عملية أخرى.
إما أن تنقل واجهة الويب في ZimaOS إلى منفذ آخر، أو تستخدم واجهة أو عنوان IP آخر، أو تنشر الوكيل عمدًا على منافذ خارجية مختلفة.
تتجنب شبكات Docker المشتركة التوجيه غير الضروري عبر المضيف
إذا كان الوكيل والتطبيق المستهدف يشتركان في شبكة Docker يحددها المستخدم، فوجه الطلبات مباشرة إلى اسم الخدمة أو الحاوية والمنفذ الداخلي. ويُبقي ذلك حركة المرور داخل Docker، ويجنبك الاعتماد على منافذ المضيف المنشورة.
أما بالنسبة إلى تطبيقات الواجهة الرسومية التي يتعذر التحكم في شبكتها بطريقة واضحة، فلا يزال من الممكن استخدام التوجيه عبر عنوان IP للمضيف والمنفذ المنشور.
توجيه لوحة تحكم ZimaOS خيار منفصل
لا توجه كل مضيف وكيل إلى عنوان IP الخاص بـ ZimaOS افتراضيًا. استخدم هذا المصدر الخلفي فقط عندما تريد عمدًا توجيه واجهة الويب في ZimaOS نفسها.
لا يجعل الوكيل العكسي التطبيق آمنًا للنشر تلقائيًا
لا تعمل شهادة HTTPS عامة إلا على تشفير الاتصال. وقد تظل التطبيقات الحساسة بحاجة إلى المصادقة، والمصادقة متعددة العوامل، والبرمجيات الوسيطة للتحكم في الوصول، وتقييد عناوين IP، أو إتاحة الوصول عبر VPN فقط.
الأسئلة الشائعة حول الوكيل العكسي في ZimaOS
هل استخدام الوكيل العكسي مستحيل على ZimaOS؟
لا. يوضح رد المجتمع في المصدر أنه ممكن؛ وتتمثل الصعوبة غالبًا في بيانات التطبيقات المثبّتة عبر الواجهة الرسومية، والشبكات، والمنافذ المشغولة.
ما الخيار الأسهل للتطبيقات الرسومية المختلطة؟
يُعد Nginx Proxy Manager أسهل عمومًا، لأنه يمكن إعداده يدويًا دون الحاجة إلى تسميات Traefik لكل تطبيق.
متى يكون Traefik الخيار الأنسب؟
عندما تكون حزمة التطبيقات منشورة باستخدام Compose، بحيث تكون التسميات وأسماء الخدمات والشبكات تحت سيطرتك.
