Container-এর ভেতর — namespace, cgroup আর Docker

১ · Container আসলে কী — আলাদা চশমা পরা একটি সাধারণ প্রসেস

এই কোর্সের অনেক পর্বে আপনি এই পাতার অনলাইন রানারে কোড চালিয়েছেন, আর বারবার কিছু অদ্ভুত জিনিস চোখে পড়েছে। পর্ব ৭-এ দেখেছেন PID 1 হলো podman-init, systemd নয়। পর্ব ৪২-এ দেখেছেন root file system একটি overlay. পর্ব ২১ আর ৩৮-এ /sys/fs/cgroup/cpu.max আর memory.max পড়েছেন, আর পর্ব ৪৯-এ দেখেছেন প্রতিটি প্রসেসে আগে থেকেই একটি seccomp filter বসানো। সবগুলো সূত্র একই দিকে ইঙ্গিত করে: রানারটি একটি container. এই পর্বে সেই ধাঁধাটি পুরো খুলব।

প্রথমেই একটি ভুল ধারণা দূর করা যাক। অনেকে container-কে “ছোট virtual machine” ভাবেন। তা নয়। পর্ব ৫০-এর virtual machine-এ একটি পুরো আলাদা OS চলে, নিজের kernel সহ, আর hypervisor তাকে নকল হার্ডওয়্যার দেয়। Container-এ আলাদা kernel নেই। Container হলো host-এর kernel-এ চলা একটি (বা কয়েকটি) সাধারণ প্রসেস, যার ওপর kernel তিনটি জিনিস চাপিয়ে দিয়েছে:

• আলাদা দৃশ্য (namespace): প্রসেসটি কোন ফাইল, কোন প্রসেস, কোন নেটওয়ার্ক, কোন hostname আর কোন user দেখবে — তার নিজস্ব কপি।
• সীমিত রিসোর্স (cgroup): কতটা CPU, মেমরি, কতগুলো প্রসেস, কতটা ডিস্ক-I/O ব্যবহার করতে পারবে — সীমা আর হিসাব।
• নিজের file system (image + overlay) আর সুরক্ষা-স্তর: একটি তৈরি করা ফোল্ডার-গাছ, যা root হিসেবে দেখানো হয়; তার ওপর পর্ব ৪৯-এর seccomp, capability আর AppArmor/SELinux.

দুটির মিশ্র রূপও আছে (microVM, gVisor), আর কখন কোনটি বেছে নেবেন — সেই আলোচনা পর্ব ৫২-এ। এখানে মনে রাখার কথা একটাই: container-এর সব জাদু kernel-এর ভেতরে, আর সেগুলো আমরা এই পর্বে একে একে খুলে দেখব।

২ · ইতিহাস — chroot থেকে Kubernetes

Container নতুন আবিষ্কার নয়; প্রায় চার দশক ধরে ধাপে ধাপে জমা হওয়া ধারণার সমষ্টি। নিচের তারিখগুলো সাধারণভাবে উদ্ধৃত হয়, তবে কোনো বৈশিষ্ট্য কোন মাসে বা কোন সংস্করণে “সম্পূর্ণ” হলো, তা নিয়ে সূত্রভেদে সামান্য পার্থক্য দেখবেন।

এই ইতিহাসের শিক্ষা হলো: kernel-এর যন্ত্রগুলো Docker-এর অনেক আগেই ছিল, কিন্তু ব্যবহার করা কঠিন ছিল। যেমন বাংলাদেশে মোবাইল ব্যাংকিংয়ের প্রযুক্তি আগে থেকেই ছিল, কিন্তু সহজ অ্যাপ আর এজেন্ট-ব্যবস্থা আসার পরই তা সবার কাছে পৌঁছায় — সুবিধাজনক মোড়ক প্রযুক্তিকে গণমানুষের করে।

৩ · আটটি namespace — kernel-এর বৈশ্বিক জিনিসের নিজস্ব কপি

সাধারণ Linux-এ অনেক কিছু “বৈশ্বিক”: একটিই প্রসেস-তালিকা, একটিই mount table, একটিই hostname, একটিই নেটওয়ার্ক-স্ট্যাক। Namespace এর একটি জিনিসকে মোড়কে ঢাকে, যাতে একদল প্রসেস নিজস্ব কপি দেখে আর ভাবে সেটিই পুরো সিস্টেম। এখন Linux-এ আট রকম namespace আছে:

খেয়াল করুন, mount namespace-এর flag-এর নাম শুধু CLONE_NEWNS — “new namespace”. ২০০২ সালে এটিই একমাত্র namespace ছিল, তাই কেউ ভাবেননি যে পরে আরও আসবে। আর time namespace শুধু “বুটের পর কত সময় গেল” ধরনের ঘড়ি বদলায় (যেমন একটি container এক যন্ত্র থেকে আরেক যন্ত্রে সরালে ঘড়ি যেন পিছিয়ে না যায়); আসল তারিখ-সময় (CLOCK_REALTIME) সবার এক।

