VPS-এ Incus সিস্টেম কন্টেইনার সেটআপ করার নিয়ম

Incus system container কী

VPS-এ Incus system container আপনাকে নিজস্ব init system এবং নিজস্ব user account-সহ একটি সম্পূর্ণ মেশিন দেয়; এটি filesystem-সহ একটি মাত্র process নয়। Container boot হয়, PID 1 হিসেবে init চালায় এবং নিজের service manager-এর নির্দেশে কাজ করে। systemd ব্যবহার করা Debian ও Ubuntu-এর মতো image-এ সেটি হলো systemctl, আর OpenRC ব্যবহার করা Alpine-এ হলো rc-service। এটি host-এর kernel শেয়ার করে, তাই এটি virtual machine নয়। Kernel-এর ওপরের সবকিছু একটি আলাদা মেশিনের মতো আচরণ করে।

Incus হলো LXD-এর community fork, যা Linux Containers project-এর অধীনে রক্ষণাবেক্ষণ করা হয়। Client command হলো incus। --vm দিলে এটি QEMU-এর মাধ্যমে বাস্তব virtual machine-ও চালাতে পারে। তবে বেশিরভাগ মানুষ এটি install করেন system container ব্যবহারের জন্য, এবং এই 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 বিষয়টি অন্য দিক থেকে দেখুন।

VPS-এর ভেতরে কি Incus চালানো যাবে?

এটি আপনার VPS-এর virtualisation type এবং kernel-এর ওপর নির্ভর করে। তাই কিছু ইনস্টল করার আগে দুটিই পরীক্ষা করুন। Provider-এর marketing page-এর তথ্য অন্ধভাবে বিশ্বাস করবেন না। সার্ভারে এই চারটি command চালান।

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

systemd-detect-virt kvm অথবা qemu দেখালে আপনার VPS একটি নিজস্ব kernel-সহ virtual machine। এটি সহজ পরিস্থিতি, কারণ তখন Incus hardware-এর ওপর চলার মতোই আচরণ করে। lxc, lxc-libvirt অথবা openvz দেখালে আপনার VPS নিজেই provider-এর kernel ভাগ করে নেওয়া একটি container। এর ভেতরে Incus container চালালে সেগুলো nested container হবে। এটি কেবল তখনই কাজ করবে, যদি provider আপনার container-এ nesting সক্রিয় করে থাকে। ভেতর থেকে আপনি এটি সক্রিয় করতে পারবেন না, কারণ সেটিংটি এমন host-এ থাকে যেটির নিয়ন্ত্রণ আপনার নেই।

stat -fc %T /sys/fs/cgroup-এর আউটপুট cgroup2fs হওয়া উচিত। অন্য যেকোনো আউটপুটের অর্থ হলো সার্ভারটি cgroup (control group) v1 অথবা hybrid layout ব্যবহার করছে, যেগুলো বর্তমান Incus-এর লক্ষ্য নয়।

cat /sys/fs/cgroup/cgroup.controllers আপনার জন্য delegated control-group controller-গুলোর তালিকা দেখায়। Incus-এর documentation অনুযায়ী blkio, cpuset, devices, freezer, memory এবং pids প্রয়োজনীয়। Nested VPS-এ এই তালিকা সাধারণত KVM-এর তুলনায় ছোট হয়, কারণ provider কোন controller আপনার কাছে হস্তান্তর করবে তা নির্ধারণ করে। কোনো controller ওই file-এ না থাকলে Incus সেটি ব্যবহার করতে পারে না। ফলে ওই controller-এর ওপর নির্ভরশীল instance limit আপনার জন্য উপলভ্য নয়।

Kernel version-এর গুরুত্ব আগের তুলনায় বেড়েছে। October 2026 অনুযায়ী upstream বর্তমানে দুটি LTS (long term support) series, 6.0 এবং 7.0, বর্তমান feature release-গুলোর পাশাপাশি রক্ষণাবেক্ষণ করছে। এই series দুটির minimum requirement এক নয়। 6.0 LTS documentation-এ বলা আছে, "The minimum supported kernel version is 5.4." বর্তমান documentation-এ বলা আছে, "The minimum supported kernel version is 6.12.", এবং 7.0 LTS প্রকাশের May 2026 announcement-এ minimum requirement-এর মধ্যে Linux 6.12 উল্লেখ করা হয়েছে। একই announcement-এ 6.0 LTS security-only phase-এ প্রবেশ করেছে বলে জানানো হয়। Ubuntu 24.04 নিজস্ব repository-তে 6.0 LTS series-এর package দেয় এবং সেটিকে 6.8 kernel-এর সঙ্গে ব্যবহার করে; এটি একটি supported combination। একই 6.8 kernel-এর ওপর upstream repository থেকে stable অথবা 7.0 LTS build ইনস্টল করলে আপনি documented minimum-এর নিচে থাকবেন। তাই repository বেছে নেওয়ার আগে uname -r পড়ুন।

