حاويات النظام في Incus على VPS: الإعداد والمشكلات

ما هي حاوية النظام في Incus

تمنحك حاويات النظام في Incus على VPS جهازاً كاملاً بنظام init خاص به وحسابات مستخدمين خاصة به، وليست عملية واحدة مرفقة بنظام ملفات. تقلع الحاوية، وتشغّل init بالمعرّف PID 1، وتستجيب لـ systemctl. وهي تشارك نواة المضيف، لذلك ليست آلة افتراضية. أما كل ما يقع فوق النواة فيعمل كما لو كان جهازاً واحداً.

Incus هو النسخة المتفرعة التي يديرها المجتمع من LXD، وتتم صيانته ضمن مشروع Linux Containers. أمر العميل هو incus. ويمكنه أيضاً تشغيل آلات افتراضية فعلية عبر QEMU عند تمرير --vm، لكن حاوية النظام هي السبب الذي يدفع معظم المستخدمين إلى تثبيته، وهي ما يغطيه باقي هذا الدليل.

لماذا تضلّل مقارنات Docker المستخدمين

يغلّف Docker عملية واحدة. بينما يغلّف Incus نظام تشغيل واحداً. توضّح وثائق Incus هذا الفرق مباشرة: "تغلّف حاويات التطبيقات (كما في Docker، على سبيل المثال) عملية أو تطبيقاً واحداً. أما حاويات النظام، فتحاكي نظام تشغيل كاملاً، على غرار النظام الذي قد تشغّله على خادم أو داخل جهاز افتراضي."

يغيّر هذا الفرق طريقة تعاملك مع الحاوية يومياً.

• لا تحتوي صورة Docker على init، لذلك يفشل `systemctl` داخلها. أما حاوية Incus فتشغّل نظام init، ولذلك تعمل الخدمات والمؤقتات بالطريقة نفسها التي تعمل بها على خادم.
• يُفترض أن تحذف حاوية Docker وتعيد إنشاءها من Dockerfile. أما حاوية Incus فيُفترض أن تحتفظ بها، وتثبّت تحديثاتها، وتنشئ لقطات لها.
• صورة Docker هي ناتج بناء تدفعه إلى registry. أما مثيل Incus فهو حالة مخزّنة على القرص داخل storage pool، وتنقله باستخدام `incus export`.
• يعزل Docker حمولة عمل. أما Incus فيعزل جهازاً، ولذلك يمكن لحاوية واحدة أن تحتوي على عدة حمولات عمل وحسابات مستخدمين متعددة.

يمكنك تشغيل Docker داخل حاوية نظام Incus. لكنك لن تشغّل Incus داخل حاوية تطبيق Docker. إذا كان ما تريده فعلاً هو عملية واحدة لكل حاوية مع خطوة بناء للصورة، فاقرأ أولاً مقارنة Podman وDocker على VPS. أما إذا كنت تريد kernel منفصلاً لكل حمولة عمل بدلاً من kernel مشترك، فمقال Firecracker microVMs على VPS يتجه إلى الخيار المعاكس.

هل سيعمل Incus داخل VPS؟

يعتمد ذلك على نوع المحاكاة الافتراضية في VPS وعلى نواته، لذلك تحقّق من الأمرين قبل تثبيت أي شيء. لا تعتمد على صفحة التسويق لدى مزوّد الخدمة. شغّل هذه الأوامر الأربعة على الخادم.

systemd-detect-virt
uname -r
stat -fc %T /sys/fs/cgroup
cat /sys/fs/cgroup/cgroup.controllers

systemd-detect-virt طباعة kvm أو qemu تعني أن VPS لديك آلة افتراضية ذات نواة خاصة بها. هذه هي الحالة السهلة، لأن Incus يتصرف عندها كما يتصرف على جهاز فعلي. أما طباعة lxc أو lxc-libvirt أو openvz فتعني أن VPS لديك حاوية تشارك نواة مزوّد الخدمة. حاويات Incus داخلها هي حاويات متداخلة، ولا يعمل التداخل إلا إذا فعّله مزوّد الخدمة لحاويتك. لا يمكنك تفعيله من الداخل، لأن الإعداد موجود على المضيف الذي لا تتحكم فيه.

