Container কেন — image, container, registry আর VM-এর সাথে তুলনা

১ · “আমার কম্পিউটারে তো চলে” — সমস্যাটা কোথায়

একটি কাল্পনিক অনলাইন বাজার অ্যাপ ধরুন। শিলা ল্যাপটপে কোড লিখলেন, পরীক্ষা করলেন, সব ঠিক। রাতে server-এ তোলার পর অ্যাপ চালু হলো না। শিলা বললেন, “আমার কম্পিউটারে তো চলে!” কথাটি সত্য। কিন্তু গ্রাহক তো শিলার ল্যাপটপ থেকে কেনাকাটা করেন না।

কারণ খুঁজলে দেখা যায়, app কখনো একা চলে না। তার পেছনে একটি লম্বা তালিকা থাকে: ভাষার runtime, library, OS-এর প্যাকেজ, environment variable, ফাইলের পথ। এই তালিকার একটি জিনিস আলাদা হলেই আচরণ বদলাতে পারে।

সমস্যাটি আরও বাড়ে যখন একই server-এ দুটি app বসে। একটি app চায় একটি library-র পুরোনো সংস্করণ, আরেকটি চায় নতুন। OS-এ একই জায়গায় দুটি সংস্করণ রাখা কঠিন। একটি ঠিক করলে আরেকটি ভাঙে। এই জট-কেই বলে dependency hell. পর্ব ৮-এ দেখা package dependency এখানে শত্রু হয়ে ওঠে।

আগেও সমাধান ছিল। পর্ব ১৬-এর machine image পুরো server-এর ছবি রাখে। কিন্তু সেটি ভারী, GB-র হিসাবে বড়, আর ল্যাপটপে সহজে চলে না। Python-এর virtualenv শুধু Python library আলাদা করে, OS-এর প্যাকেজ নয়। হাতে লেখা নির্দেশিকা সময়ের সাথে পুরোনো হয়, আর server-গুলো ধীরে ধীরে একে অন্যের থেকে আলাদা হয়ে যায় (drift).

লঞ্চঘাটের শিক্ষা — মানক বাক্স

এই বদলটিই software-এ এসেছে। মানক বাক্সের আগে server-এর প্রশাসককে প্রতিটি app-এর নিয়ম জানতে হতো: Java হলে এই ধাপ, Python হলে ওই ধাপ। Container আসার পর platform-কে শুধু একটি কথা জানতে হয়: “এই image চালান”। ভেতরে Java, Python না Go, platform-এর তা জানার দরকার নেই।

তুলনাটির একটি সীমা মনে রাখুন। লোহার বাক্স একদম আলাদা জিনিস। কিন্তু software container একই kernel-এর ওপর বসে থাকে, যেন সব বাক্সের তলা একটিই। এই একটি পার্থক্য থেকেই এই পর্বের বেশিরভাগ trade-off এসেছে।

২ · Image, container আর registry

এই তিনটি শব্দ গুলিয়ে ফেললে Docker-এর কোনো আলোচনাই পরিষ্কার হবে না। রান্নাঘরের রেসিপি খাতা দিয়ে ভাবুন। Dockerfile হলো রেসিপি। Image হলো সেই রেসিপিতে বানানো, হিমায়িত করা খাবারের প্যাকেট, যা আর বদলায় না। Container হলো প্যাকেট খুলে গরম করে পাতে দেওয়া খাবার: একই প্যাকেট থেকে অনেক পাত বাড়া যায়, আর এক পাতে লবণ দিলে অন্য পাতে তা যায় না। Registry হলো হিমাগার, যেখান থেকে যেকোনো শাখা প্যাকেট নিয়ে যায়।

Image-এর নাম পড়তে শিখুন। docker.io/library/nginx:1.26-alpine নামের চারটি অংশ: registry-র ঠিকানা (docker.io), namespace (library, official image-এর জায়গা), repository (nginx) আর tag (1.26-alpine). Registry-র নাম না লিখলে Docker ধরে নেয় docker.io. Tag না লিখলে ধরে নেয় latest.

docker run চাপলে কী হয়

