الخلاصة: تشغيل لوحة Pterodactyl لا يعني إمكانية تثبيت Wings كتطبيق آخر على ZimaOS
للوحة وWings وظيفتان مختلفتان. فاللوحة هي طبقة التحكم عبر الويب، بينما Wings هو البرنامج الخدمي للعقدة الذي يتواصل مع Docker ويدير حاويات خوادم الألعاب ويتوقع تكاملًا مع Linux على مستوى المضيف. لذلك، فإن تشغيل اللوحة داخل Docker لا ينشئ تلقائيًا بيئة مدعومة لتثبيت Wings.
يتوقع Wings مضيف Linux متعدد الاستخدامات مع Docker
يسرد دليل تثبيت Wings الرسمي توزيعات Linux المدعومة، ويتطلب نظامًا قادرًا على تشغيل Docker. كما تحذر Pterodactyl من أن بعض بيئات المحاكاة الافتراضية المتداخلة أو القائمة على الحاويات قد تمنع Wings من العمل بشكل صحيح.
وتفترض وثائق إعداد Wings التحكم المباشر في البرنامج الخدمي للعقدة، والشبكات، وتكامل Docker.
لماذا يُعد ZimaOS الأصلي مضيفًا غير مناسب لتشغيل Wings مباشرةً
إن ZimaOS نظام Buildroot بطابع الأجهزة appliance. ولا تنطبق عليه تعليمات حزم المضيف المعتادة المكتوبة لـ Debian/Ubuntu بشكل مباشر. يوضح دليل مدير حزم ZimaOS سبب عدم كون apt/yum نموذج التوسعة المعتاد.
البنية الأنظف: تشغيل Wings داخل جهاز افتراضي يعمل بنظام Linux مدعوم
استخدم جهازًا افتراضيًا يعمل بنظام Debian أو Ubuntu، وامنحه قدرًا كافيًا من وحدة المعالجة المركزية وذاكرة الوصول العشوائي ومساحة SSD وإمكانية الوصول إلى الشبكة لتشغيل خوادم الألعاب. ثم ثبّت Docker وWings باستخدام الإجراء المتبع من المشروع الأصلي داخل ذلك الجهاز الافتراضي. يحافظ هذا على نموذج المضيف المتوقع من Pterodactyl بدلًا من تعديل النظام الأساسي لـ ZimaOS.
يفيد دليل متطلبات أجهزة مدير الأجهزة الافتراضية في تخطيط موارد الجهاز الضيف، كما يوضح الملخص التعريفي للأجهزة الافتراضية من Zima التوجه الحالي نحو المحاكاة الافتراضية.
حد أمني يجب وضعه في الاعتبار
يتحكم Wings في أحمال Docker وملفات خوادم الألعاب. تعامل مع واجهة برمجة تطبيقات العقدة الخاصة به وإمكانية الوصول إلى Docker باعتبارهما بنية تحتية إدارية. لا تكشف البرنامج الخدمي أو مقبس Docker مباشرةً على الإنترنت العام لمجرد تسهيل اتصال اللوحة.