يجب أن تطبع stat -fc %T /sys/fs/cgroup القيمة cgroup2fs. أي قيمة أخرى تعني أن الخادم يستخدم تخطيط cgroup (مجموعة تحكم) من الإصدار v1 أو تخطيطاً هجيناً، وهو تخطيط لا يستهدفه Incus الحالي.

يعرض cat /sys/fs/cgroup/cgroup.controllers وحدات تحكم مجموعة التحكم المفوّضة لك. توثّق Incus أن blkio وcpuset وdevices وfreezer وmemory وpids مطلوبة. في VPS متداخل، تكون هذه القائمة غالباً أقصر منها في KVM، لأن مزوّد الخدمة يختار ما يمرّره إليك. وحدة التحكم الغائبة عن ذلك الملف هي وحدة لا يستطيع Incus استخدامها، ولذلك لا يتوفر لك حدّ المثيلات الذي يعتمد عليها.

أصبح إصدار النواة أهم مما كان عليه سابقاً. اعتباراً من August 2026، يذكر توثيق Incus حدّين أدنى مختلفين للفرعين اللذين يحافظ عليهما المشروع الرئيسي. يذكر فرع 6.0 LTS (الدعم طويل الأمد): "الحد الأدنى لإصدار النواة المدعوم هو 5.4." ويذكر فرع stable الحالي: "الحد الأدنى لإصدار النواة المدعوم هو 6.12." توفّر Ubuntu 24.04 حزم سلسلة 6.0 LTS في مستودعها الخاص، وتقرنها بنواة 6.8، وهو تركيب مدعوم. أما تثبيت الإصدار stable الحالي من المستودع الرئيسي على نواة 6.8 نفسها فيضعك دون الحد الأدنى الموثّق، لذلك اقرأ uname -r قبل اختيار مستودع.

إذا كان هدفك تشغيل آلات افتراضية كاملة بدلاً من الحاويات، فالقيد مختلف وأصعب. راجع المحاكاة الافتراضية المتداخلة على VPS لمعرفة ما إذا كان VPS لديك يستطيع إتاحة /dev/kvm أصلاً، وراجع Proxmox مقابل VPS مستأجر في الحالة التي تملك فيها العتاد.

ثبّت Incus على Ubuntu أو Debian

تتضمن Debian 13 وUbuntu 24.04 والإصدارات الأحدث Incus في مستودعاتها الخاصة.

sudo apt update
sudo apt install -y incus

في Debian، يثبّت incus-base دعم الحاويات من دون مكونات الآلات الافتراضية. في Ubuntu، أضف qemu-system إذا أردت أيضاً مثيلات --vm.

إذا كنت تريد إصداراً أحدث من الإصدار المتوفر في توزيعتك، فالحزم upstream موجودة في pkgs.zabbly.com. هذه الأوامر مأخوذة من ملف README الخاص بالمشروع في مستودعه.

sudo apt update && sudo apt install -y curl
sudo mkdir -p /etc/apt/keyrings/
sudo curl -fsSL https://pkgs.zabbly.com/key.asc -o /etc/apt/keyrings/zabbly.asc
sudo sh -c 'cat <<EOF > /etc/apt/sources.list.d/zabbly-incus-stable.sources
Enabled: yes
Types: deb
URIs: https://pkgs.zabbly.com/incus/stable
Suites: $(. /etc/os-release && echo ${VERSION_CODENAME})
Components: main
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/zabbly.asc
EOF'
sudo apt-get update
sudo apt-get install -y incus

بعد ذلك، امنح مستخدمك صلاحية الوصول إلى socket الخاص بالـdaemon.

sudo usermod -aG incus-admin "$USER"
newgrp incus-admin
incus info

يعني عرض إعدادات الخادم بواسطة incus info أن socket يعمل. ويعني خطأ الصلاحيات أن تغيير المجموعة لم يصل إلى shell الحالي، ويعالج newgrp incus-admin ذلك في shell الحالي، بينما يعالج تسجيل الدخول من جديد الأمر بصورة صحيحة. تعامل مع الانضمام إلى incus-admin على أنه يعادل امتلاك صلاحيات root على المضيف، لأن الوصول إلى ذلك socket يمنح تحكماً كاملاً في daemon يعمل بصفة root. تنشئ بعض التوزيعات أيضاً مجموعة incus عادية لتوفير وصول مقيّد للمستخدمين.

