VPS पर Incus system containers कैसे सेटअप करें

Incus system container क्या है

VPS पर Incus system containers आपको एक पूर्ण मशीन प्रदान करते हैं, जिसमें अपना init system और अपने user accounts होते हैं। यह केवल एक filesystem से जुड़ी single process नहीं है। Container boot होता है, PID 1 के रूप में एक init चलाता है, और systemctl का उत्तर देता है। यह host के kernel को साझा करता है, इसलिए यह virtual machine नहीं है। Kernel के ऊपर की हर चीज़ एक मशीन की तरह ही व्यवहार करती है।

Incus, LXD का community fork है, जिसे Linux Containers project के अंतर्गत maintain किया जाता है। इसका client command incus है। जब आप --vm पास करते हैं, तो यह QEMU के माध्यम से वास्तविक virtual machines भी चला सकता है, लेकिन system container ही वह मुख्य कारण है जिसके लिए अधिकांश लोग इसे install करते हैं, और इस guide का शेष भाग इसी पर केंद्रित है।

Docker की तुलना लोगों को गुमराह क्यों करती है

Docker एक प्रोसेस को पैकेज करता है। Incus एक ऑपरेटिंग सिस्टम को पैकेज करता है। Incus का दस्तावेजीकरण इस अंतर को स्पष्ट रूप से बताता है: "एप्लिकेशन कंटेनर (जैसे Docker द्वारा प्रदान किए गए) एक एकल प्रोसेस या एप्लिकेशन को पैकेज करते हैं। दूसरी ओर, सिस्टम कंटेनर एक पूर्ण ऑपरेटिंग सिस्टम का अनुकरण करते हैं, जो वैसा ही होता है जैसा आप किसी होस्ट या वर्चुअल मशीन पर चला रहे होते हैं।"

यह अंतर बदल देता है कि आप हर दिन उस चीज़ के साथ क्या करते हैं।

• Docker इमेज में कोई init नहीं होता, इसलिए इसके अंदर systemctl विफल हो जाता है। एक Incus कंटेनर एक init सिस्टम चलाता है, इसलिए सेवाएं और टाइमर वैसे ही काम करते हैं जैसे वे सर्वर पर करते हैं।
• Docker कंटेनर को नष्ट करने और Dockerfile से फिर से बनाने के लिए बनाया गया है। Incus कंटेनर को बनाए रखने, पैच करने और स्नैपशॉट लेने के लिए बनाया गया है।
• Docker इमेज एक बिल्ड आर्टिफैक्ट है जिसे आप रजिस्ट्री में पुश करते हैं। Incus इंस्टेंस स्टोरेज पूल में डिस्क पर मौजूद स्टेट है, और आप इसे incus export के साथ स्थानांतरित करते हैं।
• Docker एक वर्कलोड को अलग करता है। Incus एक मशीन को अलग करता है, इसलिए एक कंटेनर में कई वर्कलोड और कई यूजर अकाउंट हो सकते हैं।

आप Incus सिस्टम कंटेनर के अंदर Docker चला सकते हैं। आप Docker एप्लिकेशन कंटेनर के अंदर Incus नहीं चलाएंगे। यदि आप वास्तव में प्रति कंटेनर एक प्रोसेस और इमेज बिल्ड स्टेप चाहते हैं, तो VPS पर Podman और Docker वह तुलना है जिसे पहले पढ़ा जाना चाहिए। यदि आप साझा कर्नल के बजाय प्रति वर्कलोड एक अलग कर्नल चाहते हैं, तो VPS पर Firecracker microVMs दूसरी दिशा में जाता है।

क्या Incus एक VPS के अंदर चलेगा?

यह आपके VPS के वर्चुअलाइजेशन प्रकार और उसके kernel पर निर्भर करता है, इसलिए कुछ भी install करने से पहले दोनों की जाँच करें। प्रदाता के मार्केटिंग पेज पर भरोसा न करें। बॉक्स पर ये चार commands चलाएँ।

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