তিনটি syscall

• clone() (পর্ব ১৪-এ থ্রেড বানাতে দেখেছেন): flag-এ CLONE_NEW* দিলে নতুন প্রসেসটি জন্ম থেকেই নতুন namespace-এ। container runtime প্রধানত এটিই ব্যবহার করে।
• unshare(): চলমান প্রসেস নিজেকে নতুন namespace-এ সরায়। ব্যতিক্রম PID আর time: এ দুটিতে প্রসেস নিজে সরে না, শুধু পরের সন্তানেরা নতুনটিতে জন্মায় — তাই /proc/self/ns-এ pid_for_children আর time_for_children নামের আলাদা লিংক থাকে। একই নামের একটি কমান্ডও আছে, util-linux-এর unshare.
• setns(): একটি বিদ্যমান namespace-এর file descriptor (যেমন /proc/<pid>/ns/net খুলে) দিয়ে সেটিতে যোগ দেওয়া। docker exec আর nsenter এভাবেই চলমান container-এর “ভেতরে” নতুন প্রসেস ঢোকায়।

প্রতিটি namespace kernel-এর একটি বস্তু, যার একটি পরিচয়-নম্বর (inode) আছে। দুটি প্রসেসের নম্বর এক হলে তারা একই namespace-এ। এবার এই পাতার রানারকে নিজের পরিচয় জিজ্ঞেস করি — সবই শুধু-পড়ার কমান্ড:

echo "== my namespaces: type -> type:[inode] =="
ls -l /proc/self/ns | awk 'NR > 1 {print $9, $10, $11}'
echo "== uid_map (inside-start  outside-start  count) =="
cat /proc/self/uid_map
echo "== gid_map =="
cat /proc/self/gid_map
echo "== who am I here? =="
id
echo "== who is PID 1 in this PID namespace? =="
cat /proc/1/cmdline | tr '\0' ' '; echo
echo "== NSpid of this shell (one number per PID namespace level) =="
grep NSpid /proc/$$/status
echo "== network interfaces in my network namespace =="
for i in /sys/class/net/*; do echo "${i##*/} mtu=$(cat "$i/mtu")"; done

== my namespaces: type -> type:[inode] ==
cgroup -> cgroup:[4026532822]
ipc -> ipc:[4026532820]
mnt -> mnt:[4026532817]
net -> net:[4026532747]
pid -> pid:[4026532821]
pid_for_children -> pid:[4026532821]
time -> time:[4026531834]
time_for_children -> time:[4026531834]
user -> user:[4026532740]
uts -> uts:[4026532819]
== uid_map (inside-start  outside-start  count) ==
         0       1000          1
         1     100000      65536
== gid_map ==
         0       1000          1
         1     100000      65536
== who am I here? ==
uid=999(wandbox) gid=999(wandbox) groups=999(wandbox)
== who is PID 1 in this PID namespace? ==
/run/podman-init -- /bin/bash prog.sh
== NSpid of this shell (one number per PID namespace level) ==
NSpid:	2
== network interfaces in my network namespace ==
lo mtu=65536
tap0 mtu=65520

এবার namespace নিজে বানিয়ে দেখি — C-তে। নিচের প্রোগ্রামে সন্তান-প্রসেস unshare(CLONE_NEWUSER | CLONE_NEWUTS) দিয়ে নতুন user আর UTS namespace-এ যায়, তারপর নিজের hostname বদলাতে চেষ্টা করে। বাবা পরে দেখে তার নিজের hostname বদলেছে কি না। সাধারণ ব্যবহারকারী নতুন UTS namespace বানাতে পারেন না, কিন্তু একই কলে নতুন user namespace বানালে সেই নতুন জগতে তিনি সব capability পান — তাই দুটি flag একসাথে।

#define _GNU_SOURCE
#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <sched.h>
#include <unistd.h>
#include <sys/wait.h>
int main(void) {
    char before[64] = "", after[64] = "", host[65], now[65];
    gethostname(host, sizeof host);
    fflush(stdout);                              /* empty the buffer before fork */
    if (fork() == 0) {
        readlink("/proc/self/ns/uts", before, sizeof before - 1);
        if (unshare(CLONE_NEWUSER | CLONE_NEWUTS) != 0) {
            printf("child: unshare failed: errno=%d (%s)\n", errno, strerror(errno));
            fflush(stdout); _exit(1);
        }
        readlink("/proc/self/ns/uts", after, sizeof after - 1);   /* "uts:[...]" */
        printf("child: unshare(NEWUSER|NEWUTS) = 0, new UTS namespace: %s\n",
               strcmp(before, after) != 0 ? "yes" : "no");
        if (sethostname("lab-box", 7) != 0)
            printf("child: sethostname failed: errno=%d (%s)\n", errno, strerror(errno));
        else if (gethostname(now, sizeof now) == 0)
            printf("child: my hostname is now %s\n", now);
        fflush(stdout); _exit(0);
    }
    wait(NULL);  gethostname(now, sizeof now);
    printf("parent: my hostname unchanged: %s\n", strcmp(now, host) == 0 ? "yes" : "no");
    return 0;
}