هيّئ الـdaemon الآن.

sudo incus admin init

أجب عن الأسئلة بدلاً من استخدام incus admin init --minimal. يختار المسار الأدنى برنامج تشغيل التخزين dir، ويتناول القسم التالي سبب استمرار تأثير هذا الاختيار عليك.

شغّل شيئاً وتحقق من أنه يعمل.

incus launch images:debian/13 web
incus list
incus exec web -- bash

يجب أن يعرض incus list أن web هو RUNNING وله عنوان IPv4 على الشبكة الفرعية incusbr0. يعني غياب العنوان أن DHCP، أي بروتوكول التهيئة الديناميكية للمضيف، لم يكتمل؛ ويتناول قسم الشبكات هذه الحالة. تطبع الحاوية التي تفشل في التشغيل سبب الفشل في incus info web --show-log، بينما تظهر الأعطال على مستوى الـdaemon في sudo journalctl -u incus -n 50. على VPS حيث أعاد systemd-detect-virt القيمة lxc أو openvz، يكون هذا التشغيل الاختبار الفعلي لمعرفة ما إذا كان nesting متاحاً لك.

أهمية وحدة التخزين الافتراضية

تحدد وحدة التخزين ما إذا كانت اللقطة فورية أو نسخة كاملة من قرص الحاوية. وهذا هو الخيار الوحيد أثناء التثبيت الذي لا يمكنك تغييره لاحقاً بتكلفة منخفضة.

يدعم Incus كلاً من dir وbtrfs وlvm وzfs وCeph وعدة برامج تشغيل بعيدة. في VPS ذي قرص واحد، ينحصر الخيار الفعلي بين dir وbtrfs.

يخزّن برنامج التشغيل dir كل حاوية على شكل ملفات ومجلدات عادية ضمن /var/lib/incus. وتوثّقه Incus على أنه «أبطأ بكثير من جميع برامج التشغيل الأخرى»، لأنه يضطر إلى فك ضغط كل صورة وإنشاء نسخ فعلية بدلاً من الإشارة إلى كتل مشتركة. تنشئ لقطة حاوية بحجم 4 GiB مقدار 4 GiB من البيانات، وتستغرق المدة نفسها التي يستغرقها cp -a. تعمل حصص القرص فقط على ext4 أو XFS مع تفعيل حصص المشاريع على مستوى نظام الملفات. وهذا غير مفعّل افتراضياً في معظم صور VPS، لذلك قد لا يكون لحد القرص في مجموعة dir أي تأثير.

يستخدم btrfs وzfs آلية النسخ عند الكتابة، ولذلك تسجّل اللقطة الكتل التي تغيّرت فقط بعدها. وتسمّي Incus هذين الخيارين وحدتي التخزين الموصى بهما. وتصبح اللقطات شبه فورية. تعمل حصص القرص من خلال دعم نظام الملفات نفسه للحصص.

تمنحك معظم خطط VPS قرصاً واحداً من دون قسم إضافي، لذلك ضع المجموعة في ملف loop. ينفّذ Incus ذلك تلقائياً عندما لا تحدد source=.

sudo apt install -y btrfs-progs
incus storage create fast btrfs size=30GiB
incus profile device set default root pool=fast
incus launch images:debian/13 web2 -s fast

من دون size=، تستخدم المجموعة المدعومة بملف loop نسبة 20% من المساحة الحرة على القرص، بحد أدنى قدره 5 GiB وحد أقصى قدره 30 GiB. اضبط هذه القيمة عمداً. ملف loop هو ملف على نظام الملفات الجذر، لذلك تشترك المجموعة والمضيف في المساحة الحرة نفسها. وهذا يعني أن امتلاء المجموعة يملأ قرص المضيف.

يُعد ZFS على Debian وUbuntu وحدة DKMS بدلاً من وحدة مدمجة في النواة، لذلك يُعاد بناؤه عند كل ترقية للنواة، وقد يفشل بناؤه بعد إحدى هذه الترقيات. على خادم لا تراقبه يومياً، يكون btrfs أقل احتياجاً إلى الصيانة من الخيارين.