এই পর্বের সব Docker আউটপুট একটি আসল run থেকে নেওয়া (Docker Engine 29, BuildKit). প্রয়োজনমতো লাইন ছাঁটা হয়েছে, আর ছাঁটা জায়গায় … আছে। ID, digest, আকার আর সময় আপনার মেশিনে আলাদা হবে। নিচের stepper-এ যে image আগে থেকে মেশিনে ছিল না, তা নামিয়ে চালানো হয়েছে।

$ docker run -d --name abcl-cf-pull --hostname demo \
    -p 127.0.0.1:18362:80 nginx:1.26-alpine
Unable to find image 'nginx:1.26-alpine' locally

1.26-alpine: Pulling from library/nginx
5ab072e0bc4f: Pulling fs layer
b8651333baae: Pulling fs layer
… আরও ৬টি layer …

b8651333baae: Download complete
…
0a9a5dfd008f: Pull complete
5e18ef93c435: Pull complete
…

Digest: sha256:1eadbb07820339e8bbfed18c771691970baee292ec4ab2558f1453d26153e22d
Status: Downloaded newer image for nginx:1.26-alpine

writable layer  : নতুন, খালি
hostname        : demo
port            : 127.0.0.1:18362 → container 80
আলাদা দৃশ্য, সীমা : namespace, cgroup

$ (docker run-এর শেষ লাইন: container id)
e3120d3e3aa9a91a7a46b31b156346dfbbfcd8b4cd4a7e902ecb6bf4857387ab
$ docker logs abcl-cf-pull
/docker-entrypoint.sh: Configuration complete; ready for start up
… [notice] 1#1: nginx/1.26.3

$ curl -sI http://127.0.0.1:18362/ | head -2
HTTP/1.1 200 OK
Server: nginx/1.26.3
$ docker ps --filter name=abcl-cf-pull \
    --format 'table {{.Image}}\t{{.Status}}\t{{.Ports}}\t{{.Names}}'
IMAGE               STATUS                  PORTS                     NAMES
nginx:1.26-alpine   Up Less than a second   127.0.0.1:18362->80/tcp   abcl-cf-pull

৩ · Container একটি process — চোখে দেখুন

“Container একটি process” কথাটি মুখস্থ না করে প্রমাণ দেখা যাক। একটি ছোট Alpine image থেকে container চালানো হলো, যা শুধু ১০ মিনিট ঘুমায়। --hostname demo দেওয়া হয়েছে, যাতে ভেতরের hostname আমরাই ঠিক করি।

$ docker run -d --name abcl-cf-demo --hostname demo alpine:3.20 sleep 600
39dec5c5c16e2e40a39381383edc8361d4d10fa82b97a8c5d807071030624bcb

$ docker ps --filter name=abcl-cf-demo
CONTAINER ID   IMAGE         COMMAND       CREATED                  STATUS                  PORTS     NAMES
39dec5c5c16e   alpine:3.20   "sleep 600"   Less than a second ago   Up Less than a second             abcl-cf-demo

$ docker exec abcl-cf-demo hostname
demo

$ docker exec abcl-cf-demo ps -o pid,ppid,user,args
PID   PPID  USER     COMMAND
    1     0 root     sleep 600
   13     0 root     ps -o pid,ppid,user,args

$ docker top abcl-cf-demo -o pid,ppid,args
PID                 PPID                COMMAND
1169                1147                sleep 600

এই আলাদা দৃশ্য দেয় kernel-এর namespace, আর CPU-মেমরির সীমা ও হিসাব রাখে cgroup. এই দুটির ভেতরের কৌশল এই কোর্সে আবার লেখা হবে না। অপারেটিং সিস্টেম কোর্সের Container-এর ভেতর — namespace, cgroup আর Docker পর্বে আটটি namespace, PID 1-এর দায়িত্ব আর cgroup হাতে-কলমে দেখানো আছে। এখানে এক লাইনে মনে রাখুন: namespace ঠিক করে process কী দেখবে, cgroup ঠিক করে কতটা পাবে।

৪ · VM-এর সাথে তুলনা — এক kernel বনাম অনেক kernel

পর্ব ১৫-এ দেখেছেন, virtual machine নকল হার্ডওয়্যারের ওপর পুরো একটি OS চালায়, আর hypervisor তাদের আলাদা রাখে। বাড়ি ভাড়ার ভাষায়: VM মানে আলাদা প্লটে আলাদা বাড়ি, নিজের ভিত, নিজের পানির পাম্প। Container মানে একই ভবনের আলাদা ফ্ল্যাট, ভিত আর পানির মূল লাইন সবার এক।