আপনার লক্ষ্য যদি container নয়, পূর্ণ virtual machine চালানো হয়, তাহলে সীমাবদ্ধতা আলাদা এবং বেশি কঠিন। আপনার VPS আদৌ /dev/kvm প্রকাশ করতে পারে কি না জানতে VPS-এ nested virtualisation দেখুন। Hardware আপনার নিজের হলে ভাড়া করা VPS-এ Proxmox দেখুন।

Ubuntu বা Debian-এ Incus ইনস্টল করুন

Debian 13 এবং Ubuntu 24.04 ও পরবর্তী সংস্করণগুলো নিজেদের repository-তে Incus সরবরাহ করে।

sudo apt update
sudo apt install -y incus

Debian-এ incus-base virtual machine অংশ ছাড়া container support ইনস্টল করে। Ubuntu-তে qemu-system যোগ করুন, যদি আপনি --vm instance-ও চালাতে চান।

আপনার distribution-এ থাকা সংস্করণের চেয়ে নতুন release চাইলে upstream package পাওয়া যাবে pkgs.zabbly.com-এ। এই repository-তে lts-6.0, lts-7.0 এবং stable channel আছে। নিচের command-গুলো project-এর নিজস্ব repository README থেকে নেওয়া এবং stable ব্যবহার করে। আপনার kernel-এর জন্য LTS series প্রয়োজন হলে file name এবং URIs: line-এ channel-এর নাম বদলান।

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

এরপর আপনার user-কে daemon socket ব্যবহারের অনুমতি দিন।

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

incus info চালিয়ে server-এর configuration দেখাতে পারলে বোঝা যায় socket কাজ করছে। Permission error দেখালে বুঝবেন group change আপনার shell-এ এখনও প্রয়োগ হয়নি। বর্তমান shell-এর জন্য newgrp incus-admin এটি প্রয়োগ করে, আর নতুন করে login করলে পরিবর্তনটি স্থায়ীভাবে প্রয়োগ হয়। incus-admin-এর membership-কে host-এ root-এর সমতুল্য হিসেবে বিবেচনা করুন, কারণ ওই socket-এ access মানে root হিসেবে চলা daemon-এর সম্পূর্ণ নিয়ন্ত্রণ। কিছু distribution সীমিত user access-এর জন্য সাধারণ incus group-ও তৈরি করে।

এখন daemon initialize করুন।

sudo incus admin init

incus admin init --minimal ব্যবহার না করে প্রশ্নগুলোর উত্তর দিন। ন্যূনতম পদ্ধতিতে dir storage driver নির্বাচন করা হয়। পরের section-এ ব্যাখ্যা করা হয়েছে কেন এই নির্বাচন পরবর্তী ব্যবহারে প্রভাব ফেলে।

কিছু চালু করে কাজ করছে কি না নিশ্চিত করুন।

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

incus list-এ web-কে RUNNING হিসেবে, incusbr0 subnet-এ একটি IPv4 address-সহ দেখা যাওয়ার কথা। কোনো address না থাকলে DHCP (dynamic host configuration protocol) সম্পন্ন হয়নি। Networking section-এ এটি ব্যাখ্যা করা হয়েছে। কোনো container start করতে ব্যর্থ হলে তার কারণ incus info web --show-log-এ দেখাবে। Daemon-স্তরের failure sudo journalctl -u incus -n 50-এ নথিভুক্ত হবে। কোনো VPS-এ systemd-detect-virt lxc বা openvz ফেরত দিলে, nesting আপনার জন্য available কি না যাচাই করার সঠিক পরীক্ষা হলো এই launch।

ডিফল্ট storage backend কেন গুরুত্বপূর্ণ

storage backend নির্ধারণ করে snapshot তাৎক্ষণিক হবে, নাকি container-এর disk-এর সম্পূর্ণ copy তৈরি হবে। install-এর সময় এটি এমন একটি সিদ্ধান্ত, যা পরে কম খরচে পরিবর্তন করা যায় না।