systemd-detect-virt का प्रिंट होना, kvm या qemu का मतलब है कि आपका VPS एक virtual machine है जिसका अपना kernel है। यह आसान स्थिति है, क्योंकि Incus तब वैसे ही काम करता है जैसे वह हार्डवेयर पर करता। lxc, lxc-libvirt या openvz का प्रिंट होना मतलब है कि आपका VPS स्वयं एक container है जो प्रदाता के kernel को साझा कर रहा है। इसके अंदर Incus containers, nested containers होते हैं, और nesting तभी काम करती है यदि प्रदाता ने इसे आपके container पर enable किया हो। आप इसे अंदर से enable नहीं कर सकते, क्योंकि यह सेटिंग उस host पर होती है जिसे आप नियंत्रित नहीं करते।

stat -fc %T /sys/fs/cgroup को cgroup2fs प्रिंट करना चाहिए। कुछ और प्रिंट होने का मतलब है कि बॉक्स cgroup (control group) v1 या हाइब्रिड लेआउट पर है, जिसे वर्तमान Incus सपोर्ट नहीं करता।

cat /sys/fs/cgroup/cgroup.controllers उन control-group controllers की सूची देता है जो आपको सौंपे गए हैं। Incus दस्तावेज़ blkio, cpuset, devices, freezer, memory और pids को आवश्यक बताता है। एक nested VPS पर वह सूची अक्सर KVM VPS की तुलना में छोटी होती है, क्योंकि प्रदाता ने तय किया है कि क्या सौंपना है। उस फ़ाइल से गायब कोई भी controller ऐसा है जिसे Incus उपयोग नहीं कर सकता, इसलिए उस पर निर्भर instance limit आपके लिए उपलब्ध नहीं होगी।

Kernel version पहले की तुलना में अधिक मायने रखता है। अगस्त 2026 तक, Incus दस्तावेज़ में upstream द्वारा बनाए रखी गई दो शाखाओं के लिए दो अलग-अलग न्यूनतम आवश्यकताएं हैं। 6.0 LTS (long term support) शाखा कहती है "न्यूनतम समर्थित kernel version 5.4 है।" वर्तमान stable शाखा कहती है "न्यूनतम समर्थित kernel version 6.12 है।" Ubuntu 24.04 अपने स्वयं के रिपॉजिटरी में 6.0 LTS सीरीज़ को पैकेज करता है और इसे 6.8 kernel के साथ जोड़ता है, जो एक समर्थित संयोजन है। उसी 6.8 kernel पर upstream रिपॉजिटरी से वर्तमान stable build को install करना आपको दस्तावेज़ में दी गई न्यूनतम सीमा से नीचे ले जाता है, इसलिए रिपॉजिटरी चुनने से पहले uname -r पढ़ें।

यदि आपका लक्ष्य containers के बजाय पूर्ण virtual machines है, तो बाधा अलग और कठिन है। यह देखने के लिए कि क्या आपका VPS /dev/kvm को expose कर सकता है, VPS पर nested virtualisation देखें, और यदि आप हार्डवेयर के स्वामी हैं तो किराए के VPS के विरुद्ध Proxmox देखें।

Ubuntu या Debian पर Incus इंस्टॉल करें

Debian 13 और Ubuntu 24.04 और उसके बाद के वर्ज़न में Incus उनके अपने रिपॉजिटरी में उपलब्ध है।

sudo apt update
sudo apt install -y incus

Debian पर, incus-base वर्चुअल मशीन के हिस्सों के बिना कंटेनर सपोर्ट इंस्टॉल करता है। Ubuntu पर, यदि आप --vm इंस्टेंस भी चाहते हैं तो qemu-system जोड़ें।

यदि आप अपने डिस्ट्रिब्यूशन द्वारा प्रदान किए गए वर्ज़न से नया वर्ज़न चाहते हैं, तो अपस्ट्रीम पैकेज 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

इसके बाद अपने यूजर को डेमन सॉकेट का एक्सेस दें।

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

incus info का आउटपुट सर्वर का कॉन्फ़िगरेशन दिखाना यह दर्शाता है कि सॉकेट काम कर रहा है। परमिशन एरर का मतलब है कि ग्रुप में बदलाव आपके शेल तक नहीं पहुँचा है, जिसे newgrp incus-admin वर्तमान शेल के लिए ठीक कर देता है और एक नया लॉगिन इसे पूरी तरह से ठीक कर देता है। incus-admin की सदस्यता को होस्ट पर root के बराबर मानें, क्योंकि उस सॉकेट का एक्सेस उस डेमन का पूर्ण नियंत्रण देता है जो root के रूप में चलता है। कुछ डिस्ट्रिब्यूशन प्रतिबंधित यूजर एक्सेस के लिए एक साधारण incus ग्रुप भी बनाते हैं।

