8 تطبيقات Self-Hosted تعمل أفضل على Proxmox بدلاً من Docker

Docker خيار ممتاز لمعظم تطبيقات Self-Hosted — لكن هناك مجموعة صغيرة منها تحتاج فعلاً إلى ما لا يوفّره سوى الـ Hypervisor.

لو بحثتَ باللغة العربية عن "Proxmox مقابل Docker"، ستجد غالباً شروحات تثبيت عامة لـ Proxmox، أو مقارنات نظرية بين المفهومين. لكن السؤال العملي الذي يواجهه أي شخص يبني Home Lab حقيقياً مختلف تماماً: أي تطبيقات بالتحديد يجب أن تخرج من Docker وتنتقل إلى Proxmox، ولماذا؟ هذا ما لم أجد إجابة واضحة عنه في أي مصدر عربي، وهذا بالضبط ما سنغطيه هنا.

بحسب خبرتي في تشغيل Home Lab لسنوات، نصيحة "حوّل كل شيء إلى Docker" صحيحة في 90% من الحالات — لكن هناك مجموعة صغيرة من التطبيقات تصبح أسوأ، لا أفضل، عندما تُحشر داخل حاوية (Container). السبب ليس نقص المعالج أو الذاكرة، بل أن هذه التطبيقات تحتاج وصولاً مباشراً للعتاد (Hardware)، أو نواة نظام تشغيل (Kernel) كاملة خاصة بها، أو طبقة شبكة لا يستطيع أي Container التحكم بها بالكامل.

في هذا الدليل سأستعرض التطبيقات المحددة التي لاحظتُ فيها شخصياً أن Proxmox — منصة Hypervisor مجانية ومفتوحة المصدر تجمع بين الأجهزة الافتراضية KVM، وحاويات LXC، وتخزين ZFS، والنسخ الاحتياطي المدمج — تتفوّق بوضوح على إعداد يعتمد على Docker فقط. سأشرح سبب كل حالة، والإعداد الدقيق في العتاد الذي يُوقِع معظم الناس أول مرة عندما يحاولون تمرير USB أو كرت الشاشة (Passthrough)، بالإضافة إلى قاعدة بسيطة تساعدك على الاختيار بين VM كاملة أو حاوية LXC — وهذا هو السؤال الذي أتلقاه أكثر من غيره.

أنا مصطفى أمان، وفي مدونة وادي التكنولوجيا أكتب أدلة عملية ومُختبَرة عن الشبكات، الفرْطَنة (Virtualization)، وأنظمة الاستضافة الذاتية (Home Labs) — بدون حشو، فقط ما نجح فعلاً معي عند تطبيقه بنفسي. لنبدأ.

لماذا Docker ليس الحل المناسب دائماً؟

Docker Compose، متاجر التطبيقات بضغطة واحدة، وتوزيعات لينكس المتخصصة في الحاويات جعلت الاستضافة الذاتية أسهل من أي وقت مضى. بالنسبة لغالبية التطبيقات — أداة لتدوين الملاحظات، مدير إشارات مرجعية، لوحة تحكم بسيطة — الحاوية هي الخيار الصحيح فعلاً: خفيفة، سريعة النشر، وسهلة التحديث.

المشكلة تظهر عندما يحتاج التطبيق واحداً من الأمور التالية، وهي أمور لا تستطيع الحاويات فعلها إطلاقاً، أو تفعلها بحلول بديلة (Workarounds) هشّة:

• لقطات كاملة (Snapshots) وتراجع فوري. ليس مجرد "أعد تشغيل الحاوية"، بل التراجع عن حالة نظام التشغيل بالكامل خلال ثوانٍ لو فشل تحديث ما.
• تمرير كرت الشاشة أو أجهزة PCI (GPU/PCI Passthrough). منح حِمل عمل واحد (Workload) وصولاً حصرياً وعلى مستوى التعريف (Driver) لكرت شاشة أو متحكّم USB، دون منازعة نظام التشغيل المضيف عليه.
• نواة وطبقة شبكة خاصة به. جدران الحماية، محاكيات الشبكات، وأدوات الفرْطَنة المتداخلة (Nested Virtualization) مصمَّمة لتمتلك شبكة الجهاز بالكامل، وليس مشاركتها بلطف مع نظام مضيف.
• ميزات على مستوى نظام الملفات. لقطات ZFS، النسخ المتماثل (Replication)، ومرونة التخزين التي تعمل أسفل طبقة الحاوية بالكامل.