Incus dir, btrfs, lvm, zfs, Ceph এবং আরও কয়েকটি remote driver সমর্থন করে। একটি single-disk VPS-এ বাস্তব পছন্দ হলো dir এবং btrfs-এর মধ্যে।

dir driver প্রতিটি container-কে /var/lib/incus-এর অধীনে সাধারণ file ও directory হিসেবে রাখে। Incus এটিকে "much slower than all the other drivers" হিসেবে উল্লেখ করে, কারণ প্রতিটি image unpack করে shared block reference করার বদলে প্রকৃত copy তৈরি করতে হয়। 4 GiB আকারের একটি container-এর snapshot তৈরি করতে 4 GiB data লিখতে হয় এবং cp -a যত সময় নেয়, প্রায় তত সময় লাগে। Disk quota কেবল project quota সক্রিয় থাকা ext4 বা XFS-এ কাজ করে। বেশিরভাগ VPS image-এ filesystem level-এ এটি ডিফল্টভাবে সক্রিয় থাকে না। তাই dir pool-এ disk limit সেট করলেও প্রায়ই কোনো প্রভাব পড়ে না।

btrfs এবং zfs copy-on-write ব্যবহার করে। তাই snapshot তৈরির সময় কেবল পরে পরিবর্তিত block-গুলো রেকর্ড হয়। Incus এই দুইটিকে সুপারিশকৃত backend হিসেবে উল্লেখ করে। Snapshot প্রায় তাৎক্ষণিক হয়ে যায়। Filesystem-এর নিজস্ব quota support ব্যবহার করে disk quota কাজ করে।

বেশিরভাগ VPS plan-এ অতিরিক্ত partition ছাড়া একটি disk থাকে। তাই pool-টি একটি loop file-এ রাখুন। আপনি কোনো 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= ছাড়া loop-backed pool free disk space-এর 20% নেয়; সর্বনিম্ন 5 GiB এবং সর্বোচ্চ 30 GiB সীমা থাকে। এই মানটি ইচ্ছাকৃতভাবে নির্ধারণ করুন। Pool নিজস্ব size-এ পৌঁছালে আর বাড়ে না। ফলে host-এ free space থাকা সত্ত্বেও pool পূর্ণ হয়ে যেতে পারে। Loop-backed pool space শেষ হওয়ার এটিই সাধারণ কারণ। তবে loop file নিজেই host-এর filesystem-এ থাকা একটি file। তাই host-এর নিজস্ব প্রয়োজন বিবেচনা করে pool-এর size নির্ধারণ করুন; host-এর সব free gigabyte pool-কে দিয়ে দেবেন না।

Debian এবং Ubuntu-তে ZFS in-tree module নয়, বরং একটি DKMS module। তাই প্রতিটি kernel upgrade-এর সময় এটি rebuild হয় এবং কোনো upgrade-এর পরে build ব্যর্থ হতে পারে। প্রতিদিন নজরদারি করেন না এমন server-এ এই দুইটির মধ্যে btrfs-এর maintenance কম।

তিনটি networking mode এবং প্রতিটি mode কী প্রকাশ করে

আপনি প্রস্তাবিত উত্তরটি গ্রহণ করলে incus admin init incusbr0 নামে একটি managed bridge তৈরি করে এবং সেটিকে default profile-এর সঙ্গে যুক্ত করে। ফলে ওই profile ব্যবহার করা প্রতিটি নতুন instance এই bridge-এ যুক্ত হয়। এর পরিবর্তে আপনি কোনো বিদ্যমান bridge বা interface নির্দেশ করতে পারেন। Managed bridge হলো container যুক্ত করার তিনটি পদ্ধতির একটি। অন্য দুটি পদ্ধতির প্রয়োজন হয়, কারণ প্রথম পদ্ধতিটি NAT (network address translation)-এর আড়ালে container-গুলোকে রাখে।

Managed bridge। incusbr0 একটি private subnet পায়। Host এই subnet-এর প্রথম address ধরে gateway হিসেবে কাজ করে। Incus এই subnet-এ DHCP এবং DNS (domain name system) চালায়। Outbound traffic host-এর public address দিয়ে বের হয় এবং source NAT প্রয়োগ করা হয়। আপনি স্পষ্টভাবে অনুমতি না দেওয়া পর্যন্ত বাইরের কোনো traffic container-এ পৌঁছাতে পারে না। একটি port forward করতে 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 আলাদা userspace connection-এর মাধ্যমে proxy না করে netfilter rule ব্যবহার করে forwarding করে। ফলে client-এর প্রকৃত address container-এর log-এও থাকে। Incus এই mode কেবল তখনই সমর্থন করে, যখন host instance-এর gateway। এটি ঠিক incusbr0 case।