أوضاع الشبكات الثلاثة، وما يكشفه كل وضع

ينشئ incus admin init جسراً مُداراً باسم incusbr0 ويضع كل instance جديد عليه. هذه إحدى الطرق الثلاث لربط container، أما الطريقتان الأخريان فموجودتان لأن الطريقة الأولى تخفي containers خلف NAT ‏(ترجمة عناوين الشبكة).

الجسر المُدار

يحصل incusbr0 على شبكة فرعية خاصة. يحتفظ المضيف بأول عنوان فيها ويعمل كبوابة. ويشغّل Incus خدمتي DHCP وDNS ‏(نظام أسماء النطاقات) عليها. تغادر حركة المرور الصادرة عبر العنوان العام للمضيف بعد تطبيق source NAT. لا يمكن لأي اتصال من خارج المضيف الوصول إلى container حتى تسمح بذلك. أعد توجيه منفذ باستخدام proxy device.

incus config device add web http proxy listen=tcp:0.0.0.0:8080 connect=tcp:127.0.0.1:80 nat=true

يُجري nat=true إعادة التوجيه باستخدام قواعد netfilter بدلاً من تمرير الاتصال عبر اتصال منفصل في userspace، لذلك يبقى العنوان الحقيقي للعميل ظاهراً في سجلات container. لا يدعم Incus هذا الوضع إلا عندما يكون المضيف هو بوابة instance، وهذا هو وضع incusbr0 تحديداً.

macvlan

يحصل container على عنوان MAC ‏(التحكم بالوصول إلى الوسائط) خاص به على الشبكة الفعلية للمضيف. يفشل هذا في معظم منصات VPS، لأن منفذ المحول الافتراضي يكون مرتبطاً بعنوان MAC الخاص بـVM، ويسقط الإطارات القادمة من أي عنوان آخر. وهناك قيد ثانٍ يسبب مشكلات حتى في البيئات التي يعمل فيها. توضح وثائق Incus أن "أجهزة macvlan، رغم قدرتها على الاتصال بعضها ببعض وبالعالم الخارجي، لا تستطيع الاتصال بجهازها الأب. وهذا يعني أنه لا يمكنك استخدام macvlan إذا احتجت في أي وقت إلى أن تتصل instances نفسها بالمضيف."

Routed

هذا هو الوضع الذي يعمل عادةً على VPS مع عناوين إضافية. توضح وثائق Incus أن الجهاز "ينشئ زوجاً من الأجهزة الافتراضية لربط المضيف بـinstance، ويُعدّ static routes وإدخالات proxy ARP/NDP للسماح لـinstance بالانضمام إلى شبكة واجهة parent محددة". ARP هو بروتوكول تحليل العناوين. يحتفظ container بعنوان عام. ويرد المضيف على ARP نيابةً عنه، ولذلك لا يرى مزود الخدمة سوى عنوان MAC الخاص بالمضيف.

incus config device add web eth0 nic nictype=routed parent=enp1s0 ipv4.address=203.0.113.20

خذ اسم واجهة parent من ip route show default. تستخدم الصور الحالية أسماء مثل enp1s0 أو ens3، ونادراً ما تستخدم eth0. يؤدي تسمية الجهاز باسم eth0 إلى تجاوز الجهاز الذي يوفّره ملف التعريف default، لذلك ينتهي الأمر بـcontainer على الواجهة الموجّهة بدلاً من الجسر. تحقق من النتيجة من داخل container باستخدام ip a وip route.

لماذا تمكّنت حاوية من الوصول إلى خدمة على المضيف

تستخدم الحاوية على incusbr0 مساحة أسماء شبكة خاصة بها. لكنها لا تملك حدّاً لجدار ناري يفصلها عن المضيف. يوجد المضيف على تلك الجسور باستخدام عنوان البوابة، لذلك يكون جاراً يمكن الوصول إليه مباشرةً من داخل الحاوية، وتستجيب هناك كل خدمة على المضيف مرتبطة بـ0.0.0.0.