الصدفة أن Proxmox يجمع KVM للفرْطَنة، حاويات LXC، تخزين ZFS، شبكات مُعرَّفة بالبرمجيات (SDN)، والنسخ الاحتياطي — كل ذلك في منصة واحدة، وهذا بالضبط سبب تكراره كإجابة جاهزة لهذه الحالات المحددة. فيما يلي التطبيقات التي وجدتُ فيها هذا الفرق مؤثراً فعلاً في الاستخدام اليومي — وليس نظرياً فقط.

جدول سريع: ما الذي يحتاجه كل تطبيق فعلاً من Proxmox؟

قبل أن تبدأ: فحص العتاد الذي يتجاهله الجميع

كل شرح تقريباً يقفز مباشرة إلى "خصّص كرت الشاشة للـ VM" دون ذكر الإعداد الوحيد المسؤول عن 90% من محاولات الـ Passthrough الفاشلة: دعم IOMMU (Input-Output Memory Management Unit). هذا هو ما يسمح لـ Proxmox بعزل جهاز PCI — كرت شاشة، متحكّم USB، كرت شبكة — ومنحه لـ VM واحدة حصرياً.

تأكّد دائماً من تفعيل IOMMU في BIOS جهازك المضيف قبل إعداد أي VM.

قبل محاولة تمرير GPU أو USB لأي تطبيق في هذا الدليل، تحقّق من:

• أن معالجك يدعم هذه الميزة. ابحث عن دعم Intel VT-d أو AMD-Vi — راجع صفحة مواصفات معالجك إذا لم تكن متأكداً.
• أنها مُفعَّلة في BIOS/UEFI، وليس فقط مدعومة. عادةً تكون مُطفأة افتراضياً وتختبئ تحت إعدادات "Advanced" أو "Chipset"، وتحمل غالباً اسم VT-d أو IOMMU أو SVM Mode.
• أنها مُفعَّلة داخل Proxmox نفسه، عبر تعديل إعدادات GRUB (intel_iommu=on أو amd_iommu=on) وإعادة التشغيل قبل لمس أي إعداد في الـ VM.

إذا لم تكن معتاداً على ضبط إعدادات BIOS/UEFI أو TPM من قبل، دليلنا حول أدوات فحص BIOS و TPM في Windows يشرح كيفية الوصول إلى هذه الإعدادات والتنقّل بينها بأمان.

8 تطبيقات Self-Hosted تعمل بشكل أفضل فعلاً على Proxmox

كل تطبيق في القائمة أدناه اصطدم بمشكلة محددة عندما شغّلته عبر Docker — تعيين USB غير مستقر، تعارض Drivers، أو طبقة شبكة لا تستطيع الحاويات امتلاكها ببساطة. إليك ما نقلته إلى Proxmox، ولماذا، وهل مكانه VM كاملة أم حاوية LXC.

1. Home Assistant OS — وصول مستقر للعتاد وتحديثات آمنة

تشغيل Home Assistant OS كـ VM على Proxmox يضمن تمرير USB مستقر لأجهزة تنسيق البيت الذكي.

بمجرد أن تتجاوز الإعداد الأساسي لـ Home Assistant، ستضيف تقريباً بالتأكيد جهاز تنسيق (Coordinator) USB لـ Zigbee أو Z-Wave أو Thread. Docker يستطيع تمرير جهاز USB تقنياً، لكن هذا التعيين يميل للتغيّر عند إعادة توصيل الجهاز، أو تحديث الحاوية، أو نقلها لمضيف جديد — لقد اختفت عصا Zigbee بصمت من حاوية بعد إعادة تشغيل روتينية أكثر من مرة معي.