“সবার kernel এক” কথাটি পরীক্ষা করা যায়। তিনটি ভিন্ন image-এর ভেতরে OS-এর সংস্করণ দেখা হলো, তারপর তিন জায়গার kernel-এর সংস্করণ মিলিয়ে দেখা হলো। Kernel-এর আসল লেখাটি পাতায় দেখানো হচ্ছে না, শুধু তুলনার ফল দেখানো হচ্ছে।

$ for i in alpine:3.20 python:3.12-alpine nginx:1.27-alpine; do
    printf '%s  ' "$i"; docker run --rm --hostname demo "$i" cat /etc/alpine-release
  done
alpine:3.20  3.20.10
python:3.12-alpine  3.24.3
nginx:1.27-alpine  3.21.3

$ a=$(docker run --rm alpine:3.20 uname -r)
$ b=$(docker run --rm nginx:1.27-alpine uname -r)
$ c=$(docker run --rm python:3.12-alpine uname -r)
$ [ "$a" = "$b" ] && [ "$b" = "$c" ] && echo "same kernel (3)"
same kernel (3)

চালু হতে কত সময় লাগে — আসল মাপ

নিচের সংখ্যাগুলো এই পর্ব লেখার সময় একটি development মেশিনে মাপা। প্রতিটি কাজ ১১ বার চালানো হয়েছে, আর সময় ধরা হয়েছে কমান্ড শুরু থেকে কাজ শেষ পর্যন্ত।

একটি সাধারণ VM-এ পুরো OS boot করতে হয়, যা সাধারণত কয়েক সেকেন্ড থেকে এক-দুই মিনিট নেয়, আকার আর provider-ভেদে। অর্থাৎ পার্থক্যটি প্রায়ই এক থেকে দুই ঘরের গুণিতকে। তবে এটি প্রকৃতির নিয়ম নয়: বিশেষভাবে ছাঁটা microVM এক সেকেন্ডের কম সময়েও চালু হতে পারে, যা আমরা পরের অংশে দেখব।

এক host-এ কতগুলো ধরবে — ঘনত্বের হিসাব

প্রতিটি VM-কে নিজের kernel আর OS-এর জন্য বাড়তি মেমরি দিতে হয়। Container-এর বাড়তি খরচ খুব কম। নিচের সিমুলেটরে সংখ্যাগুলো ধরে নেওয়া, কোনো মাপা ফল নয়। VM_EXTRA বা HOST_GIB বদলে আবার চালিয়ে দেখুন।

// How many copies of one app fit on one host? All numbers are ASSUMED.
const HOST_GIB = 64;       // RAM of the physical host
const RESERVED_MIB = 2048; // host OS, hypervisor or container runtime
const VM_EXTRA = 600;      // MiB per VM: guest kernel, init, agents
const CT_EXTRA = 20;       // MiB per container: shim, kernel bookkeeping

const usable = HOST_GIB * 1024 - RESERVED_MIB;
const fit = (app, extra) => Math.floor(usable / (app + extra));
const pct = (app, extra) => (100 * extra / (app + extra)).toFixed(1) + "%";

console.log("usable MiB =", usable);
console.log("app MiB | VMs | containers | ratio | VM overhead | ct overhead");
for (const app of [50, 100, 300, 1000, 4000]) {
  const v = fit(app, VM_EXTRA), c = fit(app, CT_EXTRA);
  console.log(
    String(app).padStart(7), "|", String(v).padStart(3), "|",
    String(c).padStart(10), "|", (c / v).toFixed(2).padStart(5), "|",
    pct(app, VM_EXTRA).padStart(11), "|", pct(app, CT_EXTRA).padStart(11));
}

usable MiB = 63488
app MiB | VMs | containers | ratio | VM overhead | ct overhead
     50 |  97 |        906 |  9.34 |       92.3% |       28.6%
    100 |  90 |        529 |  5.88 |       85.7% |       16.7%
    300 |  70 |        198 |  2.83 |       66.7% |        6.3%
   1000 |  39 |         62 |  1.59 |       37.5% |        2.0%
   4000 |  13 |         15 |  1.15 |       13.0% |        0.5%

৫ · বিচ্ছিন্নতা — ফ্ল্যাটের দেয়াল কতটা শক্ত