macvlan। Container host-এর physical network-এ নিজস্ব MAC (media access control) address পায়। অধিকাংশ VPS platform-এ এটি ব্যর্থ হয়, কারণ virtual switch port আপনার VM-এর MAC address-এর সঙ্গে আবদ্ধ থাকে এবং অন্য কোনো MAC address থেকে আসা frame বাতিল করে। এটি কাজ করলেও আরও একটি সীমাবদ্ধতা রয়েছে, যা অনেকেই পরে বুঝতে পারেন। Incus-এর documentation অনুযায়ী, “macvlan device নিজেদের মধ্যে এবং বাইরের সঙ্গে যোগাযোগ করতে পারলেও parent device-এর সঙ্গে যোগাযোগ করতে পারে না। এর অর্থ, আপনার instance-গুলোর host-এর সঙ্গে যোগাযোগের প্রয়োজন হলে macvlan ব্যবহার করা যাবে না।”

Routed। অতিরিক্ত address থাকা VPS-এ সাধারণত এই mode কাজ করে। Incus এই device-কে এমন একটি device হিসেবে বর্ণনা করে, যা “host ও instance-কে সংযুক্ত করার জন্য একটি virtual device pair তৈরি করে এবং static route ও proxy ARP/NDP entry সেট করে, যাতে instance নির্ধারিত parent interface-এর network-এ যুক্ত হতে পারে”। ARP হলো address resolution protocol। Container একটি public address ধরে রাখে। Host ওই address-এর জন্য 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-এর নাম নিন। বর্তমান image-গুলোতে enp1s0 বা ens3-এর মতো নাম ব্যবহৃত হয়; eth0 খুব কম দেখা যায়। Device-এর নাম eth0 দিলে default profile থেকে সরবরাহ করা device-এর পরিবর্তে এটি ব্যবহৃত হয়। ফলে container bridge-এর পরিবর্তে routed interface-এ যুক্ত হয়। ip a এবং ip route ব্যবহার করে container-এর ভেতর থেকে ফলাফল পরীক্ষা করুন।

কেন একটি container host-এর service-এ পৌঁছাতে পেরেছিল

incusbr0-এ থাকা একটি container-এর নিজস্ব network namespace থাকে। এটি host-এর বিরুদ্ধে firewall boundary নয়। Managed Incus bridge যে firewall rule যোগ করে, সেগুলো documentation-এর ভাষায় “পূর্ণ কার্যকারিতা নিশ্চিত করার” জন্য; host-কে আলাদা করে রাখার জন্য নয়। Host gateway address-এ ওই bridge-এর সঙ্গে যুক্ত থাকে। তাই container-এর ভেতর থেকে host সরাসরি reachable neighbour হিসেবে দেখা যায়, এবং 0.0.0.0-এ bind করা প্রতিটি host service সেখানে সাড়া দেয়, যদি না host firewall rule packet drop করে।

নিজেই পরীক্ষা করুন। Host-এ কোন কোন service listening করছে, তা তালিকাভুক্ত করুন।

sudo ss -tlnp

এরপর একটি container-এর ভেতর থেকে ip route যে gateway দেখায়, সেটিতে request পাঠান।

ip route show default
nc -zv 10.0.0.1 6379

Host-এর কোনো database, metrics endpoint বা admin panel যদি 0.0.0.0-এ bind করা থাকে এবং কোনো host firewall rule bridge-এর traffic block না করে, তাহলে এই পরীক্ষা সফল হবে। আপনার provider-এর network firewall packet-টি দেখতেই পায়নি, কারণ packet-টি machine-এর বাইরে যায়নি। অধিকাংশ “এটি কীভাবে সেখানে পৌঁছাল” প্রশ্নের পেছনে এটাই মূল কারণ: NAT-এর মাধ্যমে container Internet থেকে বিচ্ছিন্ন থাকে, আর host থেকে এটি কেবল host firewall-এর প্রয়োগ করা নিয়ম অনুযায়ী বিচ্ছিন্ন থাকে।