अब डेमन को इनिशियलाइज़ करें।

sudo incus admin init

incus admin init --minimal का उपयोग करने के बजाय प्रश्नों के उत्तर दें। न्यूनतम पाथ dir स्टोरेज ड्राइवर को चुनता है, और अगला सेक्शन इस बारे में है कि यह विकल्प आपके साथ क्यों बना रहता है।

कुछ लॉन्च करें और पुष्टि करें कि यह काम कर रहा है।

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

incus list को web को incusbr0 सबनेट पर IPv4 एड्रेस के साथ RUNNING के रूप में दिखाना चाहिए। कोई एड्रेस न होने का मतलब है कि DHCP (डायनामिक होस्ट कॉन्फ़िगरेशन प्रोटोकॉल) पूरा नहीं हुआ है, जिसे नेटवर्किंग सेक्शन में कवर किया गया है। जो कंटेनर स्टार्ट होने में विफल रहता है, वह अपना कारण incus info web --show-log में प्रिंट करता है, और डेमन-लेवल की विफलताएं sudo journalctl -u incus -n 50 में दर्ज होती हैं। एक VPS पर जहाँ systemd-detect-virt ने lxc या openvz रिटर्न किया है, यह लॉन्च इस बात का वास्तविक परीक्षण है कि क्या नेस्टिंग आपके लिए उपलब्ध है।

डिफ़ॉल्ट स्टोरेज बैकएंड क्यों महत्वपूर्ण है

स्टोरेज बैकएंड यह तय करता है कि स्नैपशॉट तुरंत लिया जाएगा या कंटेनर की डिस्क की पूरी कॉपी बनाई जाएगी। यह इंस्टॉलेशन के समय लिया गया वह निर्णय है जिसे बाद में आसानी से नहीं बदला जा सकता।

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 कॉपी-ऑन-राइट (copy-on-write) हैं, इसलिए स्नैपशॉट केवल उन ब्लॉक्स को रिकॉर्ड करता है जो उसके बाद बदलते हैं। Incus इन दोनों को अनुशंसित बैकएंड के रूप में बताता है। स्नैपशॉट लगभग तुरंत हो जाते हैं। डिस्क कोटा फ़ाइल सिस्टम के अपने कोटा सपोर्ट के माध्यम से काम करते हैं।

अधिकांश VPS प्लान में आपको बिना किसी अतिरिक्त पार्टीशन के एक डिस्क मिलती है, इसलिए पूल को लूप फ़ाइल पर रखें। यदि आप कोई source= नहीं देते हैं, तो Incus आपके लिए ऐसा ही करता है।

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= के बिना, लूप-बैक्ड पूल खाली डिस्क स्पेस का 20% लेता है, जिसकी न्यूनतम सीमा 5 GiB और अधिकतम सीमा 30 GiB है। इसे सोच-समझकर सेट करें। लूप फ़ाइल आपके रूट फ़ाइल सिस्टम पर एक फ़ाइल होती है, इसलिए पूल और होस्ट एक ही खाली स्पेस साझा करते हैं। इसका मतलब है कि पूल भरने से होस्ट की डिस्क भी भर जाती है।

Debian और Ubuntu पर ZFS एक DKMS मॉड्यूल है, न कि इन-ट्री मॉड्यूल। इसलिए, यह हर कर्नल अपग्रेड पर फिर से बिल्ड होता है और कभी-कभी अपग्रेड के बाद बिल्ड होने में विफल हो सकता है। ऐसे सर्वर पर जिसे आप प्रतिदिन मॉनिटर नहीं करते हैं, btrfs दोनों में से कम रखरखाव वाला विकल्प है।

तीन नेटवर्किंग मोड और प्रत्येक द्वारा expose की जाने वाली जानकारी

incus admin init एक managed bridge बनाता है जिसे incusbr0 कहा जाता है और प्रत्येक नए instance को उस पर डाल देता है। यह container को attach करने के तीन तरीकों में से एक है, और अन्य दो तरीके इसलिए मौजूद हैं क्योंकि पहला तरीका आपके containers को NAT (network address translation) के पीछे छिपा देता है।