“হালকা” হওয়ার দাম কোথায়? দাম সীমানার শক্তিতে। VM-এর guest যা-ই করুক, তাকে নকল হার্ডওয়্যারের সরু দরজা দিয়ে hypervisor-এর সাথে কথা বলতে হয়। Container-এর process সরাসরি host kernel-এ system call করে। Linux kernel-এ কয়েকশো system call আছে, আর প্রতিটি একটি সম্ভাব্য দরজা। Kernel-এ একটি গুরুতর বাগ থাকলে একটি container থেকে পুরো host ঝুঁকিতে পড়তে পারে।

এর মানে এই নয় যে container অনিরাপদ। মানে হলো, কে কার পাশে বসছে তার ওপর সিদ্ধান্ত নির্ভর করে। নিচের তালিকা একটি সাধারণ নিয়ম, পাথরে লেখা নয়:

মাঝের পথও আছে। MicroVM (যেমন Firecracker, Kata Containers) প্রতিটি container বা function-কে খুব ছোট VM-এ চালায়। gVisor container আর host kernel-এর মাঝে একটি user-space kernel বসায়। পাশাপাশি rootless container নিয়ে চালালে ভেতরের root বাইরে সাধারণ ব্যবহারকারী হয়। এসবের ভেতরের ব্যাখ্যা অপারেটিং সিস্টেম কোর্সে আছে, আর Kubernetes-এ প্রয়োগ পর্ব ৪৯-এ আসবে।

৬ · ইতিহাস আর Docker পরিবার

এখানে নামগুলো গুলিয়ে যায়, তাই পরিষ্কার করে নিই। Docker একটি কোম্পানি, একটি টুল-পরিবার আর লোকমুখে container-এর প্রতিশব্দ, তিনটিই।

ভেতরের শিকলটি এমন: docker CLI → dockerd → containerd → container runtime runc → আপনার process. Runc process চালিয়ে দিয়েই সরে যায়। বিস্তারিত অপারেটিং সিস্টেম কোর্সের docker run থেকে আপনার process অংশে আছে। আর OCI মান থাকার ফলে Docker-এ বানানো image Podman বা Kubernetes-এ চলে। বাক্সের মাপ মানক হলে ক্রেনের কোম্পানি বদলানো যায়, ঠিক তেমনি।

Windows আর macOS-এ কেন একটি VM লাগে

একটি Linux container-এর ভেতরের প্রোগ্রাম Linux-এর system call করে, আর namespace ও cgroup চায়। এগুলো Linux kernel-এর জিনিস। Windows আর macOS-এর kernel আলাদা, তারা এই ভাষা বলে না। ফলে উপায় একটিই: পেছনে একটি ছোট Linux VM চালানো, আর container-কে সেই VM-এর kernel-এ বসানো। Docker Desktop এটিই করে। Windows-এ সাধারণত WSL 2-র ভেতরে, macOS-এ Apple-এর virtualization সুবিধা দিয়ে। এজন্য Windows বা Mac-এ docker run --rm alpine:3.20 uname -s চালালেও উত্তর আসে Linux.

৭ · Writable layer — যা লিখবেন, তা ক্ষণস্থায়ী

Image শুধু-পড়ার। তাহলে container-এর ভেতরের process ফাইল লিখলে সেটি যায় কোথায়? প্রতিটি container-এর জন্য image-এর ওপর একটি পাতলা writable layer বসে। লেখা সব সেখানে যায়। আগের একটি ফাইল বদলালে ফাইলটি ওপরে কপি হয় (copy-on-write), নিচের layer অক্ষত থাকে। এই স্তরটি container-এর সাথেই জন্মায়, আর container মুছলে মরে যায়।

1# alpine:3.20 মেশিনে আছে2docker run --name abcl-cf-note \3  --hostname demo alpine:3.20 \4  sh -c 'echo invoice-1001 > /tmp/note.txt'5docker diff abcl-cf-note6docker cp abcl-cf-note:/tmp/note.txt - | tar -xO7docker rm abcl-cf-note8docker run --rm --hostname demo \9  alpine:3.20 cat /tmp/note.txt

--rm দিলে কী হয়, সরাসরি দেখুন। প্রথম container ফাইল লিখে নিজেই পড়ল। সে শেষ হতেই মুছে গেল। দ্বিতীয় container ফাইলটি পেল না।