child: unshare(NEWUSER|NEWUTS) = 0, new UTS namespace: yes
child: sethostname failed: errno=1 (Operation not permitted)
parent: my hostname unchanged: yes

৪ · PID namespace আর PID 1 — একই প্রসেস, দুই নম্বর

PID namespace-এর জগৎগুলো একটি গাছের মতো সাজানো। নতুন namespace-এর প্রথম প্রসেস ভেতরে PID 1, কিন্তু বাবার namespace থেকে সে একটি সাধারণ বড় নম্বর। একটি প্রসেসের প্রতিটি পূর্বপুরুষ-স্তরে আলাদা নম্বর থাকে; /proc/<pid>/status-এর NSpid লাইনে বাইরের স্তর থেকে ভেতরের দিকে সেগুলো লেখা থাকে। নিয়ম একমুখী: বাইরে থেকে ভেতরের সবাইকে দেখা যায়, ভেতর থেকে বাইরের কাউকে নয় — বাড়ির দারোয়ান সব ফ্ল্যাটের লোক চেনেন, কিন্তু ফ্ল্যাটের ভেতর থেকে অন্য ফ্ল্যাটে কে আছে দেখা যায় না।

PID 1 হওয়া শুধু একটি নম্বর নয়, তিনটি দায়িত্বও। পর্ব ৭ আর ১৩-এ host-এর init-এর ক্ষেত্রে এগুলো দেখেছেন; container-এর ভেতরে এগুলো আপনার অ্যাপের ঘাড়ে পড়ে:

1. অনাথদের অভিভাবক: namespace-এর ভেতরে কোনো প্রসেসের বাবা মারা গেলে সেই orphan host-এর systemd-এর কাছে নয়, namespace-এর PID 1-এর কাছে যায় (যদি না মাঝে কোনো subreaper থাকে)।
2. Reaping: সেই সন্তান শেষ হলে PID 1-কে wait() ডাকতে হয়, নইলে সে zombie হয়ে PID দখল করে থাকে। দীর্ঘদিন চলা container-এ zombie জমে pids.max (অংশ ৫) পর্যন্ত পৌঁছালে নতুন প্রসেসই আর তৈরি হয় না।
3. Signal-এর বিশেষ নিয়ম: পর্ব ১৩-এ দেখেছেন, PID 1 যে signal-এর handler বসায়নি, ভেতর থেকে আসা সেই signal kernel ফেলে দেয় — ডিফল্ট “মরে যাও” কাজ করে না। তাই docker stop-এর SIGTERM অনেক অ্যাপ উপেক্ষা করে, আর ১০ সেকেন্ড পর SIGKILL আসে (বাবার namespace থেকে আসা SIGKILL আর SIGSTOP ঠেকানো যায় না)। আর PID 1 মারা গেলে kernel namespace-এর বাকি সব প্রসেসকে SIGKILL দেয় — পুরো container শেষ।

সমাধান হলো PID 1-এ একটি ছোট, নির্ভরযোগ্য init রাখা, যে signal অ্যাপের কাছে পৌঁছে দেয় আর orphan-দের reap করে: tini (Docker-এর docker run --init এটিই বসায়), dumb-init, আর Podman-এর podman-init — যা এই রানারেই দেখলেন (/run/podman-init -- /bin/bash prog.sh: init আগে, ---এর পরে আসল প্রোগ্রাম)। নিচে একটি container-এর জীবন ভেতর আর বাইরে — দুই চোখে দেখুন (host-এর PID নম্বরগুলো উদাহরণ):

৫ · cgroup — মিটার আর সীমা

Namespace ঠিক করে প্রসেস কী দেখবে; সে কতটা খাবে, তা ঠিক করে cgroup. Kernel প্রসেসগুলোকে একটি গাছে দল বাঁধে — প্রতিটি দল /sys/fs/cgroup-এর নিচে একটি ফোল্ডার — আর প্রতিটি দলের জন্য দুই কাজ করে: হিসাব (দলটি কতটা CPU-সময়, মেমরি, I/O খরচ করল) আর সীমা (এর বেশি নয়)। যে অংশ একটি নির্দিষ্ট রিসোর্স সামলায়, তাকে বলে controller:

v1 বনাম v2 — অনেক গাছ থেকে একটি গাছ

প্রথম সংস্করণে (v1, ২০০৮) প্রতিটি controller-এর নিজস্ব আলাদা গাছ থাকতে পারত: /sys/fs/cgroup/memory/…, /sys/fs/cgroup/cpu/…, /sys/fs/cgroup/blkio/…, আর একটি প্রসেস প্রতিটি গাছে ভিন্ন দলে থাকতে পারত। নমনীয় শোনায়, কিন্তু বাস্তবে বিশৃঙ্খলা — যেমন memory আর blkio আলাদা গাছে থাকায় “এই দলের নোংরা page লেখার I/O কার খাতায় যাবে” ঠিকমতো হিসাব করা যেত না, আর প্রতিটি controller-এর নিয়মও আলাদা ছিল। cgroup v2 (Linux 4.5, ২০১৬-তে স্থিতিশীল ঘোষিত) আনে একটিমাত্র গাছ (unified hierarchy): প্রতিটি প্রসেস ঠিক একটি দলে, আর সব controller সেই একই গাছে। নিয়ম পরিষ্কার: কোন controller একটি দলের সন্তানদের জন্য চালু, তা লেখা থাকে cgroup.subtree_control-এ; আর প্রসেস রাখা যায় শুধু পাতা-দলে (“no internal processes” নিয়ম)। আজকের বেশিরভাগ নতুন distro ডিফল্টে v2 ব্যবহার করে; পুরোনো সিস্টেমে v1 বা দুটির মিশ্রণ এখনো দেখবেন।

এই রানারের container নিজের cgroup সম্পর্কে কী জানে, দেখি। ফাইল না থাকলে স্ক্রিপ্ট থামবে না, শুধু জানাবে:

echo "== which cgroup am I in? (v2 line looks like 0::/path) =="
cat /proc/self/cgroup
cd /sys/fs/cgroup 2>/dev/null || { echo "no /sys/fs/cgroup here"; exit 0; }
echo "cgroup file system type: $(stat -f -c %T .)"
echo "== controllers enabled for this group =="
cat cgroup.controllers
show() {
    if [ -r "$1" ]; then printf '%-15s %s\n' "$1" "$(tr '\n' ' ' < "$1")"
    else printf '%-15s %s\n' "$1" "(no such file here)"; fi
}
echo "== limits and current usage =="
for f in memory.max memory.current memory.peak pids.max pids.current cpu.max cpu.weight io.max; do
    show "$f"
done
echo "== accounting counters =="
grep -E '^(usage_usec|nr_periods|nr_throttled)' cpu.stat
grep -E '^(max|oom_kill) ' memory.events
echo "processes in this cgroup: $(wc -l < cgroup.procs)"
mkdir /sys/fs/cgroup/mygroup 2>&1 || true

== which cgroup am I in? (v2 line looks like 0::/path) ==
0::/
cgroup file system type: cgroup2fs
== controllers enabled for this group ==
cpu memory pids
== limits and current usage ==
memory.max      max
memory.current  1232896
memory.peak     1400832
pids.max        2048
pids.current    4
cpu.max         max 100000
cpu.weight      100
io.max          (no such file here)
== accounting counters ==
usage_usec 32479
nr_periods 0
nr_throttled 0
max 0
oom_kill 0
processes in this cgroup: 4
mkdir: cannot create directory '/sys/fs/cgroup/mygroup': Read-only file system

সীমা বসানো হয় স্রেফ ফাইলে লিখে। একটি সাধারণ Linux-এ root হিসেবে হাতে-কলমে করলে (উদাহরণ, এই রানারে চলবে না):

# mkdir /sys/fs/cgroup/demo
# echo "+memory +pids +cpu" > /sys/fs/cgroup/cgroup.subtree_control
# echo 268435456 > /sys/fs/cgroup/demo/memory.max     # 256 MiB
# echo 64        > /sys/fs/cgroup/demo/pids.max
# echo "50000 100000" > /sys/fs/cgroup/demo/cpu.max  # 0.5 CPU
# echo $$ > /sys/fs/cgroup/demo/cgroup.procs          # move this shell in
# docker run --memory 256m --pids-limit 64 --cpus 0.5 nginx   # the same, via Docker

৬ · Image আর layer — overlayfs আর copy-up