Managed bridge. incusbr0 को एक private subnet मिलता है। host उस पर पहला address रखता है और gateway के रूप में कार्य करता है, Incus उस पर DHCP और DNS (domain name system) चलाता है, और outbound traffic source NAT लागू होने के साथ host के public address के माध्यम से बाहर जाता है। जब तक आप निर्देश न दें, बाहर से कुछ भी container तक नहीं पहुँचता। proxy device के साथ एक port forward करें।

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 एक अलग userspace connection के माध्यम से proxying करने के बजाय netfilter rules के साथ forward करता है, इसलिए client का वास्तविक address container के logs में सुरक्षित रहता है। Incus उस mode का समर्थन केवल तब करता है जब host, instance का gateway हो, जो कि बिल्कुल incusbr0 वाली स्थिति है।

macvlan. container को host के physical network पर अपना स्वयं का MAC (media access control) address मिलता है। अधिकांश VPS platforms पर यह विफल हो जाता है, क्योंकि virtual switch port आपके VM के MAC address से बंधा होता है और किसी अन्य से आने वाले frames को drop कर देता है। एक दूसरी सीमा भी है जो लोगों को तब भी प्रभावित करती है जब यह काम करता है। Incus के दस्तावेज़ बताते हैं कि "macvlan devices, हालांकि आपस में और बाहर से संवाद करने में सक्षम हैं, अपने parent device से बात नहीं कर सकते। इसका मतलब है कि यदि आपको कभी अपने instances को host से बात कराने की आवश्यकता हो, तो आप macvlan का उपयोग नहीं कर सकते।"

Routed. यह वह mode है जो आमतौर पर अतिरिक्त addresses वाले VPS पर काम करता है। Incus इस device को एक ऐसे device के रूप में वर्णित करता है जो "host को instance से जोड़ने के लिए एक virtual device pair बनाता है और instance को निर्दिष्ट parent interface के network में शामिल होने की अनुमति देने के लिए static routes और proxy ARP/NDP entries सेट करता है"। ARP का अर्थ address resolution protocol है। container एक public address रखता है। host इसके लिए ARP का उत्तर देता है, इसलिए provider को अभी भी केवल host का MAC address ही दिखाई देता है।

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

ip route show default से parent interface का नाम लें। वर्तमान images enp1s0 या ens3 जैसे नामों का उपयोग करती हैं, शायद ही कभी eth0 का। device का नाम eth0 रखने से वह override हो जाता है जिसे default profile प्रदान करती है, इसलिए container bridge के बजाय routed interface पर समाप्त होता है। अंदर से 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 बॉक्स पर, डिफ़ॉल्ट 'deny' पॉलिसी पहले से ही कंटेनर-टू-होस्ट ट्रैफ़िक को ब्लॉक करती है, जो Incus DNS और DHCP को बाधित करती है, और 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 की 'routed' पॉलिसी फॉरवर्ड किए गए पैकेट को ड्रॉप कर देती है, जिससे कंटेनरों को एड्रेस तो मिल जाता है लेकिन वे कहीं पहुँच नहीं पाते।

Snapshots और profiles

Snapshot आपके storage pool के भीतर instance की एक point-in-time copy होती है।

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

incus info web कमांड उन snapshots की सूची दिखाता है जो instance के पास हैं। आप इन्हें प्रति instance schedule कर सकते हैं।

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

Snapshot उसी pool, उसी disk और उसी server पर रहता है। यह आपको खराब upgrade से बचाता है। यह आपको खराब disk या delete किए गए instance से नहीं बचाता है। Backup incus export होता है, और उस file को server से बाहर ले जाना आवश्यक है।

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

Profile config keys और devices का एक named set है जिसे instances पर लागू किया जाता है। जब तक आप अन्यथा न कहें, हर instance को default profile मिलता है, और यही profile उसे root disk और network interface प्रदान करता है। default को edit करने से इसका उपयोग करने वाले सभी instances बदल जाते हैं, जो उपयोगी है और इसी तरह एक साथ बीस containers से network को detach किया जाता है।

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