যেখানে সম্ভব, host service-গুলোকে 127.0.0.1-এ bind করুন। এরপর host-এ bridge-এর traffic filter করুন। ufw ব্যবহার করা host-এ default deny policy ইতিমধ্যে container-to-host traffic block করে। এতে Incus DNS এবং DHCP কাজ করা বন্ধ হয়। Incus documentation-এ দেওয়া সমাধান হলো sudo ufw allow in on incusbr0। এই একটি command প্রতিটি container-এর জন্য host-এর সব port আবার খুলে দেয়। এর পরিবর্তে container-এর সত্যিই প্রয়োজনীয় traffic-ই অনুমোদন করুন।

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-এর দুটি rule instance-এর traffic-কে host-এর মধ্য দিয়ে Internet-এ যেতে দেয়। এগুলো না থাকলে ufw-এর routed policy forwarded packet drop করে। ফলে container একটি address পেলেও কোনো গন্তব্যে পৌঁছাতে পারে না।

স্ন্যাপশট এবং প্রোফাইল

স্ন্যাপশট হলো স্টোরেজ পুলের ভেতরে থাকা কোনো ইনস্ট্যান্সের একটি নির্দিষ্ট সময়ের কপি।

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

প্রোফাইল হলো কনফিগারেশন কি (keys) এবং ডিভাইসের একটি নামযুক্ত সেট, যা ইনস্ট্যান্সে প্রয়োগ করা হয়। আপনি অন্য কিছু উল্লেখ না করলে প্রতিটি ইনস্ট্যান্স ডিফল্টভাবে 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

প্রোফাইলগুলো ক্রমানুসারে প্রয়োগ করা হয়, তাই তালিকায় সবার শেষে থাকা প্রোফাইলের কি (key) প্রাধান্য পায়। incus config show api --expanded ব্যবহার করে দেখুন একটি ইনস্ট্যান্সে শেষ পর্যন্ত কী কী কনফিগারেশন কার্যকর হয়েছে।

Incus কন্টেইনারের ভেতরে Docker চালানো

একটি Incus সিস্টেম কন্টেইনারের ভেতরে Docker চালানোর জন্য nesting সুবিধাটি চালু থাকতে হয়। কারণ Docker নিজস্ব নেমস্পেস এবং মাউন্ট তৈরি করে, যা ডিফল্টভাবে একটি কন্টেইনারের করার অনুমতি থাকে না।

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

Incus-এর ডকুমেন্টেশনে security.nesting-কে "ইনস্ট্যান্সের ভেতরে নেস্টিংয়ের অনুমতি দেওয়া হবে কি না" হিসেবে উল্লেখ করা হয়েছে এবং কন্টেইনারের জন্য এটি ডিফল্টভাবে false থাকে। Incus FAQ থেকে আরও দুটি গুরুত্বপূর্ণ বিষয় জানা যায়। একটি কন্টেইনার নিজে থেকে কার্নেল মডিউল লোড করতে পারে না, তাই Docker-এর প্রয়োজনীয় মডিউলগুলো হোস্ট মেশিনে লোড থাকতে হবে এবং সেগুলোকে incus config set web linux.kernel_modules overlay,br_netfilter-এ তালিকাভুক্ত করতে হবে। এছাড়া কন্টেইনারের ভেতরে একটি /.dockerenv ফাইল তৈরি করলে Docker এমন কিছু চেক এড়িয়ে যায়, যা নেস্টেড পরিবেশে ব্যর্থ হয়।

Ubuntu 24.04 হোস্টগুলোতে, AppArmor-এর আনপ্রিভিলেজড ইউজার নেমস্পেস সীমাবদ্ধতা runc-এর করা pivot_root-কে বাধা দিতে পারে। কন্টেইনারের ভেতরে 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 বাগ রিপোর্টে উল্লেখ করা হয়েছে যে, এটিকে 0-এ সেট করলেও সমস্যার সমাধান হয়নি। কোনো নিরাপত্তা ডিফল্ট পরিবর্তন করার আগে AppArmor আসলেই আপনার সমস্যার কারণ কি না তা নিশ্চিত হতে প্রথমে dmesg পড়ুন।

আপনি যদি সরাসরি VPS-এ কন্টেইনার চালাতে চান এবং একটি লেয়ার কমাতে চান, তবে VPS-এ Docker চালানো অংশে সেই সেটআপটি আলোচনা করা হয়েছে।

ব্যর্থতার ধরন এবং যে বার্তাগুলো আপনি দেখবেন