Proxmox يُخصِّص جهاز USB أو PCI مباشرة لـ VM الخاصة بـ Home Assistant OS، فيتصرف الجهاز تقريباً كما لو كان يعمل على عتاد مخصص بالكامل. القيمة الأهم بنفس القدر: أخذ لقطة (Snapshot) كاملة للـ VM قبل تثبيت تكامل جديد أو تحديث نواة Home Assistant. لو تعطّل شيء ما وأفسد الأتمتة (Automations)، استعادة الحالة السابقة تستغرق ثوانٍ بدلاً من أمسية كاملة من أوامر التراجع المُحبِطة.

2. pfSense أو OPNsense — مختبر شبكات مُفرْطَن بالكامل

فرْطَنة pfSense أو OPNsense على Proxmox تمنحك تمرير كروت شبكة مباشراً وتراجعاً فورياً باللقطات.

تشغيل جدار الحماية (Firewall) داخل VM يبدو غير منطقي حتى تراه عملياً. مع عدة كروت شبكة أو تمرير PCI، يحصل pfSense و OPNsense على وصول مباشر لواجهات الشبكة الفعلية، مما يتيح لك بناء VLANs، اختبار إعدادات VPN، أو تشغيل مختبر شبكات افتراضي كامل بدون شراء عتاد إضافي.

اللقطات تجعل هذا منخفض المخاطر فعلاً: جرّب مجموعة قواعد جدار حماية عدوانية، ولو حجبتك عن شبكتك، تراجع عن الـ VM خلال ثوانٍ بدلاً من إعادة ضبط الراوتر يدوياً بالكامل. إذا كنت جديداً على مفاهيم جدار الحماية قبل الخوض في pfSense تحديداً، دليلنا الشامل حول جدار الحماية وأمن الشبكات يغطّي الأساسيات أولاً.

3. Jellyfin مع تمرير GPU — وداعاً لمشاكل الـ Drivers

التمرير الحصري لكرت الشاشة يُنهي تعارضات الـ Drivers التي تعاني منها إعدادات الترميز داخل الحاويات.

تسريع GPU يعمل أيضاً في Docker، لكنني أضعتُ أمسيات أكثر مما أحب الاعتراف به في مطاردة تعارض إصدارات الـ Driver بين المضيف والحاوية. تمرير كرت رسوميات Intel المدمج أو NVIDIA مباشرة إلى VM مخصصة لـ Jellyfin يمنحها وصولاً حصرياً للعتاد — دون مشاركة مكدس الـ Driver مع نظام التشغيل المضيف أو حاويات أخرى، وهذا يُزيل معظم مشاكل الصلاحيات والـ Codecs التي يواجهها الناس.

كما أنه يعزل مكدس الوسائط بالكامل: حزم الـ Codec، Drivers الترميز، والبرمجيات المساعدة تبقى داخل تلك الـ VM فقط. إذا انتقلت لعتاد جديد لاحقاً، نسخة احتياطية من Proxmox تستعيد البيئة كاملة — بما فيها الـ Drivers — دون إعادة ضبط أي شيء من الصفر.

4. Immich — حماية باللقطات قبل كل عملية إعادة فهرسة بالذكاء الاصطناعي

لقطات ZFS تحمي مكتبة صور Immich من تلف البيانات الوصفية أثناء مهام إعادة الفهرسة بالذكاء الاصطناعي.

Immich، بديل Google Photos الذاتي الاستضافة، يُعيد تشغيل مهام تعلّم آلي (Machine Learning) دورياً لإعادة فهرسة الوجوه والأشياء في كامل مكتبة صورك. هذا بالضبط النوع من العمليات الكبيرة التي يمكن أن يتلف فيها تحديث سيّئ أو كتابة تالفة في قاعدة البيانات أشهراً من البيانات الوصفية بهدوء. تشغيل Immich داخل حاوية LXC فوق تخزين ZFS يعني أنه بإمكانك أخذ لقطة للحاوية قبل أي ترقية إصدار كبيرة، والتراجع فوراً لو سارت إعادة الفهرسة بشكل خاطئ.

