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

Incus সিস্টেম কন্টেইনার কী

VPS-এ Incus সিস্টেম কন্টেইনার আপনাকে একটি পূর্ণাঙ্গ মেশিন ব্যবহারের সুবিধা দেয়, যার নিজস্ব init সিস্টেম এবং ইউজার অ্যাকাউন্ট থাকে। এটি কেবল একটি ফাইলসিস্টেমসহ একক কোনো প্রসেস নয়। কন্টেইনারটি বুট হয়, PID 1 হিসেবে একটি init প্রসেস চালায় এবং systemctl-এর মাধ্যমে সাড়া দেয়। এটি হোস্টের কার্নেল শেয়ার করে, তাই এটি ভার্চুয়াল মেশিন নয়। তবে কার্নেলের উপরের সবকিছু একটি ভার্চুয়াল মেশিনের মতোই আচরণ করে।

Incus হলো LXD-এর একটি কমিউনিটি ফর্ক, যা Linux Containers প্রজেক্টের অধীনে রক্ষণাবেক্ষণ করা হয়। এর ক্লায়েন্ট কমান্ড হলো incus। আপনি যদি --vm ফ্ল্যাগ ব্যবহার করেন, তবে এটি QEMU-এর মাধ্যমে প্রকৃত ভার্চুয়াল মেশিনও চালাতে পারে। তবে সিস্টেম কন্টেইনার ব্যবহারের জন্যই বেশিরভাগ মানুষ এটি ইনস্টল করেন এবং এই গাইডের বাকি অংশে এটি নিয়েই আলোচনা করা হয়েছে।

কেন 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-এর ভার্চুয়ালাইজেশন ধরন এবং কার্নেলের ওপর নির্ভর করে, তাই কোনো কিছু ইনস্টল করার আগে উভয়ই যাচাই করে নিন। কোনো প্রোভাইডারের মার্কেটিং পেজের তথ্যের ওপর নির্ভর করবেন না। সার্ভারে নিচের চারটি কমান্ড চালান।

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 (control group) v1 বা হাইব্রিড লেআউটে আছে, যা বর্তমান Incus সমর্থন করে না।

cat /sys/fs/cgroup/cgroup.controllers কমান্ডটি আপনার জন্য বরাদ্দকৃত কন্ট্রোল-গ্রুপ কন্ট্রোলারগুলোর তালিকা দেখায়। Incus-এর ডকুমেন্টেশন অনুযায়ী blkio, cpuset, devices, freezer, memory এবং pids থাকা আবশ্যক। একটি নেস্টেড VPS-এ এই তালিকা প্রায়শই KVM VPS-এর তুলনায় ছোট হয়, কারণ প্রোভাইডার নির্ধারণ করে দেয় কোনগুলো আপনাকে দেওয়া হবে। এই ফাইলে কোনো কন্ট্রোলার অনুপস্থিত থাকলে Incus সেটি ব্যবহার করতে পারবে না, ফলে সেই কন্ট্রোলারের ওপর নির্ভরশীল ইনস্ট্যান্স লিমিট আপনি ব্যবহার করতে পারবেন না।

কার্নেল ভার্সন আগের চেয়ে এখন অনেক বেশি গুরুত্বপূর্ণ। আগস্ট 2026 অনুযায়ী, Incus ডকুমেন্টেশনে আপস্ট্রিম দ্বারা রক্ষণাবেক্ষণ করা দুটি শাখার জন্য দুটি ভিন্ন ন্যূনতম ভার্সন উল্লেখ করা হয়েছে। 6.0 LTS (long term support) শাখার জন্য বলা হয়েছে "ন্যূনতম সমর্থিত কার্নেল ভার্সন 5.4।" বর্তমান স্টেবল শাখার জন্য বলা হয়েছে "ন্যূনতম সমর্থিত কার্নেল ভার্সন 6.12।" Ubuntu 24.04 তাদের নিজস্ব রিপোজিটরিতে 6.0 LTS সিরিজ প্যাকেজ করে এবং এটিকে 6.8 কার্নেলের সাথে যুক্ত করে, যা একটি সমর্থিত কম্বিনেশন। সেই একই 6.8 কার্নেলে আপস্ট্রিম রিপোজিটরি থেকে বর্তমান স্টেবল বিল্ড ইনস্টল করলে তা ডকুমেন্টেশনে উল্লিখিত ন্যূনতম ভার্সনের নিচে চলে যাবে, তাই রিপোজিটরি বেছে নেওয়ার আগে uname -r পড়ে নিন।