Profiles क्रम में लागू होते हैं, इसलिए अंतिम सूचीबद्ध profile में set की गई key प्रभावी होती है। incus config show api --expanded का उपयोग करके यह पढ़ें कि अंततः instance के पास क्या configuration है।

Incus container के भीतर Docker चलाना

Incus system container के भीतर Docker चलाने के लिए nesting को enable करना आवश्यक है, क्योंकि Docker अपने स्वयं के namespaces और mounts बनाता है जिन्हें एक container डिफ़ॉल्ट रूप से बनाने के लिए अधिकृत नहीं होता है।

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

Incus दस्तावेज़ security.nesting को "instance के भीतर nesting की अनुमति देनी है या नहीं" के रूप में परिभाषित करते हैं, और containers के लिए यह डिफ़ॉल्ट रूप से false होता है। दो और महत्वपूर्ण बिंदु सीधे Incus FAQ से लिए गए हैं। एक container kernel modules को load नहीं कर सकता है, इसलिए Docker को जिस module की आवश्यकता है उसे host पर load किया जाना चाहिए और incus config set web linux.kernel_modules overlay,br_netfilter के साथ सूचीबद्ध किया जाना चाहिए। साथ ही, container के भीतर एक /.dockerenv फ़ाइल बनाने से Docker उन कुछ जाँचों (checks) को छोड़ देता है जो nested environment में विफल हो जाती हैं।

Ubuntu 24.04 hosts पर, AppArmor के unprivileged user namespace प्रतिबंध उस pivot_root को रोक सकते हैं जिसे runc निष्पादित करता है। Container के भीतर Docker यह error देता है:

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

और host का dmesg एक लाइन दिखाता है जिसमें apparmor="DENIED" operation="pivotroot" class="mount" शामिल है। जिस सेटिंग को लोग आमतौर पर बदलते हैं वह kernel.apparmor_restrict_unprivileged_userns है। इसे बंद करना कोई विश्वसनीय समाधान नहीं है: इस विशिष्ट denial के लिए upstream Incus bug report में दर्ज है कि इसे 0 पर सेट करने से समस्या हल नहीं हुई। पहले denial के लिए dmesg पढ़ें, ताकि आप किसी सुरक्षा डिफ़ॉल्ट को बदलने से पहले यह जान सकें कि क्या AppArmor वास्तव में आपकी समस्या है।

यदि आप containers को सीधे VPS पर चलाना चाहते हैं और एक परत (layer) को हटाना चाहते हैं, तो VPS पर Docker चलाना उस सेटअप को विस्तार से कवर करता है।

विफलता के प्रकार और उनसे संबंधित संदेश

Docker को host पर install करने के बाद instances का network पूरी तरह बंद हो जाता है। Incus documentation में इसका कारण बताया गया है: "Docker वैश्विक FORWARD policy को drop पर सेट कर देता है, जो Incus को traffic forward करने से रोकता है और इस कारण instances का network connectivity खत्म हो जाता है।" Instances के पास अपने IP address तो रहते हैं, लेकिन वे किसी भी destination तक नहीं पहुँच पाते। /etc/docker/daemon.json में ip-forward-no-drop को true पर सेट करें, फिर forwarding को persistent बनाएँ और bridge को Docker की अपनी chain से गुजरने दें।

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 rules reboot के बाद अपने आप सुरक्षित नहीं रहते। इन्हें persistent बनाएँ।

Containers cgroup error के कारण start होना बंद हो जाते हैं। Incus FAQ में इसका उल्लेख है। Failed to mount "/sys/fs/cgroup" के बारे में कोई संदेश आने का सामान्य अर्थ यह है कि host पर किसी VPN client ने net_cls cgroup v1 controller को cgroup v2 के ऊपर mount कर दिया है, जिसका उपयोग Incus करता है। sudo umount /sys/fs/cgroup/net_cls इसे ठीक कर देता है।

Instance को IPv4 address नहीं मिलता। incus list में यह running तो दिखता है लेकिन address column खाली होता है। Host से आने वाले DHCP replies को drop किया जा रहा है, अक्सर किसी ऐसे host firewall द्वारा जिसे bridge के बारे में जानकारी नहीं है। Ufw पर, sudo ufw allow in on incusbr0 to any port 67 proto udp इसे बहाल कर देता है। sudo tcpdump -ni incusbr0 port 67 के साथ requests के आने की निगरानी करें।