$ docker run --rm --hostname demo alpine:3.20 \
    sh -c 'echo invoice-1001 > /tmp/note.txt; cat /tmp/note.txt'
invoice-1001

$ docker run --rm --hostname demo alpine:3.20 cat /tmp/note.txt
cat: can't open '/tmp/note.txt': No such file or directory

docker stop আর docker start-এও ফাইল টেকে। এই পরীক্ষাটিও আসল run-এ করা হয়েছে: চলমান container-এ ফাইল লিখে, থামিয়ে, আবার চালিয়ে cat করলে invoice-1001-ই এসেছে। সমস্যা হলো নতুন সংস্করণে যাওয়ার সময়। তখন পুরোনো container মুছে নতুন image থেকে নতুন container বানানো হয়। তাই ডেটা ভেতরে রাখা মানে পরের deploy-তেই হারানো।

একটি image, অনেক container — ভাগ করা স্তর

দুটি আসল পরীক্ষা ছবিটিকে সমর্থন করে। প্রথমে একই image থেকে দুটি container চালিয়ে দুটি আলাদা ফাইল লেখা হলো। তারপর alpine:3.20-র ওপর দুটি ছোট image বানিয়ে তাদের layer-এর তালিকা মেলানো হলো।

$ docker diff abcl-cf-c1
C /tmp
A /tmp/c1.txt
$ docker diff abcl-cf-c2
C /tmp
A /tmp/c2.txt

$ docker ps -s --filter name=abcl-cf-c --format 'table {{.Names}}\t{{.Image}}\t{{.Size}}'
NAMES        IMAGE         SIZE
abcl-cf-c2   alpine:3.20   12.3kB (virtual 8.5MB)
abcl-cf-c1   alpine:3.20   12.3kB (virtual 8.5MB)

$ printf 'FROM alpine:3.20\nRUN echo A > /a.txt\n' | docker build -q -t abcl-cf-a -
sha256:e4e2c8036ec6b9f1eef6ca91b5fc056a5b5666b5259286cdf2a41061e10d6543
$ printf 'FROM alpine:3.20\nRUN echo B > /b.txt\n' | docker build -q -t abcl-cf-b -
sha256:503d0b4624ad9833ea2b9d6c752053e8c94de5d9d311df54287f5ddc3b32cce3

$ for i in alpine:3.20 abcl-cf-a abcl-cf-b; do echo "$i"
    docker image inspect "$i" --format '{{range .RootFS.Layers}}{{println .}}{{end}}' | cut -c1-19
  done
alpine:3.20
sha256:08bc4e534116

abcl-cf-a
sha256:08bc4e534116
sha256:fa3c3934b03a

abcl-cf-b
sha256:08bc4e534116
sha256:0599dbb4b1ff

এবার নিজে হিসাবটি পরীক্ষা করুন। নিচের খেলনা মডেলে দুটি image একই base আর python layer ভাগ করে। আকারগুলো ধরে নেওয়া। read আগে writable layer খোঁজে, তারপর ওপর থেকে নিচের layer-এ যায়।

const layers = {            // sizes in MB (assumed)
  base:   { size: 8,  files: ["/bin/sh", "/etc/app.conf"] },
  python: { size: 50, files: ["/usr/bin/python3"] },
  web:    { size: 5,  files: ["/app/web.py"] },
  worker: { size: 6,  files: ["/app/worker.py"] },
};
const images = { web: ["base", "python", "web"],
                 worker: ["base", "python", "worker"] };
const live = {};            // container -> { image, rw: {path: MB} }
function read(c, path) {    // top-down: writable first, then newest layer
  if (path in live[c].rw) return `${c} ${path}: writable layer`;
  for (const l of [...images[live[c].image]].reverse())
    if (layers[l].files.includes(path)) return `${c} ${path}: read-only "${l}"`;
  return `${c} ${path}: No such file`;
}
function disk() {
  const used = new Set(), cs = Object.values(live); let rw = 0, copies = 0;
  for (const c of cs) {
    images[c.image].forEach((l) => { used.add(l); copies += layers[l].size; });
    rw += Object.values(c.rw).reduce((a, b) => a + b, 0);
  }
  const shared = [...used].reduce((a, l) => a + layers[l].size, 0);
  return `${cs.length} containers: shared ${shared} + writable ${rw} = ` +
    `${shared + rw} MB (full copies: ${copies + rw} MB)`;
}
for (const c of ["c1", "c2", "c3"]) live[c] = { image: "web", rw: {} };
live.c4 = { image: "worker", rw: {} };
live.c1.rw["/tmp/note.txt"] = 1;
live.c2.rw["/etc/app.conf"] = 1;    // copy-up: base layer stays unchanged
for (const [c, p] of [["c1", "/tmp/note.txt"], ["c2", "/tmp/note.txt"],
  ["c2", "/etc/app.conf"], ["c3", "/etc/app.conf"]]) console.log(read(c, p));