هذه فجوة لا أراها مغطاة في مكان آخر: معظم شروحات Immich تركّز على إعداد Docker Compose الأولي وتتجاهل ماذا يحدث عندما تُتلف إعادة فهرسة المكتبة الصور المصغّرة (Thumbnails) في منتصف العملية. عادة أخذ لقطة قبل الترقية تحل هذه المشكلة خلال ثوانٍ بدلاً من محنة استعادة كاملة من نسخة احتياطية.

5. Nextcloud — مرونة تخزين تنمو معك

تشغيل Nextcloud على Proxmox مع ZFS يتيح توسعة التخزين والنسخ المتماثل خارج الموقع بدون توقّف.

Nextcloud من التطبيقات التي تبدأ صغيرة ثم تتحوّل بهدوء إلى سحابتك الشخصية الكاملة. تشغيله على Proxmox مع ZFS كطبقة تحتية يعني أنك تستطيع توسيع التخزين دون توقّف، استخدام لقطات ZFS كطبقة أمان إضافية فوق نظام الإصدارات (Versioning) الخاص بـ Nextcloud نفسه، وإعداد نسخ متماثل عبر ZFS send/receive إلى جهاز ثانٍ للحصول على نسخة احتياطية خارج الموقع حقيقية — وهو أمر أصعب بكثير لإضافته لإعداد يعتمد على الحاويات فقط.

6. Kali Linux ومختبرات الأمان — بيئات معزولة قابلة للتخلّص

عزل Kali داخل VM على Proxmox يتيح اختبار الثغرات بأمان واستعادة حالة نظيفة خلال ثوانٍ.

اختبار الاختراق (Penetration Testing) وتحليل البرمجيات الخبيثة يحتاجان أمرين تعاني الحاويات معهما: وصول غير مقيَّد للـ Kernel، وعزل شبكي حقيقي. على Proxmox، تستطيع VM معزولة تعمل بـ Kali التواصل مع أهداف مصممة عمداً لتكون ضعيفة مثل Metasploitable أو OWASP Juice Shop داخل شبكة افتراضية خاصة لا تلمس شبكة الإنتاج (LAN) الخاصة بك أبداً.

اللقطات هي المكسب الحقيقي هنا. بعد تشغيل ثغرة أو تحليل عيّنة برمجية خبيثة، تستعيد حالة الـ VM النظيفة خلال لحظات بدلاً من التراجع اليدوي عن كل ما غيّره الاختبار — وهذا مهم جداً حين يكون "ما غيّره الاختبار" قد يشمل Rootkit.

7. GNS3 و EVE-NG — محاكاة شبكات بمستوى الشهادات الاحترافية

دعم الفرْطَنة المتداخلة في Proxmox يجعله مثالياً لتشغيل طوبولوجيا GNS3 و EVE-NG المعقّدة.

إذا كنت تستعد لشهادة في الشبكات أو تبني طوبولوجيا شركات في المنزل، يحتاج GNS3 و EVE-NG عادة فرْطَنة متداخلة، عدة محولات شبكة افتراضية، وهامشاً معقولاً من المعالج والذاكرة لكل مختبر. Proxmox يتعامل مع كل ذلك بشكل أصيل، ويمكنك تشغيل عدة مختبرات معزولة جنباً إلى جنب، كل منها بمحولاته الافتراضية وتخصيص العتاد الخاص به — ثم أخذ لقطة لطوبولوجيا معقّدة قبل امتحان تجريبي حتى لا يجبرك خطأ ما على إعادة بنائها من الصفر.

8. عناقيد Kubernetes — اختبار يحاكي بيئة الإنتاج في المنزل