Nested VPS पर instance start होने से मना कर देता है। पहले incus info <name> --show-log पढ़ें, फिर sudo journalctl -u incus -n 50 देखें। यदि systemd-detect-virt ने lxc या openvz कहा है, तो कमी provider की तरफ से है, और आपके VPS के अंदर की कोई भी setting इसे नहीं बदल सकती।

Snapshots धीमे हैं और disk लगातार भर रही है। आप एक dir pool का उपयोग कर रहे हैं। incus storage list प्रत्येक pool के लिए driver दिखाता है। Copy-on-write pool पर जाने का अर्थ है नया pool बनाना, incus copy web web-new -s fast के साथ instances को उसमें copy करना, और फिर copies के start होने की पुष्टि करने के बाद originals को delete करना।

FAQ

क्या Incus container और Docker container एक ही चीज़ हैं?

नहीं। Docker एक एकल process या application को package करता है। एक Incus system container एक पूर्ण operating system का अनुकरण (simulate) करता है, जिसमें अपना init, अपने users, अपनी services और अपना package manager होता है। आप एक Incus container को बनाए रखते हैं और उसे एक server की तरह patch करते हैं। आप एक Docker container को हटा देते हैं और उसे image से फिर से बनाते हैं। आप container पर security.nesting=true सेट करके Incus container के अंदर Docker चला सकते हैं। इसका उल्टा संभव नहीं है।

क्या मैं VPS पर Incus चला सकता हूँ?

KVM VPS पर, हाँ। यदि systemd-detect-virt, kvm या qemu प्रिंट करता है, तो आपके पास अपना kernel है और Incus वैसे ही काम करता है जैसे hardware पर करता है। यदि यह lxc, lxc-libvirt या openvz प्रिंट करता है, तो आपका VPS स्वयं एक container है, इसलिए इसके अंदर के Incus containers nested हैं और तभी काम करेंगे यदि आपके provider ने आपके container पर nesting सक्षम की हो। uname -r की भी जाँच करें, क्योंकि अगस्त 2026 तक वर्तमान Incus stable branch 6.12 के न्यूनतम kernel का दस्तावेजीकरण करती है, जबकि 6.0 LTS branch 5.4 का।

VPS पर Incus के लिए मुझे कौन सा storage backend चुनना चाहिए?

loop file पर btrfs चुनें, जब तक कि आपके पास इसे देने के लिए कोई अतिरिक्त block device न हो। dir driver को दूसरों की तुलना में बहुत धीमा बताया गया है, क्योंकि यह copy-on-write का उपयोग करने के बजाय फाइलों को copy करता है, इसलिए हर snapshot पूरे container को फिर से लिखता है। incus admin init --minimal, dir का चयन करता है, इसीलिए interactive सवालों के जवाब देने में दो मिनट का समय लगाना सार्थक है। incus storage create fast btrfs size=30GiB के साथ pool बनाएँ।

मेरा Incus container host पर चल रही service तक क्यों पहुँच सकता है?

क्योंकि डिफ़ॉल्ट incusbr0 bridge host को container के समान subnet पर, gateway address पर रखता है, और उनके बीच कुछ भी filter नहीं होता। 0.0.0.0 पर bind कोई भी host service वहाँ जवाब देती है, और आपके provider का firewall उन packets को कभी नहीं देखता क्योंकि वे machine से बाहर नहीं जाते। Host services को 127.0.0.1 पर bind करें, और ufw host पर blanket sudo ufw allow in on incusbr0 के बजाय केवल incusbr0 पर DNS और DHCP की अनुमति दें।

मैं Incus container का backup कैसे लूँ?

incus export web /root/web-backup.tar.gz instance और उसके snapshots को एक file में लिखता है, और incus import उसे उसी server या किसी अन्य पर restore करता है। incus snapshot create के साथ बनाए गए snapshots backup नहीं हैं: वे उसी disk पर उसी storage pool में रहते हैं, इसलिए वे खराब upgrade से तो बच जाते हैं लेकिन dead server से नहीं। उन्हें incus config set web snapshots.schedule=@daily के साथ schedule करें, और exports को box से बाहर copy करें।