console.log(disk());
delete live.c1;  live.c5 = { image: "web", rw: {} };
console.log(read("c5", "/tmp/note.txt"));
console.log(disk());

c1 /tmp/note.txt: writable layer
c2 /tmp/note.txt: No such file
c2 /etc/app.conf: writable layer
c3 /etc/app.conf: read-only "base"
4 containers: shared 69 + writable 2 = 71 MB (full copies: 255 MB)
c5 /tmp/note.txt: No such file
4 containers: shared 69 + writable 1 = 70 MB (full copies: 254 MB)

৮ · এক app, তিন জায়গা — আসল লাভ

এবার সব জোড়া লাগাই। একটি কাল্পনিক shop-api ল্যাপটপ থেকে CI হয়ে server-এ যাচ্ছে। এই stepper-টি একটি নমুনা, এর digest আর ঠিকানাগুলো বানানো। লক্ষ করুন কোনটি বদলায় না, আর কোনটি বদলায়।

image    : shop-api:dev
DB_HOST  : localhost
ফল       : চলছে, কিন্তু এটি শুধু শিলার মেশিনে

image    : shop-api:1.4.2
digest   : sha256:ab12…
DB_HOST  : test-db
ফল       : ১২০টি test পাস

image    : shop-api:1.4.2
digest   : sha256:ab12…
ফল       : test-পাস করা image-টিই জমা হলো

image    : shop-api:1.4.2
digest   : sha256:ab12…
DB_HOST  : prod-db
secret   : secret manager থেকে, image-এ নয়
ফল       : চলছে

নতুন 1.4.3 : ভুল আচরণ, চালু রাখা হলো না
ফিরে গেল   : shop-api:1.4.2
digest     : sha256:ab12…
ডেটা       : container-এর বাইরে, অক্ষত

তাই container “আমার কম্পিউটারে তো চলে” সমস্যার বড় অংশ দূর করে, পুরোটা নয়। ভুল config, ধীর নেটওয়ার্ক বা সীমিত মেমরি প্রোডাকশনে এখনো ঝামেলা বাধাবে। এই ধারণার পুরো রূপ Twelve-Factor নীতিতে আছে, আর “একবার build, সব জায়গায় deploy” আসবে পর্ব ৫৮-এ।

৯ · কখন container নয়

Container জনপ্রিয় বলেই সব জায়গায় ঠিক, এমন নয়। পরের প্রশ্নগুলো নিজেকে করুন। পর্ব ১৯-এ compute বাছাইয়ের পুরো কাঠামো আছে।

১০ · AI-এর যুগে container

AI কয়েক সেকেন্ডে Docker কমান্ড লিখে দেয়, আর সেগুলো প্রায়ই চলেও। কিন্তু “চলে” আর “নিরাপদে চলে” এক কথা নয়। AI আপনার server, খরচ বা ডেটা দেখতে পায় না।

AI সাধারণত যেসব ভুল করে

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

• প্রতিটি flag-এর অর্থ বুঝেছি, আর official docs-এ মিলিয়েছি
• Image-এর নাম, tag আর প্রকাশক যাচাই করেছি, latest নেই
• --privileged, Docker socket বা host নেটওয়ার্ক থাকলে কারণ জানি
• Port কোন interface-এ খুলছে দেখেছি, আর secret লেখায় নেই
• কোন ডেটা হারালে ক্ষতি, সেটি container-এর বাইরে রেখেছি
• Cloud-এ চালালে খরচের সতর্কতা আছে, আর পরীক্ষা ফেলে দেওয়ার মতো পরিবেশে করেছি