استنساخ قوالب VM يتيح تجهيز عقد Kubernetes شبيهة بالإنتاج خلال دقائق بدلاً من ساعات.

توزيعات خفيفة مثل k3s تعمل بسلاسة على مضيف واحد أو حتى داخل الحاويات، لكن إذا كنت تتدرّب لسيناريوهات إنتاج حقيقية، فإن عنقود متعدد العقد على VMs منفصلة أكثر تمثيلاً للواقع بكثير. كل عقدة تحصل على نواتها الخاصة، موارد مخصصة، وشبكة مستقلة — أقرب لكيفية عمل عنقود حقيقي مما ستوفره عدة نُسخ k3s تتشارك مضيف Docker واحد.

قوالب (Templates) الأجهزة الافتراضية في Proxmox تجعل هذا عملياً وليس مُملاً: استنسخ صورة عقدة جاهزة خلال دقائق لتوسيع العنقود، وجرّب فئات التخزين (Storage Classes)، أو MetalLB، أو Longhorn دون القلق من كسر النسخة الوحيدة لديك من البيئة.

VM أم حاوية LXC؟ القاعدة التي أستخدمها فعلياً

هذا هو السؤال الذي أتلقاه أكثر من غيره بعد "كيف أصلح الـ Passthrough"، ومعظم الشروحات تمر عليه سريعاً. إليك الاختصار العملي، وليس التعريف الأكاديمي:

• اختر VM عندما يحتاج التطبيق نواته الخاصة، وصولاً مباشراً للعتاد (GPU، USB، PCI)، أو حين لا تثق به بما يكفي لمشاركة نواة مع باقي أحمال العمل لديك — جدران الحماية، ترميز الفيديو بمعالجة GPU، مختبرات الأمان، وأي شيء يعتمد على الفرْطَنة المتداخلة.
• اختر حاوية LXC عندما يكون التطبيق خدمة لينكس "مؤدَّبة" لا تحتاج عتاداً حصرياً — تبدأ أسرع، تستهلك جزءاً بسيطاً من الذاكرة، وتحصل رغم ذلك على حماية لقطات ZFS. Immich، Nextcloud، ومعظم تطبيقات الويب مناسبة تماماً هنا.
• لا تلجأ للـ VM "للاحتياط فقط". ارتكبتُ هذا الخطأ في بداياتي — تشغيل كل شيء كـ VM "احتياطاً" يهدر ذاكرة ستحتاجها لاحقاً للتطبيقات التي تستحقها فعلاً.

الانتقال الفعلي: الترحيل وتكلفة الموارد

الانتقال بخدماتك من Docker إلى Proxmox يثير سؤالين رئيسيين لدى معظم الناس: "هل سيستهلك هذا كل ذاكرة السيرفر؟" و"ما مدى صعوبة نقل بياناتي؟" دعنا نفصّل الإجابتين حتى تعرف بالضبط ما تتوقعه.

Docker مقابل LXC مقابل VM: التكلفة الحقيقية للأداء

إذا كنت مرتحلاً من Docker، فأكبر مخاوفك على الأرجح هو استهلاك الموارد الإضافي (Overhead). تشغيل كل شيء كـ VM سيستهلك كل ذاكرتك بسرعة، لكن LXC كفؤة بشكل مفاجئ. إليك التفصيل الواقعي:

• حاويات Docker: استهلاك إضافي بسيط جداً. تشارك نواة المضيف وتستخدم فقط الذاكرة التي يحتاجها التطبيق نفسه.
• حاويات Proxmox LXC: تقترب كثيراً من Docker. حاوية LXC تشغّل Debian قد تستهلك فقط 30-50 ميغابايت من الذاكرة عند الخمول. يمكنك تشغيل عشرات الحاويات بارتياح على عتاد متواضع.
• الأجهزة الافتراضية الكاملة KVM: استهلاك إضافي مرتفع. كل VM تحتاج نظام تشغيل كاملاً خاصاً بها (عادة 1-2 غيغابايت فقط للإقلاع) وتحجز الذاكرة المخصصة لها بالكامل. لهذا بالضبط قاعدة VM مقابل LXC أعلاه مهمة جداً.