Container-এর root file system আসে একটি image থেকে। OCI image মানদণ্ডে image তিন ধরনের জিনিস: একটি manifest (কোন কোন layer আর config, তাদের তালিকা), একটি config (কোন কমান্ড চালাবে, কোন environment variable, কোন user) আর কয়েকটি layer — প্রতিটি একটি সংকুচিত tar ফাইল, যাতে আগের layer-এর তুলনায় যোগ হওয়া, বদলানো বা মোছা ফাইল থাকে। প্রতিটি জিনিসের নাম তার নিজের SHA-256 hash (digest, যেমন sha256:3f1a…): বিষয়বস্তু এক বাইট বদলালেই নাম বদলায়। ফলে একই layer দুটি image-এ থাকলে ডিস্কে আর নেটওয়ার্কে একবারই লাগে, আর registry (Docker Hub, GitHub Container Registry, কোম্পানির নিজের registry) থেকে নামানোর সময় শুধু অনুপস্থিত layer আসে।

চালানোর সময় এই layer-গুলো একটির ওপর আরেকটি সাজিয়ে একটি গাছ দেখাতে হয়। কাজটি করে overlayfs (Linux 3.18, ২০১৪-তে মূল kernel-এ; তার আগে Docker AUFS ব্যবহার করত)। পর্ব ৪২-এ এর নাম দেখেছেন; এবার ভেতরটা:

• lowerdir — এক বা একাধিক শুধু-পড়ার ফোল্ডার (image-এর layer), কোলনে আলাদা, বাম দিকেরটি সবচেয়ে ওপরে।
• upperdir — এই container-এর নিজস্ব লেখার স্তর, শুরুতে খালি।
• workdir — upperdir-এর একই ফাইল সিস্টেমে একটি খালি ফোল্ডার, যেখানে overlayfs ফাইল আগে প্রস্তুত করে তারপর এক ধাক্কায় (atomic rename) upperdir-এ বসায়, যাতে মাঝপথে বিদ্যুৎ গেলেও আধা-কপি করা ফাইল না দেখা যায়।
• merged — যা container দেখে: একই নামের ফাইল ওপরের স্তরে থাকলে সেটি, নইলে নিচেরটি।

নিচের স্তর কখনো বদলায় না, তাই একই image থেকে একশোটি container চালালেও layer ডিস্কে একবারই থাকে, আর page cache-এও (পর্ব ৩৮) একবার। লেখার সময় কী ঘটে, ধাপে ধাপে দেখুন:

Dockerfile আর layer cache — সংক্ষেপে

Dockerfile-এর প্রায় প্রতিটি ফাইল-বদলানো নির্দেশ (RUN, COPY, ADD) একটি নতুন layer বানায়, আর build টুল প্রতিটি ধাপের ফল ক্যাশ করে: নির্দেশ আর তার ইনপুট (কপি করা ফাইলের hash) না বদলালে আগের layer আবার ব্যবহার হয়। কোনো ধাপ বদলালে সেই ধাপ আর তার পরের সব ধাপ নতুন করে চলে। তাই কম-বদলানো জিনিস আগে রাখুন:

# (a Dockerfile comment must start its own line; "#" after an instruction is not a comment)
# base layers, shared by many images
FROM node:20-slim
WORKDIR /app
COPY package.json package-lock.json ./
# cached until the lock file changes
RUN npm ci --omit=dev
# source changes only rebuild from here
COPY . .
# do not run as root inside
USER node
# exec form: node gets signals directly
CMD ["node", "server.js"]

উল্টো ক্রমে (COPY . . আগে) লিখলে কোডের একটি লাইন বদলালেও প্রতিবার সব dependency নতুন করে নামবে। শেষ লাইনের “exec form” (["node", …]) খেয়াল করুন: “shell form” (CMD node server.js) লিখলে PID 1 হয় /bin/sh, আর পর্ব ১৩-এর সেই SIGTERM-হারানো সমস্যা ফিরে আসে।

৭ · User namespace আর rootless container — ভেতরের root, বাইরের সাধারণ মানুষ

পুরোনো Docker-এ container-এর ভেতরের root আর host-এর root একই UID ০ — শুধু namespace, capability আর seccomp দিয়ে বাঁধা। কোনোভাবে বাঁধন ছিঁড়ে বেরোতে পারলে আক্রমণকারী host-এর আসল root. User namespace এই সমীকরণ বদলায়: প্রতিটি namespace-এর নিজস্ব UID-জগৎ, আর একটি মানচিত্র বলে দেয় ভেতরের কোন UID বাইরের কোন UID. /proc/<pid>/uid_map-এর প্রতিটি লাইন তিন সংখ্যার: ভেতরের শুরু, বাইরের শুরু, কয়টি. অংশ ৩-এর রানে আমাদের মানচিত্র ছিল:

         0       1000          1     # inside 0      -> outside 1000
         1     100000      65536     # inside 1-65536 -> outside 100000-165535

