Namespace ও Cgroups — একটা 'container' আসলে কী

PID namespace — ভেতরে কী আছে

process-anatomy লেসনে দেখা হয়েছিল প্রতিটা process-এর একটা task_struct-এ pid_t pid ফিল্ড থাকে। কিন্তু PID namespace-এর পর সেই ছবিটা একটু বেশি সূক্ষ্ম — একটা process-এর একটাই PID থাকে না, বরং একাধিক, একটা করে প্রতিটা namespace-এ যেখানে সে দৃশ্যমান।

Namespace-গুলো hierarchical — একটা child namespace তার parent-এর “ভেতরে” নেস্ট করা থাকে। একটা process যদি একটা নেস্টেড child PID namespace-এ জন্মায়, সে দৃশ্যমান থাকে সেই namespace-এ এবং তার সব ancestor namespace-এ (parent, grandparent… root পর্যন্ত), কিন্তু কখনো sibling বা deeper namespace-এ না। প্রতিটা দৃশ্যমান স্তরে তার একটা ভিন্ন সংখ্যা থাকে।

Host (root PID namespace)         → এই process-এর PID = 48213
  └── Container A (নতুন PID ns)   → একই process-এর PID = 1

Container-এর ভেতরের init/entrypoint process নিজেকে PID 1 হিসেবে দেখে (echo $$ → 1), অথচ host থেকে ps aux চালালে সেই একই process একটা সাধারণ, বড় PID নিয়ে (যেমন 48213) তালিকায় থাকে। দুইটাই সত্যি, দুইটাই একই process — শুধু দুইটা ভিন্ন namespace থেকে দেখা।

Mount namespace — private filesystem tree

vfs-layer লেসনে mount tree-র কাঠামো দেখা হয়েছিল — কীভাবে আলাদা আলাদা filesystem একটা একক গাছে জোড়া লাগে। Mount namespace এই পুরো গাছের একটা ব্যক্তিগত কপি দেয় একটা process-কে।

নতুন mount namespace তৈরি হলে সেটা parent-এর মুহূর্তের mount table-এর একটা কপি নিয়ে শুরু করে, কিন্তু এরপর থেকে সম্পূর্ণ স্বাধীন — নতুন namespace-এ কিছু mount/unmount করলে সেটা (ঠিকভাবে সেট করা থাকলে) parent-এর namespace-কে প্রভাবিত করে না, আর উল্টোটাও।

vfs-layer লেসনের bind mount ধারণাটা এখানে চূড়ান্তভাবে কাজে লাগে — একটা container-এর rootfs আসলে হোস্টের ফাইলসিস্টেমের একটা অংশ, pivot_root()/chroot() দিয়ে সেটাকেই নতুন mount namespace-এর / বানিয়ে দেওয়া হয়। Container যা /etc/passwd বলে ভাবছে, সেটা আসলে host-এর ডিস্কে একটা সম্পূর্ণ ভিন্ন path-এ বসে থাকা একটা ফাইল — mount namespace আর bind mount-এর সমন্বয়েই এই বিভ্রম তৈরি হয়।

Network namespace — private network stack

নতুন network namespace মানে নতুন network interface list (শুরুতে শুধু একটা বিচ্ছিন্ন lo, loopback), নতুন routing table, নতুন iptables rule set, নতুন port space। এই শেষ পয়েন্টটাই সবচেয়ে ব্যবহারিক: একটা process নিজের net namespace-এ port 80-এ bind করতে পারে, host-এর port 80 ইতিমধ্যে অন্য কিছু ব্যবহার করলেও — দুইটা সম্পূর্ণ ভিন্ন port space, কোনো conflict নেই।

নিজে থেকে একটা net namespace বাইরের জগতের সাথে সংযুক্ত না — সাধারণত একটা veth pair (virtual ethernet, একটা cable-এর দুই প্রান্তের মতো) দিয়ে জোড়া হয়: এক প্রান্ত container-এর net namespace-এ, আরেক প্রান্ত host-এর namespace-এ একটা bridge-এ, তারপর NAT বা routing দিয়ে বাইরের নেটওয়ার্কে।

UTS ও IPC namespace — ছোট কিন্তু বাস্তব

UTS namespace সবচেয়ে সহজ — শুধু hostname আর NIS domain name। sethostname() কল করলে শুধু বর্তমান namespace-এর hostname বদলায়, host-এর না। এই সরলতার কারণেই এটা প্রায়ই সবচেয়ে ভালো প্রথম উদাহরণ — কোনো জটিল filesystem বা network setup ছাড়াই namespace isolation চোখে দেখা যায়।