تحقق من ذلك بنفسك. على المضيف، اعرض المنافذ التي تستمع إليها الخدمات.

sudo ss -tlnp

بعد ذلك، من داخل حاوية، وجّه الطلب إلى البوابة التي يعرضها ip route.

ip route show default
nc -zv 10.0.0.1 6379

إذا كانت قاعدة بيانات أو نقطة نهاية للمقاييس أو لوحة إدارة على المضيف مرتبطة بـ0.0.0.0، ينجح هذا الاختبار. لم يرَ جدار الحماية الشبكي لدى موفّر الخدمة الحزمة، لأن الحزمة لم تغادر الجهاز. يكمن سبب معظم الأسئلة من نوع «كيف تمكّنت من الوصول إلى ذلك؟» في أن الحاوية معزولة عن الإنترنت باستخدام NAT، لكنها غير معزولة عن المضيف بأي شيء.

اربط خدمات المضيف بـ127.0.0.1 كلما أمكن. ثم طبّق التصفية على الجسر في المضيف. في جهاز يستخدم ufw، تحظر سياسة الرفض الافتراضية حركة المرور من الحاويات إلى المضيف، ما يؤدي إلى تعطيل DNS وDHCP في Incus. والإصلاح الوارد في توثيق Incus هو sudo ufw allow in on incusbr0. يعيد هذا الأمر الواحد فتح كل منفذ على المضيف أمام كل حاوية. اسمح فقط بما تحتاج إليه الحاويات فعلياً.

sudo ufw allow in on incusbr0 to any port 53 proto udp
sudo ufw allow in on incusbr0 to any port 53 proto tcp
sudo ufw allow in on incusbr0 to any port 67 proto udp
sudo ufw route allow in on incusbr0
sudo ufw route allow out on incusbr0

تسمح قاعدتا ufw route بمرور حركة مرور المثيلات عبر المضيف إلى الإنترنت. من دونهما، تسقط سياسة ufw الموجّهة الحزم المُعاد توجيهها، فتحصل الحاويات على عنوان لكنها لا تصل إلى أي وجهة.

اللقطات والملفات التعريفية

اللقطة هي نسخة من المثيل في لحظة زمنية محددة، داخل مجموعة التخزين الخاصة به.

incus snapshot create web pre-upgrade
incus info web
incus snapshot restore web pre-upgrade
incus snapshot delete web pre-upgrade

يسرد incus info web اللقطات التي يحتفظ بها المثيل. جدوِل اللقطات لكل مثيل على حدة.

incus config set web snapshots.schedule=@daily
incus config set web snapshots.expiry=4w

توجد اللقطة في مجموعة التخزين نفسها، وعلى القرص نفسه، وعلى الخادم نفسه. وهي تحميك من ترقية فاشلة. لكنها لا تحميك من تعطل القرص أو حذف المثيل. توجد النسخة الاحتياطية في incus export، ويجب نقل الملف خارج الخادم.

incus export web /root/web-backup.tar.gz
incus import /root/web-backup.tar.gz

الملف التعريفي هو مجموعة مسماة من مفاتيح الإعدادات والأجهزة، وتُطبَّق على المثيلات. يحصل كل مثيل على الملف التعريفي default ما لم تحدد خلاف ذلك. وهذا الملف هو الذي يوفّر قرص الجذر وواجهة الشبكة للمثيل. يؤدي تعديل default إلى تغيير كل مثيل يستخدمه. قد يكون ذلك مفيداً، لكنه قد يفصل الشبكة عن عشرين حاوية دفعة واحدة.

incus profile create small
incus profile set small limits.memory=512MiB
incus profile set small limits.cpu=1
incus launch images:debian/13 api -p default -p small

تُطبَّق الملفات التعريفية بالترتيب، ولذلك يفوز المفتاح المحدد في آخر ملف تعريفي في القائمة. اقرأ الإعداد الفعلي الذي انتهى إليه المثيل باستخدام incus config show api --expanded.

تشغيل Docker داخل حاوية Incus

يتطلب تشغيل Docker داخل حاوية نظام Incus تفعيل التعشيش، لأن Docker ينشئ مساحات أسماء وعمليات mount خاصة به، ولا يُسمح للحاوية بإنشائها افتراضياً.