অর্থাৎ container-এর root (০) আসলে host-এর একজন সাধারণ ব্যবহারকারী, UID ১০০০ — যিনি Podman চালিয়েছেন। বাকি ৬৫৫৩৬টি UID host-এর ১০০০০০ থেকে ১৬৫৫৩৫-এ বসানো; এই পরিসর প্রশাসক আগেই /etc/subuid আর /etc/subgid-এ ওই ব্যবহারকারীর নামে বরাদ্দ রেখেছেন, আর ছোট setuid সহায়ক newuidmap/newgidmap মানচিত্রটি লেখে। আমাদের wandbox (ভেতরে UID ৯৯৯) তাই host-এ ১০০০০০ + (৯৯৯ − ১) = ১০০৯৯৮. মানচিত্রের বাইরের কোনো UID-এর মালিকানার ফাইল ভেতর থেকে দেখায় ৬৫৫৩৪ (“nobody”).

User namespace-এর মালিককে সেই namespace-এর ভেতরে পূর্ণ capability দেওয়া হয় — কিন্তু শুধু সেই namespace-এর মালিকানাধীন জিনিসের ওপর: নিজের mount namespace-এ mount, নিজের network namespace-এ interface বানানো। Host-এর ফাইল, host-এর ঘড়ি বা kernel module-এর ওপর এই ক্ষমতা অচল। একেই বলে rootless container: container runtime থেকে শুরু করে সবকিছু একজন সাধারণ ব্যবহারকারী হিসেবে চলে, কোনো root daemon নেই। এই রানার নিজেই তার প্রমাণ:

echo "== the root file system =="
grep ' / ' /proc/mounts | cut -d' ' -f1-3
opts=$(awk '$2 == "/" {print $4}' /proc/mounts)
echo "$opts" | tr ',' '\n' | grep -E '^(lowerdir|upperdir|workdir|userxattr)' | cut -c1-72
echo "lower (read-only) layers: $(echo "$opts" | tr ',' '\n' | grep '^lowerdir=' | tr ':' '\n' | wc -l)"
echo
echo "== a new user namespace: am I root now? =="
unshare --user --map-root-user id || echo "unshare: not permitted here"
unshare -r sh -c 'cat /proc/self/uid_map
  touch /etc/x 2>/dev/null && echo "touch /etc/x: allowed" || echo "touch /etc/x: still denied"' \
  || echo "unshare: not permitted here"
unshare -r --mount sh -c 'mount -t tmpfs none /mnt && grep " /mnt " /proc/self/mounts' \
  || echo "mount in new namespace: not permitted"
echo
echo "== a new PID namespace =="
unshare -r --pid --fork sh -c 'echo "inside: my shell has pid $$"; grep NSpid /proc/self/status' \
  || echo "unshare --pid: not permitted here"

== the root file system ==
overlay / overlay
lowerdir=/home/ubuntu/.local/share/containers/storage/overlay/l/YMR6VSHI
upperdir=/home/ubuntu/.local/share/containers/storage/overlay/31deda0135
workdir=/home/ubuntu/.local/share/containers/storage/overlay/31deda0135a
userxattr
lower (read-only) layers: 3

== a new user namespace: am I root now? ==
uid=0(root) gid=0(root) groups=0(root)
         0        999          1
touch /etc/x: still denied
none /mnt tmpfs rw,relatime,uid=100998,gid=100998,inode64 0 0

== a new PID namespace ==
inside: my shell has pid 1
NSpid:	25	2

৮ · docker run থেকে আপনার প্রসেস — runtime-এর শিকল আর নেটওয়ার্ক

“Docker” আসলে একটি প্রোগ্রাম নয়, কয়েক স্তরের প্রোগ্রাম, আর প্রতিটি স্তর আলাদাভাবে বদলানো যায়:

• docker CLI — শুধু একটি client; আপনার কমান্ডকে REST অনুরোধ বানিয়ে /var/run/docker.sock নামের Unix socket-এ পাঠায়।
• dockerd — root হিসেবে চলা daemon: image, নেটওয়ার্ক, volume সামলায়।
• containerd — container-এর জীবনচক্র (image নামানো, snapshot বানানো, চালানো, থামানো)। ২০১৬-তে Docker থেকে আলাদা হয়, এখন Kubernetes-ও সরাসরি এটি ব্যবহার করে।
• shim (containerd-shim-runc-v2) — প্রতিটি container-এর জন্য একটি ছোট প্রসেস, যে container-এর বাবা হয়ে থাকে, stdio ধরে রাখে আর exit code জমায়; ফলে dockerd বা containerd আবার চালু হলেও container চলতে থাকে।
• runc — OCI runtime: একটি “bundle” (একটি rootfs ফোল্ডার + config.json) নিয়ে namespace, cgroup, mount, capability, seccomp বসিয়ে আসল প্রোগ্রাম execve করে, তারপর নিজে বেরিয়ে যায়।