হোস্টে Docker ইনস্টল করার পর ইনস্ট্যান্সগুলোর নেটওয়ার্ক সংযোগ বিচ্ছিন্ন হয়ে যায়। Incus-এর ডকুমেন্টেশনে এর কারণ উল্লেখ করা হয়েছে: "Docker গ্লোবাল FORWARD পলিসিকে drop-এ সেট করে, যা Incus-কে ট্রাফিক ফরওয়ার্ড করতে বাধা দেয় এবং এর ফলে ইনস্ট্যান্সগুলো নেটওয়ার্ক সংযোগ হারিয়ে ফেলে।" ইনস্ট্যান্সগুলো তাদের আইপি অ্যাড্রেস ধরে রাখে কিন্তু কোনো কিছুর সাথে যোগাযোগ করতে পারে না। /etc/docker/daemon.json-এ ip-forward-no-drop-কে true-এ সেট করুন, তারপর ফরওয়ার্ডিং স্থায়ী করুন এবং 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 FAQ-তে এটি নথিভুক্ত করা আছে। Failed to mount "/sys/fs/cgroup" সংক্রান্ত কোনো বার্তা সাধারণত বোঝায় যে হোস্টের কোনো VPN ক্লায়েন্ট cgroup v2-এর ওপর net_cls cgroup v1 কন্ট্রোলার মাউন্ট করেছে, যা 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 প্রতিটি পুলের ড্রাইভার দেখায়। একটি কপি-অন-রাইট (copy-on-write) পুলে স্থানান্তরিত হওয়ার অর্থ হলো নতুন পুল তৈরি করা, incus copy web web-new -s fast ব্যবহার করে ইনস্ট্যান্সগুলো সেখানে কপি করা এবং কপিগুলো সঠিকভাবে চালু হচ্ছে কি না তা যাচাই করার পর মূলগুলো মুছে ফেলা।

FAQ

Incus container কি Docker container-এর মতো একই জিনিস?

না। Docker একটি single process বা application package করে। Incus system container নিজস্ব init, users, services এবং package manager-সহ একটি পূর্ণ operating system অনুকরণ করে। 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 container-গুলো nested, এবং আপনার provider container-এ nesting সক্রিয় করলেই কেবল কাজ করবে। uname -r-ও পরীক্ষা করুন। কারণ October 2026 অনুযায়ী বর্তমান Incus release এবং 7.0 LTS series-এর জন্য 6.12 বা তার নতুন kernel প্রয়োজন, আর 6.0 LTS series-এ 5.4 নথিভুক্ত করা আছে।

VPS-এ Incus-এর জন্য কোন storage backend বেছে নেওয়া উচিত?

Loop file-এর ওপর btrfs ব্যবহার করুন, যদি না দেওয়ার মতো অতিরিক্ত block device আপনার থাকে। dir driver-কে অন্যগুলোর তুলনায় অনেক ধীর বলা হয়েছে, কারণ এটি copy-on-write ব্যবহার না করে file copy করে। তাই প্রতিটি snapshot-এ পুরো container আবার লেখা হয়। incus admin init --minimal, dir নির্বাচন করে। এ কারণে interactive প্রশ্নগুলোর উত্তর দিতে দুই মিনিট ব্যয় করা সার্থক। incus storage create fast btrfs size=30GiB দিয়ে pool তৈরি করুন।

আমার Incus container host-এ চলমান service-এ পৌঁছাতে পারে কেন?

কারণ default incusbr0 bridge gateway address-এ host-কে container-এর একই subnet-এ রাখে। Incus এই bridge-এ যে firewall rule যোগ করে, সেগুলো networking সচল রাখার জন্য, host-কে block করার জন্য নয়। কোনো host service 0.0.0.0-এ bind করা থাকলে সেখানে উত্তর দেবে, যদি না host firewall rule packet drop করে। Packet-গুলো machine ছেড়ে যায় না বলে আপনার provider-এর firewall সেগুলো দেখতে পায় না। Host service-গুলো 127.0.0.1-এ bind করুন। ufw host-এ blanket sudo ufw allow in on incusbr0-এর পরিবর্তে শুধু DNS এবং DHCP-কে incusbr0-এ inbound অনুমতি দিন।

Incus container-এর backup কীভাবে নেব?

incus export web /root/web-backup.tar.gz instance এবং তার snapshot-গুলো একটি file-এ লেখে, আর incus import সেটি একই server বা অন্য server-এ restore করে। incus snapshot create দিয়ে তৈরি snapshot backup নয়। এগুলো একই disk-এর একই storage pool-এ থাকে। তাই খারাপ upgrade-এর পর এগুলো টিকে থাকে, কিন্তু server নষ্ট হলে নয়। incus config set web snapshots.schedule=@daily দিয়ে snapshot schedule করুন এবং export-গুলো server-এর বাইরে কপি করুন।