incus config set web security.nesting=true
incus restart web

تعرّف وثائق Incus الخيار security.nesting بأنه «السماح بالتعشيش داخل الـinstance»، وتكون قيمته الافتراضية false للحاويات. وتوضح نقطتان إضافيتان مباشرةً في الأسئلة الشائعة لـIncus. لا تستطيع الحاوية تحميل kernel modules، لذلك يجب تحميل أي module يحتاج إليه Docker على المضيف وإدراجه باستخدام incus config set web linux.kernel_modules overlay,br_netfilter. كما يؤدي إنشاء ملف /.dockerenv داخل الحاوية إلى جعل Docker يتجاوز بعض الفحوصات التي تفشل في بيئة متداخلة.

على مضيفي Ubuntu 24.04، قد تَحظر قيود AppArmor على user namespaces غير المميّزة العملية pivot_root التي ينفذها runc. ويطبع Docker داخل الحاوية ما يلي:

failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error jailing process inside rootfs: pivot_root .: permission denied

ويعرض dmesg على المضيف سطراً يتضمن apparmor="DENIED" operation="pivotroot" class="mount". والإعداد الذي يلجأ إليه المستخدمون عادةً هو kernel.apparmor_restrict_unprivileged_userns. لكن تعطيله ليس حلاً موثوقاً؛ إذ يسجل تقرير خطأ Incus upstream الخاص بهذا الرفض تحديداً أن ضبطه على 0 لم يحل المشكلة. اقرأ dmesg أولاً لمعرفة سبب الرفض، حتى تتأكد من أن AppArmor هو المشكلة فعلاً قبل تغيير إعداد أمني افتراضي.

إذا كنت تفضّل تشغيل الحاويات مباشرةً على VPS وتجاوز طبقة، يشرح تشغيل Docker على VPS هذا الإعداد بشكل مستقل.

أوضاع الفشل، مع النصوص التي ستظهر لك

تفقد المثيلات كل اتصالها بالشبكة بعد تثبيت Docker على المضيف. توضّح وثائق Incus السبب: "يعيّن Docker سياسة drop العامة لـFORWARD، ما يمنع Incus من إعادة توجيه حركة الشبكة، ولذلك تفقد المثيلات اتصالها بالشبكة." تحتفظ المثيلات بعناوينها، لكنها لا تصل إلى أي وجهة. عيّن ip-forward-no-drop إلى true في /etc/docker/daemon.json، ثم اجعل إعادة التوجيه دائمة، واسمح بمرور الجسر عبر سلسلة Docker نفسها.

echo "net.ipv4.conf.all.forwarding=1" | sudo tee /etc/sysctl.d/99-forwarding.conf
sudo systemctl restart systemd-sysctl
sudo iptables -I DOCKER-USER -i incusbr0 -j ACCEPT
sudo iptables -I DOCKER-USER -o incusbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

لا تبقى قواعد iptables هذه بعد إعادة التشغيل تلقائياً. اجعلها دائمة.

تتوقف الحاويات عن البدء بسبب خطأ cgroup. توثّق الأسئلة الشائعة في Incus هذه الحالة. تعني رسالة تتعلق بـFailed to mount "/sys/fs/cgroup" عادةً أن عميل VPN على المضيف ركّب وحدة تحكم cgroup v1 ‏net_cls فوق cgroup v2 التي يستخدمها Incus. يعالج sudo umount /sys/fs/cgroup/net_cls المشكلة.

لا يحصل المثيل على عنوان IPv4. يعرض incus list المثيل قيد التشغيل مع بقاء عمود العنوان فارغاً. تُسقط ردود DHCP من المضيف، وغالباً ما يكون السبب جداراً نارياً على المضيف لا يعرف الجسر. في ufw، يعيد sudo ufw allow in on incusbr0 to any port 67 proto udp الاتصال. راقب وصول الطلبات باستخدام sudo tcpdump -ni incusbr0 port 67.

يرفض المثيل البدء على VPS متداخل. اقرأ incus info <name> --show-log أولاً، ثم sudo journalctl -u incus -n 50. إذا أظهر systemd-detect-virt القيمة lxc أو openvz، فالمكوّن المفقود موجود لدى موفّر الخدمة، ولا يغيّر أي إعداد داخل VPS الخاص بك ذلك.