Podman আর crun — daemon ছাড়া

Podman (Red Hat-এর প্রকল্প, ২০১৮–২০১৯ থেকে জনপ্রিয়) একই OCI image আর প্রায় একই কমান্ড (podman run …) ব্যবহার করে, কিন্তু কোনো স্থায়ী root daemon নেই: podman নিজেই fork-exec করে runtime চালায়, আর container-এর বাবা হয় conmon নামের একটি ছোট পর্যবেক্ষক — shim-এর মতোই। শুরু থেকেই rootless-কে প্রধান ব্যবহার ধরে বানানো। এর ডিফল্ট OCI runtime প্রায়ই crun — C-তে লেখা, runc-এর (Go) চেয়ে ছোট আর দ্রুত চালু হয়। পর্ব ৪৯-এর রানে AppArmor label ছিল crun (unconfined), আর এখানে PID 1 podman-init — অর্থাৎ এই রানার rootless Podman + crun দিয়ে চলে বলে সব চিহ্ন মেলে।

Container-এর নেটওয়ার্ক — সংক্ষেপে

প্রতিটি নতুন network namespace শুরুতে শুধু একটি বন্ধ lo নিয়ে জন্মায়। বাইরের সাথে জুড়তে Docker-এর ডিফল্ট “bridge” নেটওয়ার্ক চারটি যন্ত্র ব্যবহার করে:

• veth জোড়া: একটি ভার্চুয়াল তারের দুই মাথা — এক মাথায় যা ঢোকে, অন্য মাথায় বেরোয়। এক মাথা container-এর namespace-এ eth0 নামে, অন্য মাথা host-এ vethXXXX নামে।
• bridge: host-এর docker0, একটি সফটওয়্যার switch; সব container-এর veth-মাথা এতে জোড়া, তাই তারা একে অপরের সাথে কথা বলতে পারে (সাধারণত 172.17.0.0/16).
• NAT: বাইরে যাওয়া প্যাকেটে উৎস-ঠিকানা host-এর ঠিকানায় বদল (MASQUERADE) — বাসার Wi-Fi router যেমন সব ফোনকে একটি ঠিকানার পেছনে রাখে।
• Port mapping: -p 8080:80 = host-এর ৮০৮০-এ আসা প্যাকেটের গন্তব্য বদলে container-এর ৮০ (DNAT).

Rootless container veth বানিয়ে host-এর bridge-এ জুড়তে পারে না — তাতে host-এর নেটওয়ার্ক বদলানোর ক্ষমতা লাগে। তাই rootless Podman user-mode networking ব্যবহার করে (slirp4netns বা নতুন সংস্করণে pasta): container-এর ভেতরে একটি tap ডিভাইস, আর host-এ একটি সাধারণ প্রসেস প্যাকেটগুলো পড়ে নিজের সাধারণ socket দিয়ে বাইরে পাঠায়। অংশ ৩-এর রানে tap0 mtu=65520 ঠিক এই ব্যবস্থার চিহ্ন। দাম: একটু বেশি CPU আর কিছু সীমাবদ্ধতা; লাভ: কোনো root লাগে না।

৯ · নিরাপত্তা আর Kubernetes — এক kernel, কয়েক স্তরের পাহারা

Container-এর সবচেয়ে বড় সত্য: kernel সবার এক. একটি container-এর প্রসেস host-এর একই kernel-এ syscall করে। তাই kernel-এর একটি গুরুতর বাগ, বা runtime-এর ভুল কনফিগারেশন, একটি container থেকে host-এ বা পাশের container-এ পৌঁছানোর পথ খুলে দিতে পারে — একে বলে container escape. বাস্তব ঘটনাগুলো সাধারণত তিন শ্রেণির, আর প্রতিটির প্রতিরক্ষা জানা:

Docker আর Podman ডিফল্টেই কয়েকটি স্তর বসায়, যার প্রায় সবগুলো এই রানারে আপনি নিজেই দেখেছেন:

• seccomp profile: কয়েক ডজন ঝুঁকিপূর্ণ syscall বন্ধ (পর্ব ৪৯-এ Seccomp: 2, আর এই পর্বের sethostname-এর EPERM সম্ভবত এরই ফল)।
• Capability ছাঁটা: root-এর প্রায় ৪০টি ক্ষমতার মধ্যে ডিফল্টে মোটামুটি এক ডজন রাখা হয়; পর্ব ৪৯-এর রানে bounding set-এ ১১টি ছিল, cap_sys_admin নেই।
• MAC label: Ubuntu-তে AppArmor-এর docker-default profile; Fedora/RHEL-এ SELinux-এর container_t type, আর প্রতিটি container-কে আলাদা MCS category (যেমন s0:c123,c456), যাতে একটি container আরেকটির ফাইল ছুঁতে না পারে।
• শুধু-পড়ার mount: /sys/fs/cgroup শুধু-পড়ার (অংশ ৫-এর mkdir ব্যর্থ), /proc-এর স্পর্শকাতর অংশ ঢাকা।