আপনার লক্ষ্য যদি কন্টেইনারের পরিবর্তে পূর্ণাঙ্গ ভার্চুয়াল মেশিন হয়, তবে সীমাবদ্ধতা ভিন্ন এবং আরও কঠিন। আপনার VPS আদৌ /dev/kvm এক্সপোজ করতে পারে কি না তা জানতে VPS-এ নেস্টেড ভার্চুয়ালাইজেশন দেখুন এবং আপনি যদি হার্ডওয়্যারের মালিক হন তবে ভাড়াকৃত 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-কে RUNNING হিসেবে এবং incusbr0 সাবনেটে একটি IPv4 অ্যাড্রেসসহ দেখাবে। কোনো অ্যাড্রেস না থাকলে বুঝতে হবে DHCP (dynamic host configuration protocol) সম্পন্ন হয়নি, যা নেটওয়ার্কিং সেকশনে কভার করা হয়েছে। কোনো কন্টেইনার স্টার্ট হতে ব্যর্থ হলে তার কারণ incus info web --show-log-এ প্রিন্ট হয়, এবং ডেমোন-লেভেলের ব্যর্থতাগুলো 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 হলো কপি-অন-রাইট (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 রক্ষণাবেক্ষণের দিক থেকে তুলনামূলক সহজ।

তিনটি নেটওয়ার্কিং মোড এবং প্রতিটি যা উন্মুক্ত করে

incus admin init একটি ম্যানেজড ব্রিজ তৈরি করে যার নাম incusbr0 এবং প্রতিটি নতুন ইনস্ট্যান্সকে এর সাথে যুক্ত করে। কন্টেইনার যুক্ত করার তিনটি পদ্ধতির মধ্যে এটি একটি, এবং বাকি দুটি পদ্ধতির অস্তিত্বের কারণ হলো প্রথমটি আপনার কন্টেইনারগুলোকে NAT (network address translation)-এর আড়ালে লুকিয়ে রাখে।

ম্যানেজড ব্রিজ (Managed bridge)। incusbr0 একটি প্রাইভেট সাবনেট পায়। হোস্ট এই সাবনেটের প্রথম ঠিকানাটি ধারণ করে এবং গেটওয়ে হিসেবে কাজ করে, Incus এর ওপর DHCP এবং DNS (domain name system) পরিচালনা করে এবং আউটবাউন্ড ট্রাফিক সোর্স NAT প্রয়োগের মাধ্যমে হোস্টের পাবলিক অ্যাড্রেস দিয়ে বের হয়। আপনি নির্দেশ না দেওয়া পর্যন্ত বাইরের কেউ কন্টেইনারে পৌঁছাতে পারে না। একটি প্রক্সি ডিভাইসের মাধ্যমে পোর্ট ফরওয়ার্ড করুন।

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 রুল ব্যবহার করে ফরওয়ার্ড করে, তাই ক্লায়েন্টের আসল ঠিকানা কন্টেইনারের লগে সংরক্ষিত থাকে। Incus শুধুমাত্র তখনই এই মোড সমর্থন করে যখন হোস্ট ইনস্ট্যান্সের গেটওয়ে হিসেবে কাজ করে, যা ঠিক incusbr0-এর ক্ষেত্রে ঘটে।

macvlan। কন্টেইনার হোস্টের ফিজিক্যাল নেটওয়ার্কে নিজস্ব MAC (media access control) ঠিকানা পায়। বেশিরভাগ VPS প্ল্যাটফর্মে এটি কাজ করে না, কারণ ভার্চুয়াল সুইচ পোর্টটি আপনার VM-এর MAC ঠিকানার সাথে আবদ্ধ থাকে এবং অন্য কোনো MAC থেকে আসা ফ্রেম ড্রপ করে। দ্বিতীয় একটি সীমাবদ্ধতা রয়েছে যা কাজ করার ক্ষেত্রেও সমস্যা তৈরি করে। Incus-এর ডকুমেন্টেশন অনুযায়ী, "macvlan ডিভাইসগুলো নিজেদের মধ্যে এবং বাইরের সাথে যোগাযোগ করতে পারলেও, তাদের প্যারেন্ট ডিভাইসের সাথে কথা বলতে পারে না। এর মানে হলো, যদি আপনার ইনস্ট্যান্সগুলোর হোস্টের সাথে যোগাযোগের প্রয়োজন হয়, তবে আপনি macvlan ব্যবহার করতে পারবেন না।"

রাউটেড (Routed)। এটি সেই মোড যা সাধারণত অতিরিক্ত আইপি অ্যাড্রেসসহ VPS-এ কাজ করে। Incus এই ডিভাইসটিকে এমনভাবে বর্ণনা করে যা "হোস্টকে ইনস্ট্যান্সের সাথে সংযুক্ত করার জন্য একটি ভার্চুয়াল ডিভাইস পেয়ার তৈরি করে এবং ইনস্ট্যান্সকে নির্ধারিত প্যারেন্ট ইন্টারফেসের নেটওয়ার্কে যোগ দেওয়ার অনুমতি দেওয়ার জন্য স্ট্যাটিক রুট এবং প্রক্সি ARP/NDP এন্ট্রি সেট আপ করে"। ARP হলো অ্যাড্রেস রেজোলিউশন প্রোটোকল। কন্টেইনার একটি পাবলিক অ্যাড্রেস ধরে রাখে। হোস্ট এর জন্য ARP-এর উত্তর দেয়, তাই প্রোভাইডার শুধুমাত্র হোস্টের MAC ঠিকানাই দেখতে পায়।

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

ip route show default থেকে প্যারেন্ট ইন্টারফেসের নাম নিন। বর্তমান ইমেজগুলো enp1s0 বা ens3-এর মতো নাম ব্যবহার করে, খুব কম ক্ষেত্রে eth0 দেখা যায়। ডিভাইসটির নাম eth0 রাখলে তা default প্রোফাইল দ্বারা সরবরাহকৃত নামটিকে ওভাররাইড করে, ফলে কন্টেইনারটি ব্রিজের পরিবর্তে রাউটেড ইন্টারফেসে যুক্ত হয়। কন্টেইনারের ভেতর থেকে 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 বক্সে ডিফল্ট ডিনাই পলিসি কন্টেইনার থেকে হোস্টে আসা ট্রাফিককে ব্লক করে দেয়, যা 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-এর রাউটেড পলিসি ফরওয়ার্ড করা প্যাকেটগুলোকে ড্রপ করে দেয়, ফলে কন্টেইনারগুলো একটি অ্যাড্রেস পেলেও কোথাও পৌঁছাতে পারে না।

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

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

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 একটি একক প্রসেস বা অ্যাপ্লিকেশনকে প্যাকেজ করে। একটি Incus system container একটি পূর্ণাঙ্গ অপারেটিং সিস্টেমকে সিমুলেট করে, যার নিজস্ব init, নিজস্ব ইউজার, নিজস্ব সার্ভিস এবং নিজস্ব প্যাকেজ ম্যানেজার থাকে। আপনি একটি Incus container-কে একটি সার্ভারের মতোই রক্ষণাবেক্ষণ এবং প্যাচ করতে পারেন। অন্যদিকে, একটি Docker container-কে ফেলে দিয়ে ইমেজ থেকে নতুন করে তৈরি করতে হয়। আপনি container-এ security.nesting=true সেট করে Incus container-এর ভেতরে Docker চালাতে পারেন। তবে এর বিপরীতটি সম্ভব নয়।

আমি কি VPS-এ Incus চালাতে পারি?

KVM VPS-এর ক্ষেত্রে, হ্যাঁ। systemd-detect-virt কমান্ডটি যদি kvm বা qemu আউটপুট দেয়, তবে আপনার নিজস্ব কার্নেল রয়েছে এবং Incus হার্ডওয়্যারের মতোই কাজ করবে। যদি এটি lxc, lxc-libvirt বা openvz আউটপুট দেয়, তবে আপনার VPS নিজেই একটি কন্টেইনার, তাই এর ভেতরে Incus কন্টেইনারগুলো নেস্টেড (nested) হিসেবে কাজ করবে এবং এটি তখনই কাজ করবে যদি আপনার প্রোভাইডার আপনার কন্টেইনারে নেস্টিং সুবিধা চালু রাখে। এছাড়া uname -r-ও চেক করুন, কারণ আগস্ট 2026 অনুযায়ী বর্তমান Incus stable branch-এর জন্য ন্যূনতম 6.12 কার্নেল প্রয়োজন, যেখানে 6.0 LTS branch-এর জন্য 5.4 কার্নেল উল্লেখ করা আছে।

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

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

আমার Incus কন্টেইনার কেন হোস্টের কোনো সার্ভিস অ্যাক্সেস করতে পারে?

কারণ ডিফল্ট incusbr0 ব্রিজ হোস্ট এবং কন্টেইনারকে একই সাবনেটে, গেটওয়ে অ্যাড্রেসে রাখে এবং তাদের মাঝে কোনো ফিল্টারিং থাকে না। 0.0.0.0-এ বাইন্ড করা যেকোনো হোস্ট সার্ভিস সেখানে সাড়া দেয় এবং আপনার প্রোভাইডারের ফায়ারওয়াল সেই প্যাকেটগুলো দেখতে পায় না কারণ সেগুলো মেশিন থেকে বাইরে যায় না। হোস্ট সার্ভিসগুলোকে 127.0.0.1-এ বাইন্ড করুন এবং ufw হোস্টের ক্ষেত্রে পুরো sudo ufw allow in on incusbr0-এর পরিবর্তে শুধুমাত্র incusbr0-এ DNS এবং DHCP ট্রাফিক অনুমতি দিন।

আমি কীভাবে একটি Incus কন্টেইনার ব্যাকআপ নেব?

incus export web /root/web-backup.tar.gz কমান্ডটি ইনস্ট্যান্স এবং এর স্ন্যাপশটগুলোকে একটি ফাইলে লিখে রাখে এবং incus import সেটি একই সার্ভারে বা অন্য কোনো সার্ভারে রিস্টোর করে। incus snapshot create দিয়ে তৈরি স্ন্যাপশটগুলো ব্যাকআপ নয়: এগুলো একই ডিস্কের একই স্টোরেজ পুলে থাকে, তাই এগুলো ভুল আপগ্রেড থেকে রক্ষা করলেও সার্ভার নষ্ট হয়ে গেলে কোনো কাজে আসে না। incus config set web snapshots.schedule=@daily দিয়ে ব্যাকআপ শিডিউল করুন এবং এক্সপোর্ট করা ফাইলগুলো সার্ভারের বাইরে কপি করে রাখুন।