حاويات LXC توفّر كفاءة قريبة من Docker مع تكامل أصيل مع ZFS واللقطات في Proxmox.

ما مدى صعوبة الترحيل من Docker؟

نقل تطبيق من Docker إلى حاوية LXC أو VM على Proxmox ليس مخيفاً كما يبدو، لكن لا يوجد زر سحري "تحويل". الخطوات العامة هي:

1. تصدير البيانات: خذ نسخة احتياطية من Volumes الخاصة بـ Docker وأي نسخ لقاعدة البيانات (مثل تصدير قاعدة بيانات PostgreSQL).
2. التجهيز في Proxmox: شغّل حاوية LXC أو VM الجديدة. أدوات مثل سكربتات Proxmox Helper الشهيرة تستطيع تثبيت خدمات مثل Nextcloud أو Jellyfin خلال ثوانٍ.
3. استيراد البيانات: انقل ملفاتك واستعد نسخ قاعدة البيانات داخل البيئة الجديدة.

رغم أنها تتطلّب بعض العمل اليدوي، فإن الفوائد طويلة المدى — اللقطات الأصيلة وتكامل Proxmox Backup Server (PBS) — تجعل جهد الترحيل لمرة واحدة يستحق العناء بوضوح.

5 أخطاء أراها متكررة عند الانتقال من Docker إلى Proxmox

1. تجاوز فحص IOMMU. غطّيناه أعلاه، لكن يستحق التكرار — هذا الإعداد الواحد يسبب فشل محاولات الـ Passthrough أكثر من كل الأسباب الأخرى مجتمعة.
2. تشغيل كل تطبيق كـ VM كاملة. أبسط ذهنياً، لكنك ستستهلك الذاكرة بسرعة. احتفظ بالـ VMs للتطبيقات التي تحتاج فعلاً عتاداً مخصصاً أو وصولاً للـ Kernel.
3. نسيان أخذ لقطة قبل الترقيات الكبيرة. الفكرة الكاملة من الانتقال إلى Proxmox هي شبكة الأمان — تخطّي عادة أخذ لقطة قبل تحديث محفوف بالمخاطر يُفرِغ الهدف من معناه.
4. عدم إعداد Proxmox Backup Server مبكراً. اللقطات تحميك من تحديث سيّئ؛ النسخ الاحتياطية تحميك من قرص تالف. تحتاج الاثنين معاً، ومن الأسهل بكثير إعداد PBS قبل أن يصبح لديك 15 VM تحتاج تغطيتها بأثر رجعي.
5. تمرير كرت الشاشة الوحيد في المضيف. لو خصّصت كرت الشاشة الوحيد لديك لـ VM، قد يفقد Proxmox نفسه إخراج الفيديو المحلي على ذلك الجهاز. استخدم كرت شاشة ثانوياً أو المدمج (iGPU) للتمرير إذا كنت تحتاج أيضاً استخدام المضيف مباشرة.

خلاصة القول

الميزة الحقيقية لـ Proxmox ليست أنه "أفضل من Docker" — بل أنه يتوقّف عن إجبار كل حِمل عمل على الدخول في نفس القالب. جدار الحماية يمتلك طبقة شبكته الخاصة، خادم الوسائط يحصل على وصول حصري لـ GPU، ومكتبة الصور تحصل على لقطات ZFS قبل كل عملية محفوفة بالمخاطر — بينما تطبيقات الويب البسيطة لديك تظل تعمل كحاويات LXC خفيفة تستهلك موارد بسيطة جداً.

لا تحتاج لترحيل كل شيء دفعة واحدة. ابدأ بأي تطبيق في هذه القائمة يسبب لك أكبر إزعاج في Docker الآن — بالنسبة لمعظم الناس، إما استقرار USB في Home Assistant أو صداع Drivers في Jellyfin — وابنِ من هناك.

الأسئلة الشائعة