আপনি এর ওপর আরও কয়েকটি তালা যোগ করতে পারেন — একটি শক্ত-করা docker run:

docker run -d --name web \
  --user 1000:1000 \
  --read-only --tmpfs /tmp \
  --cap-drop ALL --cap-add NET_BIND_SERVICE \
  --security-opt no-new-privileges \
  --memory 256m --pids-limit 100 --cpus 0.5 \
  --init \
  -p 8080:80 myapp:1.4.2
# check what you got:
docker inspect web --format '{{.HostConfig.CapDrop}} {{.HostConfig.ReadonlyRootfs}}'

লাইন ধরে: ভেতরেও root নয় (--user); root file system শুধু-পড়ার, শুধু /tmp লেখা যায়; সব capability বাদ, শুধু নিচু port-এ বসার ক্ষমতা ফেরত; setuid প্রোগ্রাম চালিয়েও নতুন ক্ষমতা নয় (পর্ব ৪৯-এর no_new_privs); মেমরি, প্রসেস-সংখ্যা আর CPU-র cgroup সীমা; আর PID 1-এ tini. সাথে image-এর দিকেও নজর: ছোট base image (কম প্যাকেজ = কম দুর্বলতা), নির্দিষ্ট সংস্করণ বা digest দিয়ে image টানা (latest নয়), আর image স্ক্যান করা।

Kubernetes — এক অনুচ্ছেদে

Kubernetes অনেক যন্ত্রে হাজারো container চালানোর ব্যবস্থাপক, কিন্তু প্রতিটি যন্ত্রে নিচের কাজ এই পর্বের যন্ত্রগুলোই করে। Kubernetes-এর একক pod: এক বা একাধিক container, যারা একটি network namespace (একই IP, একই localhost) আর IPC namespace ভাগ করে; সেই namespace-গুলো ধরে রাখে একটি ক্ষুদ্র “pause” container, আর চাইলে PID namespace-ও ভাগ করা যায়। প্রতিটি node-এর kubelet CRI নামের ইন্টারফেসে containerd বা CRI-O-কে বলে, তারা runc/crun দিয়ে চালায় (Docker-এর মাঝের স্তর বা dockershim Kubernetes 1.24-এ, ২০২২ সালে, সরানো হয়)। Pod-এর resources সরাসরি cgroup-এ নামে: requests.cpu scheduler-কে বলে কোন node-এ জায়গা আছে আর cgroup-এ cpu.weight হয়; limits.cpu: 500m হয় cpu.max = "50000 100000" (পর্ব ২১-এর throttling); limits.memory: 512Mi হয় memory.max = 536870912, আর তা ছাড়ালে container “OOMKilled”, exit code 137 (পর্ব ৩৮)।

১০ · AI-এর যুগে container — দ্রুত উত্তর, সাবধানে যাচাই

Dockerfile, docker-compose.yml আর Kubernetes YAML লেখায় AI সত্যিই সময় বাঁচায়। কিন্তু এই জগতে AI-এর ভুলগুলো চেনা দরকার, কারণ “চলছে” মানেই “ঠিক আছে” নয় — একটি container ঝুঁকিপূর্ণ সেটিং নিয়েও দিব্যি চলে, আর মেমরি-সীমার ভুল ধরা পড়ে শুধু আসল লোডে।

AI-এর container-পরামর্শ প্রয়োগের আগে — চেকলিস্ট

• নিজের runtime (Docker না Podman, সংস্করণ), rootless কি না আর cgroup-এর সংস্করণ AI-কে জানিয়েছি
• প্রস্তাবিত flag-গুলো docker run --help, man podman-run বা অফিসিয়াল ডকুমেন্টেশনে মিলিয়েছি
• --privileged, docker.sock mount, -v /:/host, chmod 777 বা অপ্রয়োজনীয় sudo নেই
• চালানোর পর docker inspect আর ভেতরে /proc/self/status (CapEff, Seccomp), id দিয়ে যা চেয়েছি তা-ই পেয়েছি কি না দেখেছি
• মেমরি আর CPU-সীমা হাতে হিসাব করেছি (Mi বনাম M, millicore) আর আসল লোডে memory.events ও cpu.stat-এর nr_throttled দেখেছি
• docker stop করে মেপে দেখেছি container ১০ সেকেন্ডের আগেই ভদ্রভাবে বন্ধ হয়