تكون اللقطات بطيئة، ويستمر القرص في الامتلاء. أنت تستخدم مجموعة dir. يطبع incus storage list برنامج التشغيل لكل مجموعة. يعني الانتقال إلى مجموعة تستخدم النسخ عند الكتابة إنشاء المجموعة الجديدة، ونسخ المثيلات إليها باستخدام incus copy web web-new -s fast، ثم حذف المثيلات الأصلية بعد التحقق من أن النسخ تبدأ.

FAQ

هل حاوية Incus هي نفسها حاوية Docker؟

لا. يغلّف Docker عملية أو تطبيقاً واحداً. تحاكي حاوية النظام في Incus نظام تشغيل كاملاً، مع init خاص بها، ومستخدمين خاصين بها، وخدمات خاصة بها، ومدير حزم خاص بها. تحتفظ بحاوية Incus وتطبّق التحديثات عليها كما تفعل مع خادم. أما حاوية Docker فتتخلص منها وتعيد إنشاءها من image. يمكنك تشغيل Docker داخل حاوية Incus بتعيين security.nesting=true على الحاوية. والعكس لا يعمل.

هل يمكنني تشغيل Incus على VPS؟

نعم، على VPS يعمل بنظام KVM. إذا عرض systemd-detect-virt القيمة kvm أو qemu، فلديك kernel خاص بك، ويتصرف Incus كما يتصرف على العتاد الفعلي. وإذا عرض القيمة lxc أو lxc-libvirt أو openvz، فإن VPS نفسه حاوية، ولذلك تكون حاويات Incus داخله متداخلة ولا تعمل إلا إذا فعّل مزود الخدمة nesting لحاويتك. افحص uname -r أيضاً، لأن فرع Incus المستقر الحالي، اعتباراً من August 2026، يوثّق kernel بإصدار أدنى هو 6.12، بينما يوثّق فرع 6.0 LTS الإصدار 5.4.

ما واجهة التخزين التي ينبغي أن أختارها لـ Incus على VPS؟

استخدم btrfs على loop file، ما لم يكن لديك block device فائض لتخصيصه له. إنّ dir موثّق على أنّه أبطأ بكثير من الواجهات الأخرى، لأنّه ينسخ الملفات بدلاً من استخدام copy-on-write، ولذلك تكتب كل snapshot الحاوية كاملة مرة أخرى. يختار incus admin init --minimal الخيار dir، ولذلك يستحق الأمر دقيقتين للإجابة عن الأسئلة التفاعلية. أنشئ pool باستخدام incus storage create fast btrfs size=30GiB.

لماذا يمكن لحاوية Incus لديّ الوصول إلى خدمة تعمل على المضيف؟

لأن bridge الافتراضي incusbr0 يضع المضيف والحاوية على الشبكة الفرعية نفسها، عند عنوان البوابة، ولا توجد أي تصفية بينهما. تستجيب أي خدمة على المضيف مرتبطة بـ0.0.0.0 على ذلك العنوان، ولا يرى جدار الحماية لدى مزود الخدمة هذه الحزم لأنها لا تغادر الجهاز. اربط خدمات المضيف بـ127.0.0.1، وعلى مضيف يستخدم ufw اسمح فقط بمرور DNS وDHCP إلى incusbr0 بدلاً من استخدام القاعدة الشاملة sudo ufw allow in on incusbr0.

كيف أنشئ نسخة احتياطية لحاوية Incus؟

يكتب incus export web /root/web-backup.tar.gz النسخة المثيلة وsnapshots الخاصة بها في ملف واحد، ويستعيدها incus import على الخادم نفسه أو على خادم آخر. لا تُعد snapshots التي تنشئها باستخدام incus snapshot create نسخاً احتياطية؛ فهي تبقى في storage pool نفسه وعلى القرص نفسه، ولذلك تصمد أمام ترقية فاشلة، لكنها لا تصمد أمام تعطل الخادم. جدْولها باستخدام incus config set web snapshots.schedule=@daily، وانسخ ملفات التصدير إلى خارج الجهاز.