IPC namespace System V IPC-র (semaphore, shared memory segment, message queue) id space আলাদা করে, আর POSIX message queue-ও। এই মডিউলের IPC-সংক্রান্ত লেসনে (shared memory, message queue) যেই shmget()/msgget() id-গুলো দেখা হয়েছে বা হবে, সেগুলো আসলে namespace-স্কোপড — দুইটা container একই সংখ্যার IPC id ব্যবহার করলেও তারা সম্পূর্ণ ভিন্ন, বিচ্ছিন্ন object পাবে, একে অপরের data দেখতে বা touch করতে পারবে না।

User namespace — সবচেয়ে গুরুত্বপূর্ণ, গভীরে যাওয়া দরকার

বাকি পাঁচটা namespace “কী দেখা যায়” নিয়ন্ত্রণ করে। User namespace একটু আলাদা — এটা নিয়ন্ত্রণ করে কে কতটা ক্ষমতাবান, আর এটাই সবচেয়ে দেরিতে (২০১৩) সম্পূর্ণ হওয়া, সবচেয়ে জটিল, আর নিরাপত্তার দিক থেকে সবচেয়ে তাৎপর্যপূর্ণ namespace।

কেন্দ্রীয় ধারণা: একটা process user namespace-এর ভেতরে নিজেকে UID 0 (root) হিসেবে দেখতে পারে, অথচ host থেকে দেখলে সেই একই process একটা সাধারণ, unprivileged UID (যেমন 1000)।

এটা সম্ভব হয় UID/GID mapping দিয়ে — /proc/[pid]/uid_map আর /proc/[pid]/gid_map ফাইলে লেখা হয় “namespace-এর ভেতরের ID, বাইরের প্রকৃত ID, দৈর্ঘ্য”:

echo "0 1000 1" > /proc/48213/uid_map
# অর্থ: namespace-এর ভেতরে UID 0 ↔ host-এ প্রকৃত UID 1000, ১টা ID

কেন এটা rootless container সম্ভব করে: kernel-এর capability check (ns_capable()) সবসময় একটা নির্দিষ্ট user namespace-এর সাপেক্ষে হয়, global ভাবে না। একটা process যদি তার নিজের user namespace-এ UID 0-এ mapped থাকে, সে সেই namespace-এর নিজস্ব resource-এর (নিজের তৈরি mount, নিজের net namespace-এর ভেতরের device) উপর root-এর ক্ষমতা পায় — কিন্তু host-এর প্রকৃত ফাইল, প্রকৃত process, প্রকৃত network-এর উপর কোনো বাড়তি ক্ষমতা পায় না। “namespace-এর ভেতরে root” আর “মেশিনের root” — সম্পূর্ণ আলাদা দুইটা জিনিস।

এই একটা ধারণাই Podman, rootless Docker, আর বেশিরভাগ আধুনিক container runtime-এর ভিত্তি — কোনো root daemon ছাড়াই একটা সাধারণ ব্যবহারকারী নিজের container “root” হিসেবে চালাতে পারে, অথচ host-এর নিরাপত্তা সীমানা অক্ষত থাকে।

Cgroups-এর ভেতর — enforcement বাস্তব, advisory না

/sys/fs/cgroup-এ একটা directory বানানো মানে একটা নতুন group। একটা process-কে সেই group-এ ঢোকাতে তার PID cgroup.procs ফাইলে লিখতে হয়:

mkdir /sys/fs/cgroup/my-group
echo $$ > /sys/fs/cgroup/my-group/cgroup.procs   # বর্তমান shell-কে যোগ করুন

Child process স্বয়ংক্রিয়ভাবে parent-এর cgroup উত্তরাধিকার সূত্রে পায় — এই শেলের ভেতর থেকে যা কিছু চালানো হবে, সবই my-group-এর সদস্য হয়ে যাবে, আলাদা করে কিছু করতে হবে না।

Enforcement কোথায় ঘটে — kernel-এর ভেতরের হুক পয়েন্ট:

• CPU: scheduler নিজেই (linux-schedulers লেসনের CFS/EEVDF) প্রতিটা cgroup-কে একটা নেস্টেড scheduling entity হিসেবে ট্রিট করে — cpu.max (hard quota, একটা period-এ নির্দিষ্ট সময়ের বেশি চলতেই দেয় না) বা cpu.weight (relative share, ঠিক nice value-র মতো, কিন্তু group-স্তরে)।
• Memory: প্রতিটা page allocation-এ (page-faults-and-demand-paging লেসনের page fault handler) kernel চেক করে current process-এর cgroup-এর usage memory.max ছাড়িয়ে যাচ্ছে কি না। ছাড়ালে প্রথমে reclaim চেষ্টা করে (সেই লেসনের active/inactive list, swap), তাতেও জায়গা না হলে সেই cgroup-এর ভেতর থেকেই একটা process বেছে SIGKILL পাঠায় — সিস্টেম-ব্যাপী OOM killer না, একটা group-স্কোপড সংস্করণ।
• IO: block layer-এ প্রতিটা request submit-এর সময় io.max চেক হয়, প্রয়োজনে throttle করা হয়।
• PIDs: fork()/clone()-এর সময় (fork-exec-wait লেসন) kernel চেক করে group-এর pids.max ছাড়িয়ে যাচ্ছে কি না — ছাড়ালে fork() নিজেই EAGAIN দিয়ে ব্যর্থ হয়, fork bomb-কে উৎসেই থামিয়ে দেয়।

এই প্রতিটা hook বিদ্যমান, স্বাধীন kernel subsystem-এর ভেতরেই বসানো — cgroups কোনো নতুন, সমান্তরাল enforcement engine না, এটা বিদ্যমান scheduler, page-fault handler, block layer, আর fork path-এর ভেতরে একটা অতিরিক্ত চেক।

কেন্দ্রীয় প্রমাণ — kernel-এ “container” নামে কিছুই নেই

এখন সরাসরি kernel-এর data structure দেখা যাক, কারণ কথায় না, কোডে প্রমাণ করাই এই লেসনের লক্ষ্য।

প্রতিটা task_struct-এ (মনে করুন process-anatomy লেসনের কঙ্কাল সংস্করণ) তিনটা pointer আছে যেগুলো একসাথে namespace আর cgroup membership নির্ধারণ করে:

/* সরলীকৃত, ধারণাগতভাবে সঠিক — kernel/nsproxy.h */
struct nsproxy {
    atomic_t count;
    struct uts_namespace     *uts_ns;
    struct ipc_namespace     *ipc_ns;
    struct mnt_namespace     *mnt_ns;
    struct pid_namespace     *pid_ns_for_children;
    struct net               *net_ns;
    struct cgroup_namespace  *cgroup_ns;
};

struct task_struct {
    /* ... হাজারো অন্য ফিল্ড ... */
    struct nsproxy *nsproxy;   /* কোন ৬টা namespace-এ আছে */
    struct cred    *cred;      /* cred->user_ns — কোন user namespace */
    struct css_set *cgroups;   /* কোন cgroup-এ আছে */
};

লক্ষ করুন — user namespace থাকে nsproxy-তে না, cred-এ। এটা ইচ্ছাকৃত ও অর্থবহ: user namespace সরাসরি credential/permission-এর অংশ, তাই সেটা সেখানেই থাকা যুক্তিসঙ্গত। কিন্তু যেখানেই থাকুক — এটাও শেষ পর্যন্ত একটা সাধারণ pointer, যা একটা প্রক্রিয়ার task_struct-এই আগে থেকে বিদ্যমান ছিল।

task_struct   (এইটাই — শুধু এইটাই — একটা "container" প্রসেস)
│
├── nsproxy ─────────┬── uts_namespace      (hostname)
│                     ├── ipc_namespace      (SysV IPC id space)
│                     ├── mnt_namespace      (mount tree)
│                     ├── pid_namespace_for_children
│                     ├── net               (net_namespace)
│                     └── cgroup_namespace
│
├── cred ────────────────── user_namespace   (UID/GID mapping)
│
└── cgroups (css_set) ───── cgroup path      (memory.max, cpu.max...)

এই একটা diagram-ই এই লেসনের punchline-এর সম্পূর্ণ প্রমাণ। docker run চালালে kernel-এ কোনো নতুন struct type allocate হয় না। একটা সাধারণ task_struct তৈরি হয় (ঠিক যেভাবে প্রতিটা fork()/clone()-এ হয়), আর তার nsproxy pointer কিছু নতুন namespace struct-এর দিকে নির্দেশ করে, cred->user_ns একটা নতুন user namespace-এর দিকে, আর cgroups একটা নির্দিষ্ট cgroup path-এর দিকে। container = process + কিছু pointer, ব্যস।