DEV Community: Ragib Hasan

ডকারফাইল বিল্ডের ভেতরের জাদু: ইন্টারমিডিয়েট লেয়ার ও ক্যাশিং মেকানিজম (Building Magic Behind Dockerfile)

Ragib Hasan — Sun, 30 Aug 2026 12:14:47 +0000

ডকারে কমান্ড লিখে ইমেজ তৈরি করা সহজ হলেও, docker build ব্যাকগ্রাউন্ডে কীভাবে কাজ করে এবং কেন কিছু বিল্ড চোখের পলকে হয়ে যায় আর কিছু বিল্ডে দীর্ঘ সময় লাগে—তা জানা একজন দক্ষ ইঞ্জিনিয়ার বা DevOps প্রফেশনালের জন্য অত্যন্ত জরুরি।

এই ব্লগে আমরা ডকারফাইল বিল্ডের অভ্যন্তরীণ জীবনচক্র, টেম্পোরারি কন্টেইনার মেকানিজম, ইন্টারমিডিয়েট লেয়ার এবং ডকার ক্যাশিংয়ের আসল কৌশল বিস্তারিতভাবে উন্মোচন করব।

১. ডকার বিল্ডের অভ্যন্তরীণ জীবনচক্র (Internal Execution Lifecycle)

যখন টার্মিনালে docker build -t go_server:1.0.0 . কমান্ড দেওয়া হয়, ডকার প্রতিটি লাইনের জন্য নিচের ৪টি ধাপ চক্রাকারে সম্পন্ন করে:

┌────────────────────────────────────────────────────────────────────────┐
│                        প্রতিটি লাইনের এক্সিকিউশন সাইকেল                │
├────────────────────────────────────────────────────────────────────────┤
│  ধাপ ১: পূর্ববর্তী লেয়ারের ইমেজ থেকে টেম্পোরারি কন্টেইনার তৈরি করা    │
│  ধাপ ২: বর্তমান ইনস্ট্রাকশনটি সেই কন্টেইনারের ভেতর এক্সিকিউট করা       │
│  ধাপ ৩: কন্টেইনারের পরিবর্তনগুলো কমিট করে নতুন ইন্টারমিডিয়েট ইমেজ তৈরি │
│  ধাপ ৪: টেম্পোরারি কন্টেইনারটি স্বয়ংক্রিয়ভাবে মুছে ফেলা (Remove)       │
└────────────────────────────────────────────────────────────────────────┘

২. ডকারফাইলের প্রতিটি লাইনের লেয়ার আর্কিটেকচার

একটি সাধারণ ডকারফাইলের প্রতিটি লাইন কীভাবে একেকটি পৃথক লেয়ার তৈরি করে, তা নিচের ডায়াগ্রামে লক্ষ্য করুন:

Dockerfile Instruction                         Internal State & Layer Creation
───────────────────────────────────────────────────────────────────────────────
FROM ubuntu:24.04           ──▶ [Layer 0 (Base Image)] ──▶ উবুন্টু বেজ ইমেজ পুল/লোড হয়
                                           │
RUN apt update              ──▶ [Layer 1 Image] ───────▶ টেম্পোরারি কন্টেইনার ──▶ apt update ──▶ Commit ──▶ Delete Container
                                           │
RUN apt install -y golang   ──▶ [Layer 2 Image] ───────▶ টেম্পোরারি কন্টেইনার ──▶ Go Install ──▶ Commit ──▶ Delete Container
                                           │
WORKDIR /app                ──▶ [Layer 3 Image] ───────▶ টেম্পোরারি কন্টেইনার ──▶ /app সেট ───▶ Commit ──▶ Delete Container
                                           │
COPY ./server.go ./         ──▶ [Layer 4 Image] ───────▶ টেম্পোরারি কন্টেইনার ──▶ ফাইল কপি ────▶ Commit ──▶ Delete Container
                                           │
CMD ["go", "run", "server.go"] ────────────┴───────────▶ CMD মেটাডাটা বাইন্ড হয়ে ফাইনাল ইমেজ তৈরি

লেয়ারভিত্তিক বিস্তারিত বিশ্লেষণ:

Layer 0 (FROM ubuntu:24.04): ডকার হাব থেকে উবুন্টু ইমেজ পুল করে লোকাল ক্যাশে রাখে এবং বিল্ডের প্রাথমিক রেফারেন্স পয়েন্ট হিসেবে নেয়।
Layer 1 (RUN apt update): Layer 0 থেকে একটি টেম্পোরারি কন্টেইনার বানায়, তার ভেতর apt update কমান্ড চালায়, পরিবর্তিত স্টেটকে কমিট করে Layer 1 ইমেজ তৈরি করে এবং কন্টেইনারটি ডিলিট করে দেয়।
Layer 2 (RUN apt install -y golang): Layer 1 থেকে নতুন কন্টেইনার খুলে Golang ইনস্টল করে, আবার কমিট করে Layer 2 ইমেজ তৈরি করে।
Layer 3 (WORKDIR /app): Layer 2 থেকে কন্টেইনার খুলে /app ডিরেক্টরি সেট ও তৈরি করে Layer 3 ইমেজ তৈরি করে।
Layer 4 (COPY ./server.go ./): হোস্ট মেশিন থেকে কোড এনে কন্টেইনারে রেখে কমিট করে Layer 4 ইমেজ তৈরি করে।
Final Image: সবার শেষে CMD নির্দেশিকাটি Layer 4-এর সাথে বাইন্ড হয়ে আমাদের কাঙ্ক্ষিত ট্যাগযুক্ত ইমেজ (যেমন: go_server:1.0.0) হিসেবে প্রস্তুত হয়।

৩. ডকার লেয়ার ক্যাশিংয়ের ম্যাজিক (Docker Layer Caching)

ডকার বিল্ডের সবচেয়ে বড় শক্তি হলো এর লেয়ার ক্যাশিং (Layer Caching)। প্রতিবার পুরো ডকারফাইল প্রথম থেকে বিল্ড করার পরিবর্তে ডকার অপরিবর্তিত লেয়ারগুলোকে লোকাল ক্যাশ থেকে পুনরায় ব্যবহার করে।

┌────────────────────────────────────────────────────────────────────────┐
│                        ডকারফাইল ক্যাশিং আচরণ                            │
├────────────────────────────────────────────────────────────────────────┤
│  FROM ubuntu:24.04         [কোনো পরিবর্তন নেই] ──▶ CACHED (0.0s)       │
│  RUN apt update            [কোনো পরিবর্তন নেই] ──▶ CACHED (0.0s)       │
│  RUN apt install -y golang [কোনো পরিবর্তন নেই] ──▶ CACHED (0.0s)       │
│                                                                        │
│  ───────▶ [ এখানে পরিবর্তন ঘটলে (Cache Invalidation) ] ◀────────       │
│                                                                        │
│  WORKDIR /habib            [পরিবর্তিত লাইন]    ──▶ NEW BUILD (কন্টেইনার)│
│  COPY ./server.go ./       [পরবর্তী সব লাইন]   ──▶ NEW BUILD (পুনরায়)   │
└────────────────────────────────────────────────────────────────────────┘

ক্যাশ ইনভ্যালিডেশনের মূল নীতি:

ডকার উপর থেকে নিচ পর্যন্ত প্রতিটি লাইন যাচাই করে।
যতক্ষণ পর্যন্ত কোনো পরিবর্তন না পাওয়া যায়, ততক্ষণ সব লেয়ার সরাসরি ক্যাশ থেকে গ্রহণ করে।
যে লাইনে পরিবর্তন শনাক্ত হয়, ঠিক সেই লাইন এবং তার নিচের সমস্ত ইনস্ট্রাকশনের ক্যাশ বাতিল হয়ে যায় এবং সেগুলো নতুন করে সম্পূর্ণ প্রক্রিয়ার মাধ্যমে বিল্ড হয়।

৪. প্রোডাকশন ডকারফাইল অপ্টিমাইজেশন স্ট্র্যাটেজি

প্রোডাকশন এনভায়রনমেন্টে একটি ডকারফাইল শত শত লাইনের হতে পারে। ভুলভাবে ডকারফাইল সাজালে একটি সাধারণ কোড পরিবর্তনের কারণেও ৪০-৫০ মিনিট পর্যন্ত অপ্রয়োজনীয় বিল্ড টাইম লাগতে পারে।

┌────────────────────────────────────────────────────────┐
│               ডকারফাইল সাজানোর মূল নিয়ম                │
├────────────────────────────────────────────────────────┤
│  [উপরে]   অপরিবর্তনশীল ও ভারী লেয়ার (OS, Runtime, SDK) │
│    │                                                   │
│    ▼                                                   │
│  [মাঝখানে] ডিপেন্ডেন্সি তালিকা (package.json / go.mod)  │
│    │                                                   │
│    ▼                                                   │
│  [নিচে]   ঘনঘন পরিবর্তিত সোর্স কোড (server.go / src/)   │
└────────────────────────────────────────────────────────┘

বেস্ট প্র্যাকটিস:

ওএস ও ভারী প্যাকেজ উপরে রাখুন: যেমন RUN apt update বা রানটাইম ইনস্টলেশন একদম উপরে রাখা উচিত, কারণ এগুলোতে ঘনঘন হাত দেওয়ার প্রয়োজন হয় না।
সোর্স কোড নিচে রাখুন: অ্যাপ্লিকেশন কোড (COPY . .) ডেভেলপাররা প্রতিনিয়ত পরিবর্তন করেন। তাই কোড কপি করার লাইনটি ডকারফাইলের নিচের দিকে রাখা উচিত, যেন উপরের ভারী ডিপেন্ডেন্সিগুলোর ক্যাশ অক্ষত থাকে এবং বিল্ড কয়েক সেকেন্ডের মধ্যে শেষ হয়।

সংক্ষেপ চিত্র (Cheat Sheet)

ইন্টারমিডিয়েট ইমেজ: প্রতিটি RUN, COPY, WORKDIR ব্যাকগ্রাউন্ডে একটি করে ইন্টারমিডিয়েট ইমেজ লেয়ার তৈরি করে।
টেম্পোরারি কন্টেইনার: লেয়ারের কমান্ড এক্সিকিউট করতে ডকার ক্ষণস্থায়ী কন্টেইনার তৈরি করে এবং কাজ শেষে তা নিজে থেকেই ডিলিট করে দেয়।
ক্যাশ সেভ: যে লাইনে পরিবর্তন আসে, তার নিচের সব লেয়ার নতুন করে বিল্ড হয়; উপরের লেয়ারগুলো অক্ষত থাকে।

ডকারফাইলে WORKDIR-এর গভীর বিশ্লেষণ (WORKDIR Deep Dive)

Ragib Hasan — Sun, 30 Aug 2026 11:37:00 +0000

ডকারফাইলে (Dockerfile) কনটেইনারের ভেতরের ফাইল ও পাথ ব্যবস্থাপনার জন্য WORKDIR একটি অত্যন্ত গুরুত্বপূর্ণ ইনস্ট্রাকশন। পূর্ববর্তী পর্বে আমরা CMD কমান্ডের কাজ বিস্তারিত দেখেছি। আজকের পর্বে আমরা জানব: WORKDIR ব্যবহার না করলে কী সমস্যা হয়, এটি কীভাবে ডিরেক্টরি পাথ সরল করে এবং কনটেইনারের ভেতরে এক্সিকিউশন কনটেক্সট সেট করে।

১. ডিফল্ট আচরণ: WORKDIR ছাড়া কী ঘটে?

একটি লিনাক্স বেজ ইমেজে (যেমন: ubuntu:24.04) ডিফল্টভাবে সক্রিয় ওয়ার্কিং ডিরেক্টরি থাকে একদম মূল রুট ডিরেক্টরি (/)।

যদি আমরা WORKDIR ব্যবহার না করে সাধারণ RUN mkdir /app কমান্ড দিয়ে একটি ফোল্ডার তৈরি করি, তবে ডকার শুধুমাত্র ফোল্ডারটি তৈরি করে কিন্তু সক্রিয় পাথ পরিবর্তন করে না। ফলে পরবর্তী সকল ইনস্ট্রাকশন রুট ডিরেক্টরিতেই (/) চলতে থাকে।

┌────────────────────────────────────────────────────────────────────────┐
│                        ১. WORKDIR ছাড়া প্রক্রিয়া                       │
│                                                                        │
│  ডিফল্ট পাথ: / (Root)                                                  │
│  ├── RUN mkdir /app       ──▶ ফোল্ডার তৈরি হলো, কিন্তু কারেন্ট পাথ '/' │
│  ├── COPY server.go /app/ ──▶ কপি করতে পুরো পাথ উল্লেখ করতে হয়         │
│  └── CMD ["go", "run", "/app/server.go"] ──▶ এবসলিউট পাথ বাধ্যতামূলক    │
└────────────────────────────────────────────────────────────────────────┘

                                   VS

┌────────────────────────────────────────────────────────────────────────┐
│                        ২. WORKDIR সহ প্রক্রিয়া                        │
│                                                                        │
│  WORKDIR /app                                                          │
│  ├── স্বয়ংক্রিয়ভাবে '/app' ফোল্ডার তৈরি হয় (যদি না থাকে)              │
│  ├── পরবর্তী সকল নির্দেশের কারেন্ট পাথ '/app' এ সেট হয়ে যায়            │
│  ├── COPY server.go ./    ──▶ সরাসরি কারেন্ট পাথে কপি                 │
│  └── CMD ["go", "run", "server.go"] ──▶ কোনো পাথ প্রিফিক্স লাগে না     │
└────────────────────────────────────────────────────────────────────────┘

২. কেস স্টাডি ১: `WORKDIR` ছাড়া ডকারফাইল কনফিগারেশন

যদি আমরা WORKDIR ব্যবহার না করি, তাহলে ডকারফাইলটি দেখতে এমন হয়:

# বেজ ইমেজ ও Golang ইনস্টলেশন
FROM ubuntu:24.04
RUN apt update
RUN apt install -y golang

# ম্যানুয়ালি ফোল্ডার তৈরি
RUN mkdir /app

# রুট কনটেক্সট থেকে /app পাথে কোড কপি
COPY ./server.go /app/server.go

# এবসলিউট পাথ উল্লেখ করে কমান্ড রান
CMD ["go", "run", "/app/server.go"]

এর সীমাবদ্ধতাসমূহ:

পাথের পুনরাবৃত্তি: প্রতিটি ফাইলে /app/ বা সম্পূর্ণ পাথ বারবার টাইপ করতে হয়।
কমান্ড ফেইল হওয়ার ঝুঁকি: CMD বা RUN-এ সরাসরি ফাইলের নাম দিলে তা রুটে (/) খোঁজার চেষ্টা করবে এবং No such file এরর দেবে।
ডিবাগিংয়ের অসুবিধা: docker exec দিয়ে কন্টেইনারে প্রবেশ করলে ডিফল্টভাবে রুটে (/) ল্যান্ড করতে হয়, ফলে বারবার cd /app করতে হয়।

৩. কেস স্টাডি ২: `WORKDIR` দিয়ে আদর্শ ডকারফাইল কনফিগারেশন

ডকারফাইলে WORKDIR /app ইনস্ট্রাকশন দিলে এটি একাধারে ফোল্ডার তৈরি এবং ভেতরে প্রবেশের কাজটি স্বয়ংক্রিয়ভাবে সম্পন্ন করে:

FROM ubuntu:24.04

RUN apt update
RUN apt install -y golang

# ওয়ার্কিং ডিরেক্টরি নির্ধারণ
WORKDIR /app

# কারেন্ট ডিরেক্টরিতে (./) কোড কপি
COPY ./server.go ./server.go

# সরাসরি ফাইলনেম দিয়ে অ্যাপ্লিকেশন চালু
CMD ["go", "run", "server.go"]

৪. `WORKDIR` ব্যবহারের মূল সুবিধাসমূহ

┌─────────────────────────────────────────────────────────────┐
│                    WORKDIR-এর প্রধান সুবিধাসমূহ             │
├─────────────────────────────────────────────────────────────┤
│ 1. Auto-Directory Creation : ফোল্ডার না থাকলে নিজে তৈরি করে │
│ 2. Context Switching       : পরবর্তী কমান্ডের পাথ নির্ধারণ করে │
│ 3. Clean Syntax            : অপ্রয়োজনীয় এবসলিউট পাথ দূর করে │
│ 4. Direct Container Entry  : docker exec সরাসরি পাথে খোলে   │
└─────────────────────────────────────────────────────────────┘

স্বয়ংক্রিয় ডিরেক্টরি তৈরি: যদি নির্ধারিত ডিরেক্টরি আগে থেকে বিদ্যমান না থাকে, ডকার নিজে থেকেই সেটি তৈরি করে নেয় (আলাদা করে RUN mkdir দেওয়ার দরকার নেই)।
সাবসিকুয়েন্ট কমান্ড কনটেক্সট: WORKDIR-এর পরবর্তী সব RUN, COPY, ADD, CMD এবং ENTRYPOINT ওই নির্দিষ্ট ডিরেক্টরির ভেতর কার্যকর হয়।
ক্লিন টার্মিনাল সেশন: docker exec -it <container_id> bash দিয়ে কন্টেইনারে প্রবেশ করলে সরাসরি /app ডিরেক্টরিতে নিয়ে যায়।

৫. হ্যান্ডস-অন প্র্যাকটিস: বিল্ড, রান ও ভেরিফিকেশন

১. ইমেজ বিল্ড করা

docker build -t new_go_server:1.0.3 .

বিল্ড চলাকালীন ডকার স্বয়ংক্রিয়ভাবে /app ডিরেক্টরি সেট করে এবং server.go ফাইলটি কপি করে।

২. কন্টেইনার রান করা

docker run new_go_server:1.0.3

আউটপুট:

Server is running on port 8080

৩. কন্টেইনারে প্রবেশ ও পাথ যাচাই

অন্য একটি টার্মিনাল ওপেন করে কন্টেইনারের অভ্যন্তরীণ অবস্থা পরীক্ষা করা যাক:

# কন্টেইনারের ভেতর প্রবেশ
docker exec -it <CONTAINER_ID> bash

# বর্তমান লোকেশন যাচাই
pwd
# আউটপুট: /app

ls
# আউটপুট: server.go

কার্ল (curl) দিয়ে রিকোয়েস্ট পাঠালে সার্ভার রেসপন্স পাওয়া যাবে:

curl http://localhost:8080
# আউটপুট: Hello World!

ডকারফাইল কমান্ড সারসংক্ষেপ

ইনস্ট্রাকশন	কাজ	ব্যবহারের উদাহরণ
`FROM`	বেজ ইমেজ নির্বাচন করে	`FROM ubuntu:24.04`
`RUN`	বিল্ড টাইমে সিস্টেম কমান্ড চালায়	`RUN apt update`
`WORKDIR`	সক্রিয় ডিরেক্টরি তৈরি ও সেট করে	`WORKDIR /app`
`COPY`	হোস্ট ফাইল কন্টেইনারে কপি করে	`COPY ./server.go ./server.go`
`CMD`	কন্টেইনার শুরুর ডিফল্ট কমান্ড নির্ধারণ করে	`CMD ["go", "run", "server.go"]`

Dockerfile CMD Explained: Build-Time vs Runtime and How CMD Override Works

Ragib Hasan — Sun, 30 Aug 2026 08:52:04 +0000

Dockerfile শেখার সময় FROM, RUN, WORKDIR, এবং COPY নিয়ে কাজ করার পর খুব স্বাভাবিকভাবেই একটি প্রশ্ন আসে:

Container start হলে application automatically কীভাবে run করবে?

আমরা যদি শুধু এই ধরনের Dockerfile লিখি—

FROM ubuntu:24.04

RUN apt update
RUN apt install -y golang

WORKDIR /app

COPY ./server.go ./server.go

তাহলে image তৈরি হবে ঠিকই।

Go-ও install হবে।

server.go-ও image-এর মধ্যে চলে যাবে।

কিন্তু container start করলে কি আমাদের Go server automatically চালু হবে?

না।

আমাদের আবার container-এর ভিতরে ঢুকে manually লিখতে হবে:

go run server.go

এটাই সেই জায়গা যেখানে Dockerfile-এর একটি অত্যন্ত গুরুত্বপূর্ণ instruction সামনে আসে:

`CMD`

CMD আমাদের image-এর default runtime command নির্ধারণ করে।

এই article-এ আমরা দেখব:

কেন container immediately exit করতে পারে
CMD কী
RUN এবং CMD-এর পার্থক্য
build time বনাম runtime
CMD কীভাবে Docker image-এর সঙ্গে থাকে
কীভাবে CMD override করা যায়
এবং একটি real Go server দিয়ে পুরো বিষয়টি hands-onভাবে বোঝা

এই distinction বোঝা Docker-এর fundamental concepts-এর একটি।

1. The Problem: Why Does the Container Exit?

ধরুন আমাদের image তৈরি হয়ে গেছে:

new_go_server:1.0.0

এখন আমরা চালালাম:

docker run new_go_server:1.0.0

কিন্তু কিছুক্ষণ পরেই container বন্ধ হয়ে গেল।

docker ps-এ কিছু নেই।

তখন:

docker ps -a

দিলে দেখা যাবে container-এর status:

Exited

কেন?

কারণ container কোনো GUI application নয় যে শুধু "open" হয়ে থাকবে।

একটি Docker container-এর lifecycle মূলত তার primary process-এর সঙ্গে সম্পর্কিত।

যে process container-এর প্রধান process হিসেবে চলছে সেটি শেষ হয়ে গেলে container-ও শেষ হয়ে যায়। Reference material-এও এই কারণেই default command/process না থাকলে container start হয়ে immediately exit করার বিষয়টি দেখানো হয়েছে।

আমাদের Go application-এর ক্ষেত্রে আমরা চাই:

docker run
     ↓
Container starts
     ↓
Go server starts
     ↓
Server keeps running
     ↓
Container stays alive

কিন্তু Docker-কে তো আমরা বলিইনি যে server কীভাবে start করবে।

এখানেই CMD প্রয়োজন।

2. What Does `CMD` Actually Do?

সহজ ভাষায়:

CMD বলে দেয়—কোনো image থেকে container start হলে default হিসেবে কোন command চালানো হবে।

আমাদের ক্ষেত্রে:

CMD ["go", "run", "server.go"]

এর অর্থ:

Container starts
       ↓
Run:
go run server.go

ফলে:

docker run new_go_server:1.0.1

দিলেই Go server automatically start হবে।

আর manually:

go run server.go

লিখতে হবে না।

এটাই CMD-এর মূল purpose।

3. Our Complete Dockerfile

এখন আগের Dockerfile-এ CMD যোগ করি:

FROM ubuntu:24.04

RUN apt update

RUN apt install -y golang

WORKDIR /app

COPY ./server.go ./server.go

CMD ["go", "run", "server.go"]

এখন আমাদের Dockerfile-এর responsibilities পরিষ্কার:

FROM
 ↓
Base Image

RUN
 ↓
Install Dependencies

WORKDIR
 ↓
Set Working Directory

COPY
 ↓
Bring Application Code

CMD
 ↓
Define Default Runtime Command

এটি Dockerfile-এর একটি very useful mental model।

4. The Most Important Concept: `RUN` vs `CMD`

Dockerfile শেখার সময় সবচেয়ে common confusion:

"RUN আর CMD—দুটোই তো command চালায়। তাহলে difference কী?"

Difference হলো কখন এবং কেন command চালানো হচ্ছে।

`RUN`

RUN execute হয়:

docker build

এর সময়।

`CMD`

CMD execute হয়:

docker run

এর সময়।

অর্থাৎ:

                 docker build
                      │
                      ▼
               ┌─────────────┐
               │     RUN     │
               └─────────────┘
                      │
                      ▼
                   IMAGE
                      │
                      │ docker run
                      ▼
               ┌─────────────┐
               │     CMD     │
               └─────────────┘
                      │
                      ▼
                 CONTAINER

Reference material-এও RUN-কে build phase এবং CMD-কে run phase-এর instruction হিসেবে আলাদা করা হয়েছে।

5. What Happens During `docker build`?

ধরুন আমরা চালালাম:

docker build -t new_go_server:1.0.1 .

Dockerfile:

FROM ubuntu:24.04

RUN apt update
RUN apt install -y golang

WORKDIR /app

COPY ./server.go ./server.go

CMD ["go", "run", "server.go"]

Build-এর সময় Docker:

FROM ubuntu:24.04
        ↓
RUN apt update
        ↓
RUN apt install -y golang
        ↓
WORKDIR /app
        ↓
COPY server.go
        ↓
Create Image

কিন্তু এখানে একটি গুরুত্বপূর্ণ বিষয়:

CMD ["go", "run", "server.go"]

এই command build-এর সময় execute হয় না।

এটি image-এর configuration/metadata-এর অংশ হিসেবে রাখা হয়।

Reference build flow-এও CMD build step হিসেবে execute না হয়ে image-এর সঙ্গে default runtime instruction হিসেবে সংরক্ষিত হওয়ার বিষয়টি দেখানো হয়েছে।

6. Then What Happens During `docker run`?

Build শেষ।

আমাদের image:

new_go_server:1.0.1

এখন:

docker run new_go_server:1.0.1

চালালাম।

Docker image থেকে একটি container তৈরি করবে।

তারপর image-এর মধ্যে থাকা default CMD দেখবে:

CMD ["go", "run", "server.go"]

এবং container-এর ভিতরে সেটি execute করবে।

ফলে:

docker run
     ↓
Create Container
     ↓
Start Container
     ↓
Execute CMD
     ↓
go run server.go
     ↓
Go Server :8080

Output:

Server is running on :8080

এখন container আর সঙ্গে সঙ্গে exit করবে না, কারণ Go server foreground-এ চলমান process হিসেবে container-কে active রাখছে। Reference hands-on test-এও docker run new_go_server:1.0.1-এর পর CMD থেকে Go server automatically start হওয়ার বিষয়টি দেখানো হয়েছে।

7. Understanding the Exec Form

আমরা লিখেছি:

CMD ["go", "run", "server.go"]

এটাকে বলা হয় Exec Form।

এখানে প্রতিটি argument আলাদা string:

"go"
"run"
"server.go"

এবং comma দিয়ে আলাদা করা হয়েছে।

Conceptually এটি:

go run server.go

command-টির equivalent।

Reference material-এ Dockerfile-এর জন্য এই JSON-array/Exec Form syntax-টিকেই ব্যবহার করা হয়েছে।

8. A Critical Mental Model

এখন এই দুইটি statement মনে রাখুন:

`RUN`

Build the image.

`CMD`

Run the application when the container starts.

আরও সহজভাবে:

RUN
→ Image তৈরির সময়

CMD
→ Container চালুর সময়

এই একটি distinction Dockerfile-এর অনেক confusion দূর করে।

9. `CMD` Does NOT Run During Build

এটি beginner-দের একটি common misunderstanding।

ধরুন:

CMD ["go", "run", "server.go"]

লিখেছি।

তারপর:

docker build -t go-server:1.0.1 .

চালালাম।

এখানে Go server start হবে না।

আপনি build output-এ:

Server is running on :8080

দেখবেন না।

কারণ CMD তখন execute হয়নি।

Image তৈরি হয়েছে এবং default command হিসেবে CMD image-এর সঙ্গে সংরক্ষিত হয়েছে।

তারপর:

docker run go-server:1.0.1

দিলে CMD execute হবে।

10. The Magic of Default Commands

এখন সবচেয়ে useful part।

আমাদের image:

new_go_server:1.0.1

এর default command:

CMD ["go", "run", "server.go"]

তাই:

docker run new_go_server:1.0.1

মানে effectively:

Run container
+
Use the image's default command

ফলে server automatically start হয়।

এটাই containerized application-এর expected behaviour:

docker run image
        ↓
Application starts
        ↓
Application keeps running

User-কে container-এর ভিতরে ঢুকে application manually start করতে হয় না।

11. But What If I Want Another Command?

এখানে Docker-এর আরেকটি powerful feature আছে।

ধরুন image-এর default:

CMD ["go", "run", "server.go"]

কিন্তু debugging-এর জন্য আমরা container-এর ভিতরে bash shell চাই।

তাহলে:

docker run -it new_go_server:1.0.1 bash

এখানে কী হলো?

আমরা bash command দিয়েছি।

Docker default CMD ব্যবহার না করে এই command execute করবে।

অর্থাৎ:

Dockerfile CMD
      │
      │ override
      ▼
docker run ... bash
      │
      ▼
bash

Reference material-এ এই exact behaviour দেখানো হয়েছে—docker run <image> <custom_command> ব্যবহার করলে Dockerfile-এর CMD override হয়ে custom command execute হয়।

12. CMD Override: A Practical Example

Default behaviour:

docker run new_go_server:1.0.1

Result:

go run server.go

কিন্তু:

docker run -it new_go_server:1.0.1 bash

Result:

bash

অর্থাৎ CMD override হয়েছে।

এটি বিশেষ করে debugging-এর সময় useful।

ধরুন application start হচ্ছে না।

তখন:

docker run -it new_go_server:1.0.1 bash

দিয়ে container-এর ভিতরে ঢুকে manually inspect করতে পারি:

ls
go version
go run server.go

অর্থাৎ production-এ default command ব্যবহার করা হবে, আর troubleshooting-এর সময় custom command দিয়ে override করা যেতে পারে।

13. CMD Override মানে Image পরিবর্তন নয়

এখানে আরেকটি subtle point আছে।

যখন আমরা:

docker run -it new_go_server:1.0.1 bash

দিই, তখন আমরা Docker image-এর CMD permanently পরিবর্তন করছি না।

শুধু এই particular container-এর জন্য default command-এর পরিবর্তে bash চালাচ্ছি।

পরেরবার:

docker run new_go_server:1.0.1

দিলে আবার:

CMD ["go", "run", "server.go"]

execute হবে।

অর্থাৎ:

Image
│
├── Default CMD → go run server.go
│
├── Container A → default CMD
│
└── Container B → bash override

Image-এর default configuration unchanged থাকে।

14. Hands-On: Build the New Image

এখন complete Dockerfile দিয়ে নতুন image build করি:

docker build -t new_go_server:1.0.1 .

Build-এর সময়:

FROM
RUN
RUN
WORKDIR
COPY

এর instructions process হবে।

কিন্তু:

CMD ["go", "run", "server.go"]

run হবে না।

এটি image-এর default runtime command হিসেবে save হবে।

15. Run Without `-it`

এবার:

docker run new_go_server:1.0.1

কোনো:

-it

নেই।

কোনো:

bash

নেই।

শুধু:

docker run
+
image

এবং তারপরও Go server start হয়ে যাবে।

কারণ Docker image-এর মধ্যে আমরা already define করেছি:

CMD ["go", "run", "server.go"]

Output:

Server is running on :8080

এটাই আমাদের desired behaviour।

16. Verify the Running Container

অন্য terminal খুলে:

docker ps

চালালে running container দেখা যাবে।

তারপর container-এর ভিতরে প্রবেশ করতে:

docker exec -it <CONTAINER_ID> bash

এবং:

curl http://localhost:8080

Expected:

Hello World!

Reference hands-on workflow-এ docker exec দিয়ে running container-এ ঢুকে curl http://localhost:8080 ব্যবহার করে Hello World! response verify করা হয়েছে।

17. `docker run` বনাম `docker exec`

এই example-এ আরেকটি important distinction পাওয়া যায়।

`docker run`

নতুন container তৈরি করে এবং তার default command বা supplied command চালায়।

docker run new_go_server:1.0.1

`docker exec`

Already running container-এর ভিতরে নতুন command চালায়।

docker exec -it <CONTAINER_ID> bash

অর্থাৎ:

docker run
→ Start a new container

docker exec
→ Execute inside an existing container

এই distinction debugging-এর সময় খুব গুরুত্বপূর্ণ।

18. Complete Lifecycle

এখন পুরো lifecycle-টা একসঙ্গে দেখি:

                 Dockerfile
                     │
                     │ docker build
                     ▼
              Docker Image
                     │
              ┌──────┴──────┐
              │             │
              │ docker run  │
              │             │
              ▼             ▼
        Default CMD      Custom Command
              │             │
              ▼             ▼
     go run server.go      bash
              │
              ▼
       Go HTTP Server
              │
              ▼
          :8080

এখানে Dockerfile থেকে image, image থেকে container, এবং container start হওয়ার সময় CMD execution—পুরো chain-টি পরিষ্কার হয়ে যায়।

19. `RUN` vs `CMD`: Final Comparison

বিষয়	`RUN`	`CMD`
কখন execute হয়?	`docker build`	`docker run`
মূল উদ্দেশ্য	Image তৈরি/configure করা	Default runtime command
Image layer তৈরি করে?	হ্যাঁ	Command নিজে build layer তৈরি করে না
Build-এর সময় application চালায়?	হতে পারে	না
Container start হলে automatically execute?	না	হ্যাঁ, যদি override না করা হয়
Override করা যায়?	Runtime command হিসেবে নয়	হ্যাঁ
Example	`RUN apt install -y golang`	`CMD ["go", "run", "server.go"]`

Reference material-এও execution phase, purpose এবং image-এর সঙ্গে persistence-এর ভিত্তিতে RUN ও CMD-কে এভাবেই আলাদা করা হয়েছে।

20. The Three Most Important Commands

এই lesson-এর core workflow মাত্র কয়েকটি command-এ:

Build

docker build -t new_go_server:1.0.1 .

Normal Run

docker run new_go_server:1.0.1

→ CMD automatically execute হবে।

Debug / Override

docker run -it new_go_server:1.0.1 bash

→ CMD override হয়ে bash execute হবে।

এই তিনটি command-এর relationship বুঝলেই CMD অনেক সহজ হয়ে যায়।

21. The Most Important Mental Model

Dockerfile-এর ক্ষেত্রে এই flow-টি মনে রাখুন:

                 BUILD TIME
                     │
                     ▼
        ┌────────────────────────┐
        │ FROM                   │
        │ RUN                    │
        │ WORKDIR                │
        │ COPY                   │
        └────────────────────────┘
                     │
                     ▼
                Docker Image
                     │
                     │ docker run
                     ▼
                 RUNTIME
                     │
                     ▼
                   CMD
                     │
                     ▼
             Application Process

অর্থাৎ:

RUN prepares the image. CMD starts the application.

এই এক লাইনের mental model-টি Dockerfile-এর অনেক confusion দূর করতে পারে।

22. Why This Matters Beyond This Example

আমাদের example একটি simple Go server।

কিন্তু একই principle practically সব ধরনের containerized application-এর ক্ষেত্রে দেখা যায়।

একটি application image তৈরি করার সময়:

Dependencies
Configuration
Application Files

image-এর মধ্যে prepare করা হয়।

আর container start হওয়ার সময়:

Application Process

start করা হয়।

তাই একটি well-designed container-এর ক্ষেত্রে user experience ideally এমন:

docker run <image>

এবং application নিজে থেকেই start করবে।

User-কে container-এর ভিতরে গিয়ে manually setup করতে হবে না।

এটাই containerization-এর বড় সুবিধাগুলোর একটি।

23. One Last Look at Our Go Server

আমাদের server.go:

package main

import (
    "fmt"
    "net/http"
)

func main() {
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintln(w, "Hello World!")
    })

    fmt.Println("Server is running on :8080")
    http.ListenAndServe(":8080", nil)
}

Dockerfile:

FROM ubuntu:24.04

RUN apt update
RUN apt install -y golang

WORKDIR /app

COPY ./server.go ./server.go

CMD ["go", "run", "server.go"]

Build:

docker build -t new_go_server:1.0.1 .

Run:

docker run new_go_server:1.0.1

Debug:

docker run -it new_go_server:1.0.1 bash

Test:

curl http://localhost:8080

Response:

Hello World!

এই ছোট example-এর মধ্যেই Dockerfile-এর একটি complete lifecycle দেখা যাচ্ছে।

Final Takeaway

আজকের lesson-এ মূলত একটি প্রশ্নের উত্তর খুঁজেছি:

How do we make a Docker container automatically start our application?

উত্তর:

CMD ["go", "run", "server.go"]

কিন্তু শুধু syntax মনে রাখলে হবে না।

বোঝা দরকার কখন এটি execute হয়।

`docker build`

FROM
RUN
WORKDIR
COPY

এগুলো image তৈরি করে।

CMD তখন execute হয় না।

তারপর:

`docker run`

Container Created
      ↓
CMD Executed
      ↓
Go Server Started
      ↓
Container Keeps Running

আর যদি debugging করতে চাই:

docker run -it new_go_server:1.0.1 bash

তাহলে default CMD override হয়ে bash চালু হবে।

শেষ পর্যন্ত Docker-এর এই simple mental model-টি মনে রাখুন:

Build the environment with RUN.
Define the default application process with CMD.
Start it with docker run.
Override it when you need to debug.

একটি ছোট CMD instruction আসলে Docker image-কে একটি static filesystem থেকে একটি runnable application environment-এ পরিণত করার গুরুত্বপূর্ণ অংশ।

আর Docker শেখার পরবর্তী ধাপে এই concept থেকেই naturally আসে ENTRYPOINT, CMD বনাম ENTRYPOINT, environment variables, ports, volumes এবং production-grade container design।

Understand the lifecycle, not just the command. 🐳

Dockerfile CMD Explained: Build-Time vs Runtime and How CMD Override Works

Ragib Hasan — Sun, 30 Aug 2026 08:37:10 +0000

Container start হলে application automatically কীভাবে run করবে?

আমরা যদি শুধু এই ধরনের Dockerfile লিখি—

FROM ubuntu:24.04

RUN apt update
RUN apt install -y golang

WORKDIR /app

COPY ./server.go ./server.go

তাহলে image তৈরি হবে ঠিকই।

Go-ও install হবে।

server.go-ও image-এর মধ্যে চলে যাবে।

কিন্তু container start করলে কি আমাদের Go server automatically চালু হবে?

না।

আমাদের আবার container-এর ভিতরে ঢুকে manually লিখতে হবে:

go run server.go

এটাই সেই জায়গা যেখানে Dockerfile-এর একটি অত্যন্ত গুরুত্বপূর্ণ instruction সামনে আসে:

`CMD`

CMD আমাদের image-এর default runtime command নির্ধারণ করে।

এই article-এ আমরা দেখব:

কেন container immediately exit করতে পারে
CMD কী
RUN এবং CMD-এর পার্থক্য
build time বনাম runtime
CMD কীভাবে Docker image-এর সঙ্গে থাকে
কীভাবে CMD override করা যায়
এবং একটি real Go server দিয়ে পুরো বিষয়টি hands-onভাবে বোঝা

এই distinction বোঝা Docker-এর fundamental concepts-এর একটি।

1. The Problem: Why Does the Container Exit?

ধরুন আমাদের image তৈরি হয়ে গেছে:

new_go_server:1.0.0

এখন আমরা চালালাম:

docker run new_go_server:1.0.0

কিন্তু কিছুক্ষণ পরেই container বন্ধ হয়ে গেল।

docker ps-এ কিছু নেই।

তখন:

docker ps -a

দিলে দেখা যাবে container-এর status:

Exited

কেন?

কারণ container কোনো GUI application নয় যে শুধু "open" হয়ে থাকবে।

একটি Docker container-এর lifecycle মূলত তার primary process-এর সঙ্গে সম্পর্কিত।

আমাদের Go application-এর ক্ষেত্রে আমরা চাই:

docker run
     ↓
Container starts
     ↓
Go server starts
     ↓
Server keeps running
     ↓
Container stays alive

কিন্তু Docker-কে তো আমরা বলিইনি যে server কীভাবে start করবে।

এখানেই CMD প্রয়োজন।

2. What Does `CMD` Actually Do?

সহজ ভাষায়:

CMD বলে দেয়—কোনো image থেকে container start হলে default হিসেবে কোন command চালানো হবে।

আমাদের ক্ষেত্রে:

CMD ["go", "run", "server.go"]

এর অর্থ:

Container starts
       ↓
Run:
go run server.go

ফলে:

docker run new_go_server:1.0.1

দিলেই Go server automatically start হবে।

আর manually:

go run server.go

লিখতে হবে না।

এটাই CMD-এর মূল purpose।

3. Our Complete Dockerfile

এখন আগের Dockerfile-এ CMD যোগ করি:

FROM ubuntu:24.04

RUN apt update

RUN apt install -y golang

WORKDIR /app

COPY ./server.go ./server.go

CMD ["go", "run", "server.go"]

এখন আমাদের Dockerfile-এর responsibilities পরিষ্কার:

FROM
 ↓
Base Image

RUN
 ↓
Install Dependencies

WORKDIR
 ↓
Set Working Directory

COPY
 ↓
Bring Application Code

CMD
 ↓
Define Default Runtime Command

এটি Dockerfile-এর একটি very useful mental model।

4. The Most Important Concept: `RUN` vs `CMD`

Dockerfile শেখার সময় সবচেয়ে common confusion:

"RUN আর CMD—দুটোই তো command চালায়। তাহলে difference কী?"

Difference হলো কখন এবং কেন command চালানো হচ্ছে।

`RUN`

RUN execute হয়:

docker build

এর সময়।

`CMD`

CMD execute হয়:

docker run

এর সময়।

অর্থাৎ:

                 docker build
                      │
                      ▼
               ┌─────────────┐
               │     RUN     │
               └─────────────┘
                      │
                      ▼
                   IMAGE
                      │
                      │ docker run
                      ▼
               ┌─────────────┐
               │     CMD     │
               └─────────────┘
                      │
                      ▼
                 CONTAINER

Reference material-এও RUN-কে build phase এবং CMD-কে run phase-এর instruction হিসেবে আলাদা করা হয়েছে।

5. What Happens During `docker build`?

ধরুন আমরা চালালাম:

docker build -t new_go_server:1.0.1 .

Dockerfile:

FROM ubuntu:24.04

RUN apt update
RUN apt install -y golang

WORKDIR /app

COPY ./server.go ./server.go

CMD ["go", "run", "server.go"]

Build-এর সময় Docker:

FROM ubuntu:24.04
        ↓
RUN apt update
        ↓
RUN apt install -y golang
        ↓
WORKDIR /app
        ↓
COPY server.go
        ↓
Create Image

কিন্তু এখানে একটি গুরুত্বপূর্ণ বিষয়:

CMD ["go", "run", "server.go"]

এই command build-এর সময় execute হয় না।

এটি image-এর configuration/metadata-এর অংশ হিসেবে রাখা হয়।

6. Then What Happens During `docker run`?

Build শেষ।

আমাদের image:

new_go_server:1.0.1

এখন:

docker run new_go_server:1.0.1

চালালাম।

Docker image থেকে একটি container তৈরি করবে।

তারপর image-এর মধ্যে থাকা default CMD দেখবে:

CMD ["go", "run", "server.go"]

এবং container-এর ভিতরে সেটি execute করবে।

ফলে:

docker run
     ↓
Create Container
     ↓
Start Container
     ↓
Execute CMD
     ↓
go run server.go
     ↓
Go Server :8080

Output:

Server is running on :8080

7. Understanding the Exec Form

আমরা লিখেছি:

CMD ["go", "run", "server.go"]

এটাকে বলা হয় Exec Form।

এখানে প্রতিটি argument আলাদা string:

"go"
"run"
"server.go"

এবং comma দিয়ে আলাদা করা হয়েছে।

Conceptually এটি:

go run server.go

command-টির equivalent।

Reference material-এ Dockerfile-এর জন্য এই JSON-array/Exec Form syntax-টিকেই ব্যবহার করা হয়েছে।

8. A Critical Mental Model

এখন এই দুইটি statement মনে রাখুন:

`RUN`

Build the image.

`CMD`

Run the application when the container starts.

আরও সহজভাবে:

RUN
→ Image তৈরির সময়

CMD
→ Container চালুর সময়

এই একটি distinction Dockerfile-এর অনেক confusion দূর করে।

9. `CMD` Does NOT Run During Build

এটি beginner-দের একটি common misunderstanding।

ধরুন:

CMD ["go", "run", "server.go"]

লিখেছি।

তারপর:

docker build -t go-server:1.0.1 .

চালালাম।

এখানে Go server start হবে না।

আপনি build output-এ:

Server is running on :8080

দেখবেন না।

কারণ CMD তখন execute হয়নি।

Image তৈরি হয়েছে এবং default command হিসেবে CMD image-এর সঙ্গে সংরক্ষিত হয়েছে।

তারপর:

docker run go-server:1.0.1

দিলে CMD execute হবে।

10. The Magic of Default Commands

এখন সবচেয়ে useful part।

আমাদের image:

new_go_server:1.0.1

এর default command:

CMD ["go", "run", "server.go"]

তাই:

docker run new_go_server:1.0.1

মানে effectively:

Run container
+
Use the image's default command

ফলে server automatically start হয়।

এটাই containerized application-এর expected behaviour:

docker run image
        ↓
Application starts
        ↓
Application keeps running

User-কে container-এর ভিতরে ঢুকে application manually start করতে হয় না।

11. But What If I Want Another Command?

এখানে Docker-এর আরেকটি powerful feature আছে।

ধরুন image-এর default:

CMD ["go", "run", "server.go"]

কিন্তু debugging-এর জন্য আমরা container-এর ভিতরে bash shell চাই।

তাহলে:

docker run -it new_go_server:1.0.1 bash

এখানে কী হলো?

আমরা bash command দিয়েছি।

Docker default CMD ব্যবহার না করে এই command execute করবে।

অর্থাৎ:

Dockerfile CMD
      │
      │ override
      ▼
docker run ... bash
      │
      ▼
bash

12. CMD Override: A Practical Example

Default behaviour:

docker run new_go_server:1.0.1

Result:

go run server.go

কিন্তু:

docker run -it new_go_server:1.0.1 bash

Result:

bash

অর্থাৎ CMD override হয়েছে।

এটি বিশেষ করে debugging-এর সময় useful।

ধরুন application start হচ্ছে না।

তখন:

docker run -it new_go_server:1.0.1 bash

দিয়ে container-এর ভিতরে ঢুকে manually inspect করতে পারি:

ls
go version
go run server.go

13. CMD Override মানে Image পরিবর্তন নয়

এখানে আরেকটি subtle point আছে।

যখন আমরা:

docker run -it new_go_server:1.0.1 bash

দিই, তখন আমরা Docker image-এর CMD permanently পরিবর্তন করছি না।

শুধু এই particular container-এর জন্য default command-এর পরিবর্তে bash চালাচ্ছি।

পরেরবার:

docker run new_go_server:1.0.1

দিলে আবার:

CMD ["go", "run", "server.go"]

execute হবে।

অর্থাৎ:

Image
│
├── Default CMD → go run server.go
│
├── Container A → default CMD
│
└── Container B → bash override

Image-এর default configuration unchanged থাকে।

14. Hands-On: Build the New Image

এখন complete Dockerfile দিয়ে নতুন image build করি:

docker build -t new_go_server:1.0.1 .

Build-এর সময়:

FROM
RUN
RUN
WORKDIR
COPY

এর instructions process হবে।

কিন্তু:

CMD ["go", "run", "server.go"]

run হবে না।

এটি image-এর default runtime command হিসেবে save হবে।

15. Run Without `-it`

এবার:

docker run new_go_server:1.0.1

কোনো:

-it

নেই।

কোনো:

bash

নেই।

শুধু:

docker run
+
image

এবং তারপরও Go server start হয়ে যাবে।

কারণ Docker image-এর মধ্যে আমরা already define করেছি:

CMD ["go", "run", "server.go"]

Output:

Server is running on :8080

এটাই আমাদের desired behaviour।

16. Verify the Running Container

অন্য terminal খুলে:

docker ps

চালালে running container দেখা যাবে।

তারপর container-এর ভিতরে প্রবেশ করতে:

docker exec -it <CONTAINER_ID> bash

এবং:

curl http://localhost:8080

Expected:

Hello World!

17. `docker run` বনাম `docker exec`

এই example-এ আরেকটি important distinction পাওয়া যায়।

`docker run`

নতুন container তৈরি করে এবং তার default command বা supplied command চালায়।

docker run new_go_server:1.0.1

`docker exec`

Already running container-এর ভিতরে নতুন command চালায়।

docker exec -it <CONTAINER_ID> bash

অর্থাৎ:

docker run
→ Start a new container

docker exec
→ Execute inside an existing container

এই distinction debugging-এর সময় খুব গুরুত্বপূর্ণ।

18. Complete Lifecycle

এখন পুরো lifecycle-টা একসঙ্গে দেখি:

                 Dockerfile
                     │
                     │ docker build
                     ▼
              Docker Image
                     │
              ┌──────┴──────┐
              │             │
              │ docker run  │
              │             │
              ▼             ▼
        Default CMD      Custom Command
              │             │
              ▼             ▼
     go run server.go      bash
              │
              ▼
       Go HTTP Server
              │
              ▼
          :8080

19. `RUN` vs `CMD`: Final Comparison

বিষয়	`RUN`	`CMD`
কখন execute হয়?	`docker build`	`docker run`
মূল উদ্দেশ্য	Image তৈরি/configure করা	Default runtime command
Image layer তৈরি করে?	হ্যাঁ	Command নিজে build layer তৈরি করে না
Build-এর সময় application চালায়?	হতে পারে	না
Container start হলে automatically execute?	না	হ্যাঁ, যদি override না করা হয়
Override করা যায়?	Runtime command হিসেবে নয়	হ্যাঁ
Example	`RUN apt install -y golang`	`CMD ["go", "run", "server.go"]`

20. The Three Most Important Commands

এই lesson-এর core workflow মাত্র কয়েকটি command-এ:

Build

docker build -t new_go_server:1.0.1 .

Normal Run

docker run new_go_server:1.0.1

→ CMD automatically execute হবে।

Debug / Override

docker run -it new_go_server:1.0.1 bash

→ CMD override হয়ে bash execute হবে।

এই তিনটি command-এর relationship বুঝলেই CMD অনেক সহজ হয়ে যায়।

21. The Most Important Mental Model

Dockerfile-এর ক্ষেত্রে এই flow-টি মনে রাখুন:

                 BUILD TIME
                     │
                     ▼
        ┌────────────────────────┐
        │ FROM                   │
        │ RUN                    │
        │ WORKDIR                │
        │ COPY                   │
        └────────────────────────┘
                     │
                     ▼
                Docker Image
                     │
                     │ docker run
                     ▼
                 RUNTIME
                     │
                     ▼
                   CMD
                     │
                     ▼
             Application Process

অর্থাৎ:

RUN prepares the image. CMD starts the application.

এই এক লাইনের mental model-টি Dockerfile-এর অনেক confusion দূর করতে পারে।

22. Why This Matters Beyond This Example

আমাদের example একটি simple Go server।

কিন্তু একই principle practically সব ধরনের containerized application-এর ক্ষেত্রে দেখা যায়।

একটি application image তৈরি করার সময়:

Dependencies
Configuration
Application Files

image-এর মধ্যে prepare করা হয়।

আর container start হওয়ার সময়:

Application Process

start করা হয়।

তাই একটি well-designed container-এর ক্ষেত্রে user experience ideally এমন:

docker run <image>

এবং application নিজে থেকেই start করবে।

User-কে container-এর ভিতরে গিয়ে manually setup করতে হবে না।

এটাই containerization-এর বড় সুবিধাগুলোর একটি।

23. One Last Look at Our Go Server

আমাদের server.go:

package main

import (
    "fmt"
    "net/http"
)

func main() {
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintln(w, "Hello World!")
    })

    fmt.Println("Server is running on :8080")
    http.ListenAndServe(":8080", nil)
}

Dockerfile:

FROM ubuntu:24.04

RUN apt update
RUN apt install -y golang

WORKDIR /app

COPY ./server.go ./server.go

CMD ["go", "run", "server.go"]

Build:

docker build -t new_go_server:1.0.1 .

Run:

docker run new_go_server:1.0.1

Debug:

docker run -it new_go_server:1.0.1 bash

Test:

curl http://localhost:8080

Response:

Hello World!

এই ছোট example-এর মধ্যেই Dockerfile-এর একটি complete lifecycle দেখা যাচ্ছে।

Final Takeaway

আজকের lesson-এ মূলত একটি প্রশ্নের উত্তর খুঁজেছি:

How do we make a Docker container automatically start our application?

উত্তর:

CMD ["go", "run", "server.go"]

কিন্তু শুধু syntax মনে রাখলে হবে না।

বোঝা দরকার কখন এটি execute হয়।

`docker build`

FROM
RUN
WORKDIR
COPY

এগুলো image তৈরি করে।

CMD তখন execute হয় না।

তারপর:

`docker run`

Container Created
      ↓
CMD Executed
      ↓
Go Server Started
      ↓
Container Keeps Running

আর যদি debugging করতে চাই:

docker run -it new_go_server:1.0.1 bash

তাহলে default CMD override হয়ে bash চালু হবে।

শেষ পর্যন্ত Docker-এর এই simple mental model-টি মনে রাখুন:

Build the environment with RUN.
Define the default application process with CMD.
Start it with docker run.
Override it when you need to debug.

Understand the lifecycle, not just the command. 🐳

From Manual Containers to Dockerfile: Containerizing a Go Server the Right Way

Ragib Hasan — Sun, 30 Aug 2026 08:13:54 +0000

Docker শেখার শুরুতে docker run করা খুব সহজ।

একটি Ubuntu image নিন, container চালান, ভিতরে ঢুকুন—তারপর application চালিয়ে দিন।

কিন্তু software engineering-এর আসল প্রশ্নটা একটু ভিন্ন:

Can someone else reproduce exactly what you just built?

যদি উত্তর হয় “না, আমাকে একে একে সব command বলে দিতে হবে”—তাহলে আমাদের workflow-এ এখনও একটি সমস্যা আছে।

এই article-এ আমরা একটি ছোট Go HTTP server-কে Docker container-এর ভিতরে চালানোর মাধ্যমে সেই সমস্যাটি বুঝব।

প্রথমে সবকিছু manually করব।

তারপর docker commit দিয়ে সেই environment-এর একটি image বানাব।

এরপর দেখব কেন এই approach দীর্ঘমেয়াদে inconvenient।

সবশেষে একই process-কে একটি Dockerfile-এ লিখে পুরো setup-টিকে reproducible এবং automated করে তুলব।

এটাই মূল transition:

Manual Configuration
        ↓
docker commit
        ↓
Problem
        ↓
Dockerfile
        ↓
Reproducible Image
        ↓
Containerized Application

1. The Application We Want to Containerize

আমাদের application একটি খুব simple Go HTTP server।

server.go:

package main

import (
    "fmt"
    "net/http"
)

func main() {
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintln(w, "Hello World!")
    })

    fmt.Println("Server is running on :8080")
    http.ListenAndServe(":8080", nil)
}

Application-এর কাজ খুব straightforward:

HTTP server start করবে
8080 port-এ listen করবে
/ endpoint-এ request এলে Hello World! response দেবে

অর্থাৎ আমাদের লক্ষ্য:

Browser / Client
       │
       │ HTTP Request
       ▼
Go Server
       │
       ▼
:8080
       │
       ▼
"Hello World!"

এখন প্রশ্ন হলো—এই application-টিকে Docker container-এর মধ্যে কীভাবে চালাব?

2. First Attempt: Do Everything Manually

শুরু করি Ubuntu দিয়ে।

প্রথমে image pull:

docker pull ubuntu:24.04

তারপর interactive container:

docker run -it ubuntu:24.04 bash

এখন আমরা Ubuntu container-এর ভিতরে।

Reference workflow-এও প্রথমে Ubuntu image pull করে interactive container চালানো হয়েছে।

এখন আমাদের container একটি basic Ubuntu environment।

কিন্তু এখানে Go নেই।

তাই পরবর্তী কাজ—Go install করা।

3. Install Go Inside the Container

প্রথমে package index update:

apt update

তারপর:

apt install -y golang

Installation verify করতে:

go version

যদি version output পাওয়া যায়, তাহলে Go environment ready।

Reference workflow-এও একইভাবে apt update, apt install -y golang, এবং go version ব্যবহার করা হয়েছে।

এখন আমাদের container-এর ভিতরে Go আছে।

কিন্তু application কোথায়?

4. Create an Application Directory

Application-এর জন্য একটি dedicated directory তৈরি করি:

mkdir /app
cd /app

এখন আমাদের container structure conceptually এমন:

/
├── bin/
├── etc/
├── usr/
├── var/
└── app/

আমরা application-এর জন্য /app ব্যবহার করছি।

Reference workflow-এও application code রাখার জন্য /app directory তৈরি করা হয়েছে।

5. Move `server.go` into the Container

এখন একটি গুরুত্বপূর্ণ বিষয় আছে।

আমাদের server.go host machine-এ আছে।

কিন্তু Go runtime চলছে container-এর ভিতরে।

তাই host থেকে container-এ file নিতে হবে।

Docker-এর জন্য এই কাজের একটি command হলো:

docker cp server.go <CONTAINER_ID>:/app/server.go

Conceptually:

HOST MACHINE
│
│  server.go
│
│ docker cp
▼
DOCKER CONTAINER
│
└── /app/server.go

docker cp host এবং container-এর মধ্যে file copy করার জন্য ব্যবহৃত হয়।

এখন container-এর ভিতরে:

cd /app
ls

আমরা দেখতে পাব:

server.go

6. Run the Go Server

এখন application চালানো যাক:

go run server.go

Output:

Server is running on :8080

আমাদের Go server এখন container-এর ভিতরে চলছে।

Application test করার জন্য container-এর ভিতর থেকেই:

curl http://localhost:8080

করলে response:

Hello World!

Reference workflow-এও go run server.go দিয়ে server চালিয়ে curl http://localhost:8080 দিয়ে Hello World! response verify করা হয়েছে।

আমরা সফল।

কিন্তু আমাদের journey এখানেই শেষ নয়।

বরং এখান থেকেই আসল problem শুরু।

7. We Built It. But Can We Rebuild It?

একবার চিন্তা করুন, আমরা কী কী করেছি:

1. Pull Ubuntu
2. Run container
3. Update packages
4. Install Go
5. Create /app
6. Copy server.go
7. Run the server
8. Test the application

এখন যদি container delete হয়ে যায়?

আমাদের আবার সব করতে হবে।

যদি server.go পরিবর্তন হয়?

আবার setup করতে হবে।

যদি আরেকজন developer একই environment চায়?

তাকে আমাদের সব command দিতে হবে।

এখানে একটা fundamental engineering problem আছে:

The environment exists, but the process used to create the environment is not properly encoded.

এই problem থেকেই Dockerfile-এর প্রয়োজনীয়তা বোঝা যায়।

8. `docker commit`: Take a Snapshot

আমরা চাই আমাদের configured container-এর বর্তমান state preserve করতে।

এখানে ব্যবহার করা যায়:

docker commit <CONTAINER_ID> go_server

এটি container-এর current filesystem state থেকে একটি নতুন image তৈরি করে।

তারপর:

docker run -it go_server bash

চালালে নতুন container-এর মধ্যে আগের setup পাওয়া যাবে।

অর্থাৎ:

Configured Container
        │
        │ docker commit
        ▼
    go_server
      Image
        │
        │ docker run
        ▼
New Container

docker commit দিয়ে configured container থেকে image তৈরি করার এই workflow-টিই reference material-এ দেখানো হয়েছে।

এটি useful।

কিন্তু production engineering-এর জন্য এখানেও একটি বড় প্রশ্ন রয়ে যায়।

9. The Problem with `docker commit`

ধরুন server.go-তে আজ একটি পরিবর্তন এসেছে।

আমাদের manual workflow আবার:

Ubuntu
  ↓
Install Go
  ↓
Create /app
  ↓
Copy new server.go
  ↓
Run application
  ↓
docker commit

আবার একই কাজ।

এটি repetitive।

আরও গুরুত্বপূর্ণ হলো, image দেখে সহজে বোঝা যায় না কীভাবে environment-টি তৈরি হয়েছিল।

কোন base image?

কোন package?

কোন directory?

কোন source file?

কোন setup command?

Manual process-এর এই traceability এবং repeatability limitation-ই Dockerfile-এর দিকে যাওয়ার মূল কারণ।

10. Enter the Dockerfile

এবার আমরা একটি গুরুত্বপূর্ণ engineering principle ব্যবহার করব:

If you have to repeat a process, turn the process into code.

আমরা এতক্ষণ যে কাজগুলো terminal-এ manually করেছি, সেগুলো এখন একটি Dockerfile-এ লিখব।

আমাদের project structure:

docker-learning/
│
├── Dockerfile
└── server.go

এখন Dockerfile:

FROM ubuntu:24.04

RUN apt update

RUN apt install -y golang

WORKDIR /app

COPY ./server.go ./server.go

এটাই আমাদের manual workflow-এর declarative version।

11. Understanding the Dockerfile

Dockerfile-এর প্রতিটি instruction-এর একটি নির্দিষ্ট responsibility আছে।

`FROM`

FROM ubuntu:24.04

এটি আমাদের base image নির্ধারণ করে।

অর্থাৎ:

Start with Ubuntu 24.04.

Docker image তৈরির foundation এখান থেকেই শুরু হচ্ছে।

`RUN`

RUN apt update

Image build-এর সময় package index update হবে।

তারপর:

RUN apt install -y golang

Build-এর সময় Go install হবে।

Manual workflow-এ আমরা এগুলো নিজের হাতে করেছিলাম।

Dockerfile-এ আমরা instructions লিখে দিলাম।

Reference material-এ RUN instructions-এর মাধ্যমে package update এবং Golang installation automate করার একই workflow দেখানো হয়েছে।

12. `WORKDIR`: A Better Way to Handle `/app`

Manual approach-এ আমাদের লিখতে হয়েছিল:

mkdir /app
cd /app

Dockerfile-এ:

WORKDIR /app

এই একটি instruction /app-কে working directory হিসেবে set করে।

এর ফলে পরবর্তী instructions-এর relative context /app হয়ে যায়।

Reference material-এও উল্লেখ করা হয়েছে যে WORKDIR /app ব্যবহার করলে আলাদা করে mkdir /app এবং cd /app করার প্রয়োজন হয় না।

এটি Dockerfile-কে অনেক cleaner করে।

13. `COPY`: Bring the Application into the Image

এখন:

COPY ./server.go ./server.go

এর মাধ্যমে build context-এর server.go image-এর working directory-তে copy হবে।

আমাদের WORKDIR যেহেতু:

WORKDIR /app

তাই application file পাওয়া যাবে:

/app/server.go

অর্থাৎ:

Host
│
└── server.go
       │
       │ COPY
       ▼
Container Image
│
└── /app/server.go

Reference workflow-এও COPY দিয়ে host-এর server.go application directory-তে অন্তর্ভুক্ত করা হয়েছে।

14. Manual Process vs Dockerfile

এখন সবচেয়ে গুরুত্বপূর্ণ comparison:

Manual Process	Dockerfile
Pull Ubuntu	`FROM ubuntu:24.04`
`apt update`	`RUN apt update`
Install Go	`RUN apt install -y golang`
`mkdir /app`	`WORKDIR /app`
`docker cp server.go`	`COPY ./server.go ./server.go`
`docker commit`	`docker build`

খেয়াল করুন কী হয়েছে।

আমরা শুধু কয়েকটি command replace করিনি।

আমরা পুরো environment creation process-টাকে code-এ পরিণত করেছি।

15. Build the Image

এখন Dockerfile থেকে একটি image তৈরি করি:

docker build -t new_go_server:1.0.0 .

এখানে:

docker build

→ Dockerfile instructions অনুসরণ করে image তৈরি করবে।

-t new_go_server:1.0.0

→ image-এর name এবং version tag।

→ current directory-কে build context হিসেবে ব্যবহার করবে।

Reference workflow-এও docker build -t new_go_server:1.0.0 . ব্যবহার করা হয়েছে।

16. What Happens During `docker build`?

আমাদের Dockerfile:

FROM ubuntu:24.04

RUN apt update

RUN apt install -y golang

WORKDIR /app

COPY ./server.go ./server.go

Docker build করার সময় conceptually:

FROM ubuntu:24.04
        ↓
Base Image
        ↓
RUN apt update
        ↓
Install Go
        ↓
WORKDIR /app
        ↓
COPY server.go
        ↓
Final Image

Docker প্রতিটি instruction অনুসরণ করে একটি নতুন image তৈরি করে।

এখানে সবচেয়ে গুরুত্বপূর্ণ পরিবর্তন হলো:

আগে আমরা environment তৈরি করছিলাম manually।

এখন Docker environment তৈরি করছে Dockerfile-এর instructions অনুসরণ করে।

17. Run the Custom Image

Image তৈরি হয়ে গেছে।

এখন:

docker run -it new_go_server:1.0.0 bash

Container-এর ভিতরে ঢুকলে আমরা /app directory-তে থাকব।

কারণ Dockerfile-এ:

WORKDIR /app

দেওয়া আছে।

এখন:

ls

দিলে:

server.go

দেখা যাবে।

তারপর:

go run server.go

Output:

Server is running on :8080

অর্থাৎ আমাদের image-এর ভিতরে ইতিমধ্যেই:

Ubuntu আছে
Go আছে
/app আছে
server.go আছে

আমাদের শুধু application run করতে হচ্ছে।

Reference workflow-এও custom image run করার পর /app-এ server.go পাওয়া এবং go run server.go দিয়ে application চালানোর বিষয়টি দেখানো হয়েছে।

18. The Workflow Has Completely Changed

আগের workflow:

Manual Setup
     ↓
Manual Configuration
     ↓
Manual Copy
     ↓
Manual Testing
     ↓
docker commit

এখন:

Dockerfile
     ↓
docker build
     ↓
Image
     ↓
docker run
     ↓
Application

এটাই Docker-এর real engineering advantage।

19. What If the Code Changes?

ধরুন server.go-তে আমরা পরিবর্তন করলাম।

Manual approach-এ আবার পুরো environment setup করতে হতে পারে।

Dockerfile approach-এ:

docker build -t new_go_server:1.0.1 .

নতুন image তৈরি করা যায়।

Version tag-ও পরিবর্তন করা যায়:

new_go_server:1.0.0
new_go_server:1.0.1
new_go_server:1.0.2

এতে application image-এর version track করা সহজ হয়।

Reference comparison-এ Dockerfile workflow-এর এই repeatable build এবং version-control-friendly nature-কে manual docker commit workflow-এর তুলনায় বড় সুবিধা হিসেবে দেখানো হয়েছে।

20. Why This Matters in Real Engineering

এখন বিষয়টা শুধু Docker শেখার মধ্যে সীমাবদ্ধ নয়।

ধরুন একটি team-এ পাঁচজন developer আছে।

Manual workflow হলে প্রত্যেক developer-এর environment setup আলাদা হতে পারে।

একজনের:

Go version A

অন্যজনের:

Go version B

কেউ অন্য package install করেছে।

কেউ কিছু configuration পরিবর্তন করেছে।

ফলে classic problem:

“It works on my machine.”

Dockerfile এই সমস্যাকে পুরোপুরি magic-এর মাধ্যমে solve করে না, কিন্তু environment creation-কে explicit, repeatable এবং version-controlled করার একটি শক্তিশালী mechanism দেয়।

একজন developer Dockerfile পাবে।

একটি image build করবে।

তারপর একই defined environment-এর ভিত্তিতে application চালাবে।

21. Dockerfile Is Infrastructure as Code Thinking

Dockerfile-এর সবচেয়ে গুরুত্বপূর্ণ lesson শুধু Docker syntax নয়।

এটি একটি broader engineering mindset শেখায়:

Infrastructure and environment configuration should be reproducible.

আমরা আগে environment তৈরি করছিলাম command-by-command।

এখন environment definition একটি file-এ:

FROM ubuntu:24.04

RUN apt update
RUN apt install -y golang

WORKDIR /app

COPY ./server.go ./server.go

এই file Git repository-তে রাখা যায়।

Code review করা যায়।

Change track করা যায়।

একজন নতুন developer repository clone করে একই environment build করতে পারে।

এখান থেকেই Docker CI/CD এবং DevOps workflow-এর সঙ্গে naturally connect করতে শুরু করে।

Reference material-এও Dockerfile-কে version control এবং production/CI-CD workflow-এর জন্য বেশি উপযোগী হিসেবে আলাদা করা হয়েছে।

22. One Important Distinction: Image vs Container

এই পুরো article-এর মধ্যে একটি mental model সবচেয়ে গুরুত্বপূর্ণ।

Dockerfile
    │
    │ docker build
    ▼
 Docker Image
    │
    │ docker run
    ▼
 Docker Container
    │
    ▼
Go Application

Dockerfile

Environment কীভাবে তৈরি হবে তার definition।

Image

সেই definition থেকে তৈরি packaged environment।

Container

সেই image-এর running instance।

এই distinction পরিষ্কার থাকলে Docker-এর অনেক concept অনেক সহজ হয়ে যায়।

23. The Complete Example

আমাদের project:

docker-learning/
│
├── Dockerfile
└── server.go

`server.go`

package main

import (
    "fmt"
    "net/http"
)

func main() {
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintln(w, "Hello World!")
    })

    fmt.Println("Server is running on :8080")
    http.ListenAndServe(":8080", nil)
}

`Dockerfile`

FROM ubuntu:24.04

RUN apt update

RUN apt install -y golang

WORKDIR /app

COPY ./server.go ./server.go

Build

docker build -t new_go_server:1.0.0 .

Run

docker run -it new_go_server:1.0.0 bash

Start the application

go run server.go

Test

curl http://localhost:8080

Expected:

Hello World!

24. A Small but Important Production Note

উপরের Dockerfile একটি learning-oriented example।

এখানে আমরা ইচ্ছাকৃতভাবে Ubuntu-এর ভিতরে Go install করছি, যাতে FROM, RUN, WORKDIR, এবং COPY—এই fundamental Dockerfile instructions পরিষ্কারভাবে বোঝা যায়।

Production environment-এ একই Go application-এর জন্য আরও optimized approach ব্যবহার করা যায়—যেমন:

multi-stage builds
smaller runtime images
compiled Go binary
explicit CMD বা ENTRYPOINT
dependency caching
non-root execution
health checks

অর্থাৎ এই Dockerfile-কে production-ready final architecture হিসেবে নয়, বরং Dockerfile fundamentals বোঝার foundation হিসেবে দেখা উচিত।

25. The Bigger Picture

এই ছোট Go server example-এর মধ্যেই Docker-এর একটি বড় philosophy লুকিয়ে আছে।

আমরা শুরু করেছিলাম:

“আমি নিজে container configure করব।”

তারপর:

“আমার configuration-এর একটা snapshot নিয়ে রাখি।”

docker commit আমাদের সেই capability দেয়।

কিন্তু তারপর প্রশ্ন আসে:

“আমি কি এই configuration-টাকে লিখে রাখতে পারি?”

উত্তর:

Yes. Dockerfile.

তারপর:

Dockerfile
    ↓
docker build
    ↓
Image
    ↓
docker run
    ↓
Container

এখন environment creation আর developer-এর memory-এর ওপর নির্ভর করছে না।

এটি একটি file-এর মধ্যে definition হিসেবে আছে।

Final Takeaway

Docker শেখার সময় শুধু command মুখস্থ করা যথেষ্ট নয়।

সবচেয়ে গুরুত্বপূর্ণ হলো এই transformation বোঝা:

Manual Work
    ↓
Automation
    ↓
Reproducibility
    ↓
Consistency

আমরা প্রথমে একটি Ubuntu container manually configure করেছি।

Go install করেছি।

server.go copy করেছি।

Application চালিয়েছি।

তারপর docker commit দিয়ে সেই configured environment-এর snapshot নিয়েছি।

কিন্তু বুঝেছি—এভাবে প্রতিবার environment তৈরি করা scalable নয়।

তাই একই process-কে Dockerfile-এ লিখেছি:

FROM ubuntu:24.04

RUN apt update
RUN apt install -y golang

WORKDIR /app

COPY ./server.go ./server.go

তারপর:

docker build -t new_go_server:1.0.0 .

এবং একটি reproducible image তৈরি করেছি।

শেষ পর্যন্ত:

Source Code
     ↓
Dockerfile
     ↓
Docker Image
     ↓
Docker Container
     ↓
Go Server
     ↓
HTTP Response

এটাই Docker-এর সবচেয়ে গুরুত্বপূর্ণ engineering lesson:

Don't just build an environment. Define how to build it.

কারণ manual setup একজন developer-এর knowledge হতে পারে।

কিন্তু Dockerfile সেই knowledge-কে code-এ পরিণত করে।

And once your environment becomes code, it becomes much easier to reproduce, version, review, automate, and ship.

🐳 That is where Docker starts becoming an engineering tool—not just a container runtime.

Docker Hands-On: Image থেকে Container, তারপর নিজের Custom Image

Ragib Hasan — Sun, 30 Aug 2026 05:46:43 +0000

Docker শেখার সময় সবচেয়ে বড় সমস্যা Docker-এর command মনে রাখা নয়—বরং Docker আসলে কী করছে সেটা বোঝা।

docker run, docker pull, docker ps, docker exec, docker build—এই commandগুলো আলাদা আলাদা করে মুখস্থ করলে Docker কিছুদিন পরেই confusing মনে হতে পারে।

কিন্তু যদি আমরা একটি simple mental model তৈরি করি—

Image → Container → Process

তাহলে Docker-এর অনেক কিছুই surprisingly সহজ হয়ে যায়।

এই লেখায় আমরা একদম hands-on approach-এ দেখব কীভাবে Docker Hub থেকে একটি Ubuntu image local machine-এ আনা যায়, সেটি থেকে একাধিক container তৈরি করা যায়, container-এর সঙ্গে interactiveভাবে কাজ করা যায় এবং শেষে একটি Dockerfile ব্যবহার করে নিজের custom Docker image তৈরি করা যায়।

Docker শুরু করার আগে: Image আর Container-এর পার্থক্য

প্রথমে সবচেয়ে গুরুত্বপূর্ণ distinction:

Docker Image কী?

একটি Docker Image হলো একটি read-only template/package, যার মধ্যে application চালানোর জন্য প্রয়োজনীয় filesystem, libraries, configuration এবং অন্যান্য প্রয়োজনীয় উপাদান থাকে।

উদাহরণ:

ubuntu:24.04

এটি Ubuntu 24.04-এর একটি Docker image।

Docker Hub-এর মতো registry থেকে image local machine-এ pull করা যায়। তারপর সেই image ব্যবহার করে container তৈরি করা যায়।

Container কী?

Container হলো সেই image-এর running বা instantiated form।

অর্থাৎ—

Docker Image
      ↓
Container
      ↓
Process / Command

একটি image থেকে একাধিক independent container তৈরি করা সম্ভব। একই ubuntu:24.04 image ব্যবহার করে একাধিক container চালানো যায়, এবং প্রতিটি container-এর নিজস্ব runtime state থাকে।

এটাই Docker-এর একটি fundamental concept।

1. Local Machine-এ কোন Image আছে?

প্রথমে দেখি আমাদের Docker environment-এ কোন কোন image already available।

docker images

এই command local image cache-এর imageগুলো দেখায়।

সাধারণত এখানে আমরা দেখতে পারি:

REPOSITORY    TAG       IMAGE ID       CREATED       SIZE
ubuntu        24.04     ........       ...           101MB

এখানে গুরুত্বপূর্ণ কয়েকটি field:

REPOSITORY → image-এর নাম
TAG → version/variant
IMAGE ID → image-এর unique identifier
CREATED → image কখন তৈরি হয়েছে
SIZE → image-এর size

যেমন:

ubuntu:24.04

এখানে:

ubuntu     → Repository
24.04      → Tag

docker images local cache-এ থাকা imageগুলো দেখতে ব্যবহৃত হয়।

2. Docker Hub থেকে Image Pull করা

যদি local machine-এ ubuntu:24.04 না থাকে, তাহলে Docker Hub থেকে image pull করা যায়:

docker pull ubuntu:24.04

এখানে Docker remote registry থেকে image-এর প্রয়োজনীয় layers download করে local machine-এ store করে।

তারপর আবার:

docker images

চালালে image-টি local cache-এ দেখতে পাব।

এখানে একটি গুরুত্বপূর্ণ বিষয় আছে:

docker pull মূলত image-কে local environment-এ এনে রাখে; এটি নিজে থেকে interactive container তৈরি করে না।

Docker image layer-based হওয়ায় কোনো কোনো layer আগে থেকেই local machine-এ থাকলে Docker সেগুলো আবার download না করে reuse করতে পারে।

3. Image Remove করা

ধরুন local machine থেকে ubuntu:24.04 remove করতে চাই।

docker rmi ubuntu:24.04

কিন্তু যদি কোনো existing container এই image-এর সঙ্গে associated থাকে, Docker image remove করতে বাধা দিতে পারে।

সেক্ষেত্রে force removal:

docker rmi -f ubuntu:24.04

তবে production environment-এ -f blindly ব্যবহার না করাই ভালো। আগে বুঝতে হবে কোন container বা resource-এর সঙ্গে image-এর dependency রয়েছে।

4. Image থেকে Container তৈরি করা

এখন আসি Docker-এর সবচেয়ে গুরুত্বপূর্ণ command-এ:

docker run

সহজভাবে:

docker run ubuntu:24.04

এখানে Docker ubuntu:24.04 image ব্যবহার করে একটি নতুন container তৈরি করে এবং সেটিতে specified/default process চালানোর চেষ্টা করে।

কিন্তু interactive shell নিয়ে কাজ করতে চাইলে আমরা সাধারণত ব্যবহার করব:

docker run -it ubuntu:24.04 bash

এই command-টিকে ভেঙে দেখি।

docker run
    ↓
-it
    ↓
ubuntu:24.04
    ↓
bash

`docker run`

Container create এবং start করার মূল command।

`ubuntu:24.04`

যে image থেকে container তৈরি হবে।

`bash`

Container-এর ভিতরে যে command/process চালানো হবে।

`-it`

Interactive terminal session-এর জন্য প্রয়োজনীয় দুইটি option-এর combination।

5. `-it` আসলে কী?

Docker শেখার সময় -it সবচেয়ে বেশি দেখা যায়।

এটি দুটি flag-এর combination:

-i
-t

`-i` → Interactive / STDIN

-i container-এর standard input stream open রাখে।

অর্থাৎ container যেন input গ্রহণ করতে পারে।

docker run -i ubuntu:24.04 bash

এখানে input দেওয়া সম্ভব হলেও terminal experience সম্পূর্ণ normal terminal-এর মতো নাও হতে পারে।

`-t` → Pseudo-TTY

-t একটি pseudo-terminal allocate করে।

এর ফলে shell-এর terminal-style interface পাওয়া যায়।

কিন্তু শুধু -t দিলে interactive keyboard input-এর জন্য STDIN open নাও থাকতে পারে।

তাই আমরা সাধারণত ব্যবহার করি:

docker run -it ubuntu:24.04 bash

অর্থাৎ:

-i → Input open
-t → Terminal interface

দুটো একসঙ্গে:

-it → Interactive terminal session

এই breakdown-টি Docker-এর interactive usage বোঝার জন্য অত্যন্ত গুরুত্বপূর্ণ।

6. Container-এর ভিতরে কী হচ্ছে?

Container-এর ভিতরে ঢোকার পর আমরা সাধারণ Linux command ব্যবহার করতে পারি:

pwd
ls
cd /bin
ls

এখানে গুরুত্বপূর্ণ বিষয় হলো:

আমরা Docker-এর কোনো magical command ব্যবহার করছি না।

আমরা আসলে container-এর filesystem-এর ভিতরে একটি process—এই ক্ষেত্রে bash—এর মাধ্যমে Linux environment-এর সঙ্গে interact করছি।

এই কারণেই Linux fundamentals জানা থাকলে Docker অনেক সহজ হয়ে যায়।

7. Running Container দেখতে `docker ps`

একটি container চালু থাকা অবস্থায়:

docker ps

চালালে running containers দেখা যাবে।

Output-এ সাধারণত দেখা যায়:

CONTAINER ID
IMAGE
COMMAND
CREATED
STATUS
PORTS
NAMES

অর্থাৎ Docker শুধু container ID দেখাচ্ছে না; container কোন image ব্যবহার করছে, কোন command চালাচ্ছে, কখন তৈরি হয়েছে, status কী এবং তার নাম কী—এসব information-ও দেখায়।

8. Running + Stopped সব Container দেখতে

শুধু running container দেখতে:

docker ps

কিন্তু stopped বা exited container-সহ সব দেখতে:

docker ps -a

এটি খুব গুরুত্বপূর্ণ distinction।

docker ps
    ↓
Running containers

docker ps -a
    ↓
Running + Stopped/Exited containers

9. একটি Image থেকে Multiple Containers

এখানে Docker-এর একটি সুন্দর property দেখা যায়।

আমাদের কাছে যদি থাকে:

ubuntu:24.04

তাহলে আমরা করতে পারি:

docker run -it ubuntu:24.04 bash

তারপর আবার:

docker run -it ubuntu:24.04 sh

আবার:

docker run -it ubuntu:24.04 bash

ফলে একই image থেকে তিনটি আলাদা container তৈরি হতে পারে।

Conceptually:

                ubuntu:24.04
                      │
        ┌─────────────┼─────────────┐
        ↓             ↓             ↓
   Container 1   Container 2   Container 3
      bash           sh            bash

Image একটি template; container হলো সেই template-এর runtime instance।

এটি Docker-এর mental model-এর অন্যতম গুরুত্বপূর্ণ অংশ।

10. Container-এর Random Name কেন আসে?

Docker যখন আমরা manually কোনো name না দিই, তখন container-এর জন্য একটি automatically generated name দিতে পারে।

যেমন:

hardcore_goldstine

সমস্যা হলো, এমন নাম মনে রাখা সবসময় সহজ নয়।

তাই আমরা নিজের meaningful name দিতে পারি।

docker run --name my_ubuntu -it ubuntu:24.04 bash

এখন container-এর নাম:

my_ubuntu

এটি পরে container access এবং management অনেক সহজ করে দেয়।

11. Running Container-এর ভিতরে `docker exec`

ধরুন একটি container already running:

my_ubuntu

অন্য একটি terminal থেকে সেই running container-এর ভিতরে নতুন interactive shell খুলতে পারি:

docker exec -it my_ubuntu bash

এখানে:

docker exec
      ↓
existing container
      ↓
bash

অর্থাৎ নতুন container তৈরি হচ্ছে না।

Already running container-এর ভিতরে একটি নতুন process execute হচ্ছে।

এটি docker run এবং docker exec-এর মধ্যে একটি গুরুত্বপূর্ণ পার্থক্য।

docker run
→ নতুন container তৈরি করে

docker exec
→ existing running container-এর ভিতরে command চালায়

12. Container-এর ভিতরের State

ধরুন আমরা my_ubuntu container-এর ভিতরে:

mkdir /app
cd /app
touch myfile.txt

এখন অন্য terminal থেকে:

docker exec -it my_ubuntu bash

দিয়ে একই container-এ ঢুকলে:

ls /app

আমরা দেখতে পাব:

myfile.txt

কারণ দুই terminal আলাদা হলেও তারা একই container-এর filesystem-এর সঙ্গে কাজ করছে।

এটি docker exec বোঝার জন্য একটি অত্যন্ত কার্যকর hands-on example।

13. এবার নিজের Docker Image বানানো যাক

এখন পর্যন্ত আমরা existing image ব্যবহার করেছি।

কিন্তু real-world development-এ আমাদের প্রায়ই নিজের application-এর জন্য custom image তৈরি করতে হয়।

সেখানেই আসে:

Dockerfile

একটি নতুন directory তৈরি করি:

mkdir docker-tutorial
cd docker-tutorial

তারপর তৈরি করি:

Dockerfile

খেয়াল করুন:

Dockerfile

নামটি সাধারণত এই exact convention-এই রাখা হয়।

14. একটি Simple Dockerfile

আমাদের প্রথম Dockerfile:

FROM ubuntu:24.04

RUN echo "Hello World" > /hello.txt

CMD ["bash"]

এখন প্রতিটি instruction বুঝি।

`FROM`

FROM ubuntu:24.04

এটি আমাদের base image নির্ধারণ করে।

অর্থাৎ:

এই custom image-এর foundation হবে ubuntu:24.04।

`RUN`

RUN echo "Hello World" > /hello.txt

Image build হওয়ার সময় এই command execute হবে।

ফলে image-এর filesystem-এর মধ্যে:

/hello.txt

নামে একটি file তৈরি হবে।

File-এর content:

Hello World

`CMD`

CMD ["bash"]

Container start হওয়ার সময় default command হিসেবে bash ব্যবহার করার নির্দেশ দেয়।

সহজভাবে:

FROM
 ↓
Base image

RUN
 ↓
Build-time operation

CMD
 ↓
Default runtime command

Dockerfile-এর এই basic structure পরবর্তীতে আরও advanced Docker configuration বোঝার foundation তৈরি করে।

15. Dockerfile থেকে Image Build করা

এখন Dockerfile যে directory-তে আছে সেখানে:

docker build -t custom_ubuntu .

এই command-এর তিনটি গুরুত্বপূর্ণ অংশ:

docker build
     ↓
-t custom_ubuntu
     ↓
.

`docker build`

Dockerfile-এর instructions অনুসরণ করে একটি নতুন image তৈরি করবে।

`-t custom_ubuntu`

Image-কে একটি meaningful name/tag দেয়।

`.`

বর্তমান directory-কে build context হিসেবে নির্দেশ করে।

অর্থাৎ Docker বর্তমান directory থেকে Dockerfile এবং প্রয়োজনীয় build context ব্যবহার করবে।

16. Build শেষ হলে কী হলো?

Build সফল হলে:

docker images

চালালে আমরা দেখতে পাব:

custom_ubuntu    latest    ........    101MB

এখানে আমরা কোনো explicit tag না দিলে Docker সাধারণত:

latest

tag ব্যবহার করে।

অর্থাৎ:

custom_ubuntu

প্রকৃতপক্ষে:

custom_ubuntu:latest

হিসেবে দেখা যেতে পারে।

17. এবার নিজের Image Run করি

আমাদের custom image এখন ready।

চালাই:

docker run -it custom_ubuntu bash

Container-এর ভিতরে:

ls /

দিলে আমরা দেখতে পাব:

hello.txt

তারপর:

cat /hello.txt

Output:

Hello World

এখানেই Dockerfile-এর power স্পষ্ট হয়।

আমরা manually container-এর ভিতরে file তৈরি করিনি।

Image build করার সময় Dockerfile-এর:

RUN echo "Hello World" > /hello.txt

instruction file-টি image-এর filesystem-এ তৈরি করে দিয়েছে।

Docker-এর পুরো Flow এক নজরে

এখন পুরো বিষয়টাকে একটি flow হিসেবে দেখি:

                 Docker Hub
                     │
                     │ docker pull
                     ▼
              Local Image Cache
                     │
                     │ docker run
                     ▼
                 Container
                     │
                     │ command/process
                     ▼
                   bash

আর custom image-এর ক্ষেত্রে:

             Dockerfile
                  │
                  │ docker build
                  ▼
            Custom Image
                  │
                  │ docker run
                  ▼
              Container
                  │
                  ▼
            Application

এই দুইটি flow বুঝতে পারলে Docker-এর অনেক command আর isolated command মনে হবে না।

সবচেয়ে গুরুত্বপূর্ণ Docker Commands

এই hands-on session-এর commandগুলো এক জায়গায়:

Command	কাজ
`docker images`	Local images দেখা
`docker pull ubuntu:24.04`	Docker Hub থেকে image pull করা
`docker rmi ubuntu:24.04`	Image remove করা
`docker rmi -f ubuntu:24.04`	Force করে image remove করা
`docker ps`	Running containers দেখা
`docker ps -a`	সব containers দেখা
`docker run -it ubuntu:24.04 bash`	Interactive Ubuntu container চালানো
`docker run --name my_ubuntu -it ubuntu:24.04 bash`	Custom name দিয়ে container চালানো
`docker exec -it my_ubuntu bash`	Running container-এর ভিতরে shell চালানো
`docker build -t custom_ubuntu .`	Dockerfile থেকে custom image build করা

এই command reference-টির ভিত্তি দেওয়া hands-on notes-এও একইভাবে সংগঠিত হয়েছে।

কয়েকটি গুরুত্বপূর্ণ Mental Model

Docker শেখার সময় শুধু command মনে না রেখে এই কয়েকটি relationship মাথায় রাখা বেশি গুরুত্বপূর্ণ।

1. Image ≠ Container

Image → Template
Container → Runtime Instance

2. `docker pull` ≠ `docker run`

docker pull
→ Image local machine-এ আনে

docker run
→ Image থেকে container তৈরি ও start করে

3. `docker run` ≠ `docker exec`

docker run
→ New container

docker exec
→ Existing running container-এর ভিতরে নতুন process

4. `docker ps` ≠ `docker ps -a`

docker ps
→ Running

docker ps -a
→ Running + Exited

5. `-i` ≠ `-t`

-i → STDIN open
-t → Pseudo-TTY
-it → Interactive terminal experience

শেষ কথা: Docker কেন শুরুতে কঠিন মনে হয়?

Docker-এর command খুব বেশি কঠিন নয়।

কঠিন হয় যখন আমরা Docker-কে isolated technology হিসেবে শেখার চেষ্টা করি।

যদি Linux filesystem, process, shell, standard input/output, terminal, networking এবং basic operating-system concepts সম্পর্কে ধারণা থাকে, তাহলে Docker-এর behaviour অনেক বেশি logical মনে হয়।

এই hands-on journey-তে তাই সবচেয়ে গুরুত্বপূর্ণ lesson শুধু:

docker run

বা

docker build

মনে রাখা নয়।

বরং বোঝা:

একটি image কীভাবে container-এ পরিণত হয়, container-এর ভিতরে process কীভাবে চলে, এবং Dockerfile কীভাবে সেই environment reproducibly তৈরি করে।

আজ আমরা Docker-এর foundation তৈরি করলাম:

Image → Container → Process → Dockerfile → Custom Image

এর পরের ধাপে এই foundation-এর ওপর দাঁড়িয়ে আরও বাস্তব বিষয়—production-grade Dockerfile, application containerization, networking, ports, volumes, এবং multi-container architecture—বোঝা অনেক সহজ হবে।

Docker আসলে কোনো জাদু নয়।

ঠিক mental model তৈরি করতে পারলে এটি একটি অত্যন্ত predictable এবং powerful tool.

Learn the model, not just the commands. 🐳

Linux User, Group & File Permission Management — A Hands-on Guide 🐧

Ragib Hasan — Sun, 30 Aug 2026 04:43:19 +0000

Linux শিখতে গেলে কিছু বিষয় এড়িয়ে যাওয়ার সুযোগ নেই। তার মধ্যে অন্যতম হলো User, Group এবং File Permission Management।

Docker, Kubernetes, Server Administration, Cloud বা DevOps—যে দিকেই যেতে চান না কেন, Linux-এর এই মৌলিক বিষয়গুলো পরিষ্কারভাবে বোঝা খুবই গুরুত্বপূর্ণ।

এই লেখায় আমরা একদম হাতে-কলমে দেখব:

Linux User কী?
Root User এবং Normal User-এর পার্থক্য
নতুন User তৈরি করা
User-এর তথ্য দেখা
Password সেট করা
User switch করা
User lock/unlock করা
User delete করা
Group কী এবং কেন ব্যবহার করা হয়
Primary ও Supplementary Group
Group তৈরি ও delete করা
Group-এ User যোগ/বাদ দেওয়া
Linux File Permission কী?
r, w, x কী?
User, Group এবং Others-এর permission
chmod দিয়ে permission পরিবর্তন
chown দিয়ে ownership পরিবর্তন
ls -l output কীভাবে পড়তে হয়

1. Linux User কী?

আপনি যখন Linux machine-এ login করেন, তখন আপনি একটি User হিসেবে কাজ করেন।

Linux-এ সাধারণভাবে দুই ধরনের User নিয়ে কাজ করা হয়:

                    Linux Users
                         │
             ┌───────────┴───────────┐
             │                       │
        Root User              Normal User
        (Superuser)            (Standard User)
             │                       │
       Full Control             Limited Access

Root User

Root হলো Linux-এর সবচেয়ে powerful user।

Root user-এর system-এর প্রায় সব resource-এর ওপর administrative control থাকে। সে file দেখতে, modify করতে, delete করতে এবং permission পরিবর্তন করতে পারে।

Root shell-এ সাধারণত prompt-এর শেষে # দেখা যায়:

root@ubuntu:/#

Normal User

Normal user সাধারণ কাজের জন্য ব্যবহৃত হয় এবং তার access সীমিত থাকে। এর উদ্দেশ্য হলো অসাবধানতাবশত গুরুত্বপূর্ণ system file বা configuration পরিবর্তন করে ফেলা থেকে system-কে রক্ষা করা।

Normal user-এর prompt সাধারণত $ দিয়ে শেষ হয়:

habib@ubuntu:~$

Rule of thumb: প্রতিদিনের কাজের জন্য normal user ব্যবহার করা নিরাপদ; administrative কাজের জন্য প্রয়োজন অনুযায়ী elevated privileges ব্যবহার করা উচিত।

2. User Management

এবার terminal-এ হাতে-কলমে User management করা যাক।

নতুন User তৈরি করা

useradd দিয়ে নতুন user তৈরি করা যায়।

useradd -m habib

এখানে:

useradd → নতুন user তৈরি করে
-m → user-এর জন্য home directory তৈরি করে
habib → নতুন username

-m ব্যবহার করলে সাধারণত:

/home/habib

directory তৈরি হবে। -m না দিলে account তৈরি হলেও home directory স্বয়ংক্রিয়ভাবে তৈরি নাও হতে পারে।

User-এর UID এবং Group Information দেখা

কোনো user-এর identification information দেখতে:

id habib

উদাহরণ:

uid=1001(habib)
gid=1001(habib)
groups=1001(habib)

এখানে:

uid → User ID
gid → Group ID
groups → User কোন কোন group-এর সদস্য

Linux-এ username-এর পাশাপাশি UID এবং GID গুরুত্বপূর্ণ কারণ system internally এই numeric IDs ব্যবহার করে user এবং group identify করে।

3. System-এর সব User দেখা

Linux system-এর user account-এর information /etc/passwd-এ পাওয়া যায়।

দেখতে:

cat /etc/passwd

cat এখানে file-এর content terminal-এ print করার জন্য ব্যবহার করা হয়েছে।

উদাহরণ হিসেবে:

root:x:0:0:root:/root:/bin/bash
habib:x:1001:1001::/home/habib:/bin/bash

এখান থেকে user-এর account-related information পাওয়া যায়।

4. User-এর Password Set করা

নতুন user-এর password সেট করতে:

passwd habib

তারপর Linux নতুন password এবং confirmation চাইবে।

New password:
Retype new password:
passwd: password updated successfully

Root user অন্য user-এর password সেট বা পরিবর্তন করতে পারে।

5. এক User থেকে অন্য User-এ Switch করা

User switch করার জন্য su ব্যবহার করা যায়।

su - habib

- ব্যবহার করলে target user's login environment সহ shell শুরু করা হয়।

আবার আগের shell-এ ফিরে আসতে:

exit

উদাহরণ:

root@ubuntu:/# su - habib
habib@ubuntu:~$

এখানে লক্ষ্য করুন:

Root    → #
Normal  → $

Source demonstration-এ root থেকে normal user-এ switch করার ক্ষেত্রে password প্রয়োজন হয়নি, কিন্তু normal user থেকে অন্য user বা root-এ switch করার ক্ষেত্রে authentication প্রয়োজন হয়েছে।

6. User Lock ও Unlock

কোনো user-এর login temporarily বন্ধ করতে চাইলে:

usermod -L habib

এখানে -L অর্থ account lock করা।

আবার unlock করতে:

usermod -U habib

এখানে -U account unlock করে।

এটি useful হতে পারে যখন কোনো account-এর login সাময়িকভাবে বন্ধ রাখতে হয়।

7. User Delete করা

শুধু user account delete করতে:

userdel habib

আর user-এর home directory-সহ delete করতে:

userdel -r habib

-r ব্যবহার করলে user-এর home directory এবং associated files-ও remove করার চেষ্টা করা হয়।

⚠️ Production server-এ এই command চালানোর আগে অবশ্যই নিশ্চিত হোন যে user-এর প্রয়োজনীয় data backup করা আছে।

8. Linux Group কী?

ধরুন একটি project-এ ১০ জন developer আছে।

আপনি চাইছেন তারা সবাই একটি নির্দিষ্ট directory access করতে পারবে।

প্রত্যেক user-এর permission আলাদাভাবে manage করার বদলে একটি Group তৈরি করে সবাইকে সেই group-এর member করা যায়।

অর্থাৎ:

Developer 1 ─┐
Developer 2 ─┤
Developer 3 ─┼──> developers group
Developer 4 ─┘

তারপর directory-র group permission configure করলেই group-এর members-দের access নিয়ন্ত্রণ করা যায়।

9. Primary Group বনাম Supplementary Group

Linux-এ user-এর সঙ্গে একাধিক group সম্পর্ক থাকতে পারে।

দুইটি গুরুত্বপূর্ণ category হলো:

Primary Group

User account তৈরির সময় একটি primary group থাকতে পারে এবং source example-এ user-এর username অনুযায়ী একটি group তৈরি হয়েছে। Primary group user-এর group identity-এর গুরুত্বপূর্ণ অংশ।

Supplementary Group

একজন user অতিরিক্ত একাধিক group-এর member হতে পারে।

উদাহরণ:

habib
 ├── habib       ← Primary Group
 ├── admin       ← Supplementary Group
 └── developers  ← Supplementary Group

এভাবে একই user একাধিক project বা resource group-এর অংশ হতে পারে।

10. Group তৈরি করা

নতুন group তৈরি করতে:

groupadd admin

এতে admin নামে একটি group তৈরি হবে।

System-এর group list দেখতে:

cat /etc/group

বর্তমান user কোন কোন group-এর member তা দেখতে:

groups

11. User-কে Group-এ Add করা

ধরুন admin নামে group আছে এবং আমরা habib user-কে সেখানে যোগ করতে চাই।

usermod -aG admin habib

এখানে:

usermod → user configuration পরিবর্তন
-a → append
-G → supplementary group
admin → target group
habib → target user

তারপর:

groups

দিলে নতুন group-টি দেখা যাবে।

⚠️ `-a` কেন গুরুত্বপূর্ণ?

-aG ব্যবহার না করে শুধু -G ব্যবহার করলে existing supplementary group membership replace হয়ে যাওয়ার ঝুঁকি থাকে।

তাই existing groups-এর সঙ্গে নতুন group যোগ করার সময় সাধারণত:

usermod -aG group user

pattern ব্যবহার করা হয়।

12. Group থেকে User Remove করা

gpasswd দিয়ে কোনো user-কে group থেকে remove করা যায়:

gpasswd -d habib faltu

এখানে:

habib → User
faltu → Group

অর্থাৎ faltu group থেকে habib-কে remove করা হচ্ছে।

13. Group Delete করা

Group delete করতে:

groupdel admin

এতে admin group remove হবে।

14. এবার আসি File Permissions-এ 🔐

Linux-এর অন্যতম গুরুত্বপূর্ণ concept হলো File Permission।

একটি Linux system-এ সব user যেন সব file modify বা delete করতে না পারে, সেজন্য permission system ব্যবহার করা হয়।

একটি file-এর permission দেখতে:

ls -l

উদাহরণ:

-rw-r--r-- 1 habib habib 12 Nov 23 10:05 a.txt

প্রথম অংশ:

-rw-r--r--

এটাই মূল permission information।

15. `r`, `w`, `x` — তিনটি Basic Permission

Linux permission-এর তিনটি basic mode:

Permission	Meaning
`r`	Read
`w`	Write
`x`	Execute

`r` — Read

File-এর content পড়ার permission।

r = Read

`w` — Write

File modify করার permission।

Directory-এর ক্ষেত্রে write permission থাকলে directory-এর content পরিবর্তন করার ক্ষমতা পাওয়া যায়।

`x` — Execute

Executable file বা script চালানোর permission।

Directory-এর ক্ষেত্রে x permission directory-তে enter/traverse করার সঙ্গে সম্পর্কিত।

16. User, Group এবং Others

এই অংশটি Linux permission বোঝার জন্য সবচেয়ে গুরুত্বপূর্ণ।

ধরুন:

-rwxr-xr--

এখানে permission-কে তিন ভাগে ভাগ করা যায়:

-rwx r-x r--
 │    │   │
 │    │   └── Others
 │    └────── Group
 └─────────── User / Owner

অর্থাৎ:

User     → rwx
Group    → r-x
Others   → r--

User / Owner

যে user file-এর owner।

Group

যে group file-এর সঙ্গে associated।

Others

Owner এবং group-এর বাইরে থাকা অন্য users।

এই তিন category-র জন্য আলাদা permission রাখা হয়।

17. `ls -l` Output কীভাবে পড়বেন?

এই output-টি দেখুন:

-rw-r--r-- 1 habib habib 12 Nov 23 10:05 a.txt

ভেঙে দেখলে:

-          rw-      r--      r--
│           │        │        │
│           │        │        └── Others
│           │        └─────────── Group
│           └──────────────────── User
└──────────────────────────────── File type

আর পুরো output-এর পরের অংশগুলো:

-rw-r--r--  1  habib  habib  12  Nov 23 10:05  a.txt
             │    │      │     │       │          │
             │    │      │     │       │          └── Name
             │    │      │     │       └──────────── Date
             │    │      │     └──────────────────── Size
             │    │      └────────────────────────── Group
             │    └───────────────────────────────── Owner
             └────────────────────────────────────── Link count

File type-এর ক্ষেত্রে:

- = regular file
d = directory

Source example-এ directory-এর permission string d দিয়ে শুরু হয়েছে এবং regular file-এর ক্ষেত্রে - দিয়ে শুরু হয়েছে।

18. `chmod` — Permission পরিবর্তন করা

Permission পরিবর্তনের জন্য সবচেয়ে গুরুত্বপূর্ণ command:

chmod

chmod অর্থ change mode।

ধরুন:

ls -l a.txt

Output:

-rw-r--r--

আমরা owner-এর execute permission যোগ করতে চাই।

chmod u+x a.txt

এখানে:

u = user/owner
+ = add
x = execute

ফলে permission হবে:

-rwxr--r--

Source example-এ symbolic mode ব্যবহার করে permission যোগ এবং remove করার এই পদ্ধতিগুলো দেখানো হয়েছে।

19. Permission Remove করা

Owner-এর write permission remove করতে:

chmod u-w a.txt

Group-এর read permission remove করতে:

chmod g-r a.txt

Others-এর execute permission add করতে:

chmod o+x a.txt

এখানে:

u = user
g = group
o = others

+ = add permission
- = remove permission

r = read
w = write
x = execute

এক নজরে:

chmod u+x a.txt
chmod u-w a.txt
chmod g-r a.txt
chmod o+x a.txt

20. `chown` — File Ownership পরিবর্তন

Permission এবং ownership এক জিনিস নয়।

ধরুন a.txt-এর owner বর্তমানে:

habib

আপনি owner পরিবর্তন করে habibur করতে চান।

chown habibur a.txt

chown অর্থ change ownership। Source material-এ ownership পরিবর্তনের জন্য এই command এবং root-level access-এর প্রয়োজনীয়তা দেখানো হয়েছে।

Owner এবং group দুটো একসঙ্গে specify করা যায়:

chown habibur:developers a.txt

21. Directory Permission বনাম File Permission

একটি গুরুত্বপূর্ণ বিষয় হলো—directory-এর ক্ষেত্রে permission-এর meaning কিছুটা আলাদা।

ধরুন:

drwxr-xr--

Directory-এর ক্ষেত্রে:

r → directory-এর entries list করার ক্ষমতা
w → directory-এর content পরিবর্তন করার ক্ষমতা
x → directory-তে enter/traverse করার ক্ষমতা

অর্থাৎ directory-তে x permission না থাকলে শুধু r থাকা যথেষ্ট নাও হতে পারে—directory-এর ভিতরের object access করার ক্ষেত্রে traversal permission গুরুত্বপূর্ণ।

22. `ls -l`-এর Size ও Link Count

ls -l শুধু permission দেখায় না। আরও metadata দেখায়।

উদাহরণ:

drwxr-xr-x  3  habib  habib  4096  Nov 23 10:00  files/
-rw-r--r--  1  habib  habib    12  Nov 23 10:05  a.txt

এখানে 3 এবং 1 হলো link count-এর অংশ। Directory-এর ক্ষেত্রে . এবং .. এবং subdirectory-এর কারণে এই count পরিবর্তিত হতে পারে; সাধারণ file-এর ক্ষেত্রে এটি সাধারণত 1 থাকে।

Directory size কেন 4096?

Linux filesystem-এ directory metadata-এর জন্য অনেক ক্ষেত্রে 4096 bytes-এর মতো একটি size দেখা যায়। এটি directory-এর ভিতরের সব file-এর total size বোঝায় না।

অন্যদিকে:

a.txt → 12 bytes

মানে file-এর content-এর size 12 bytes।

23. একটি ছোট Hands-on Example

এখন পুরো বিষয়টা একটি ছোট workflow দিয়ে দেখি।

Step 1 — User তৈরি

useradd -m habib

Step 2 — Password সেট

passwd habib

Step 3 — User information দেখুন

id habib

Step 4 — Group তৈরি করুন

groupadd admin

Step 5 — User-কে group-এ add করুন

usermod -aG admin habib

Step 6 — Group membership check করুন

groups habib

Step 7 — একটি file তৈরি করুন

touch a.txt

Step 8 — Permission দেখুন

ls -l a.txt

Step 9 — Owner-কে execute permission দিন

chmod u+x a.txt

Step 10 — Ownership পরিবর্তন করুন

chown habibur a.txt

এভাবেই Linux-এর user → group → permission → ownership—এই পুরো relationship-টি practically বোঝা যায়।

24. সবচেয়ে গুরুত্বপূর্ণ Commands — Cheat Sheet 🚀

# User Management
useradd -m <username>
passwd <username>
id <username>
cat /etc/passwd
su - <username>
exit
usermod -L <username>
usermod -U <username>
userdel <username>
userdel -r <username>

# Group Management
groupadd <group>
cat /etc/group
groups
usermod -aG <group> <user>
gpasswd -d <user> <group>
groupdel <group>

# Permission & Ownership
ls -l
chmod u+x <file>
chmod u-w <file>
chmod g-r <file>
chmod o+x <file>
chown <user> <file>
chown <user>:<group> <file>

এই core commands-গুলোর summary source-এর cheat sheet-এও দেওয়া হয়েছে।

25. শেষ কথা

Linux-এর User, Group এবং Permission system প্রথমে একটু complicated মনে হতে পারে। কিন্তু concept-গুলো যদি তিনটি layer হিসেবে চিন্তা করেন, তাহলে বিষয়টি অনেক সহজ:

                 Linux Security Model
                         │
          ┌──────────────┼──────────────┐
          │              │              │
        User           Group        Permissions
          │              │              │
       Who are you?   Who are they?   What can they do?

User নির্ধারণ করে কে কাজ করছে।

Group নির্ধারণ করে কোন users একই access policy share করবে।

Permission নির্ধারণ করে তারা কী করতে পারবে।

আর এই তিনটির সঙ্গে:

useradd
usermod
groupadd
chmod
chown

এর মতো command ভালোভাবে বুঝে ফেললে Linux administration-এর একটি গুরুত্বপূর্ণ foundation তৈরি হয়ে যায়।

বিশেষ করে Docker, Kubernetes, Cloud এবং DevOps-এর দিকে যেতে চাইলে Linux fundamentals শক্ত হওয়া অত্যন্ত গুরুত্বপূর্ণ। Source lesson-টিও Linux fundamentals শেষ করে পরবর্তী Docker topics-এ যাওয়ার প্রসঙ্গটি তুলে ধরে।

Linux শুধু একটা operating system নয়—একজন developer বা DevOps engineer-এর জন্য এটি একটি fundamental skill।

Happy Learning! 🐧

Linux-এর মৌলিক কমান্ড ও File System: Terminal থেকে File Management পর্যন্ত একটি Practical Guide

Ragib Hasan — Sat, 29 Aug 2026 13:32:44 +0000

Linux শেখার শুরুতে সবচেয়ে গুরুত্বপূর্ণ বিষয়গুলোর একটি হলো Terminal এবং Basic Linux Commands বোঝা।

Docker, Kubernetes, DevOps, Cloud বা System Design—যে ক্ষেত্রেই কাজ করতে চান না কেন, Linux-এর command line সম্পর্কে ভালো ধারণা থাকা অত্যন্ত গুরুত্বপূর্ণ। কারণ বাস্তব server, container এবং অনেক development environment-এ GUI-এর পরিবর্তে terminal দিয়েই অধিকাংশ কাজ করতে হয়।

এই কারণে pwd, ls, cd, mkdir, touch, cat, echo, head, tail, cp, mv, rm—এই commandগুলো শুধু মুখস্থ করলেই হবে না; এগুলো কেন এবং কীভাবে কাজ করে, সেটিও বুঝতে হবে।

১. Linux Terminal আসলে কী?

Terminal হলো Linux system-এর সঙ্গে command-এর মাধ্যমে interact করার একটি interface।

আপনি terminal খুললে সাধারণত এমন একটি prompt দেখতে পারেন:

ragib@ragib-arch:~ %

অথবা Docker container-এর ভিতরে:

root@container-id:/#

এই একটি line-এর মধ্যেই system সম্পর্কে বেশ কিছু গুরুত্বপূর্ণ information থাকে।

একটি prompt-কে ভেঙে দেখলে:

    ragib @       ragib-arch    : ~ %
      │              │            │   │
   Username       Hostname      Home Shell/
                               Directory Privilege

২. Terminal Prompt-এর প্রতিটি অংশ

Username

ragib

এটি হলো বর্তমানে যে user system-এ login করে আছে তার username।

`@` চিহ্ন

এটি username এবং machine/host name-এর মধ্যে separator হিসেবে কাজ করে।

যেমন:

user@machine

অর্থাৎ:

এই machine-এ এই user login করে আছে।

Machine / Hostname

ragib-arch

এটি হলো machine বা host-এর নাম।

Docker container-এর ক্ষেত্রে এটি container hostname-ও হতে পারে।

৩. `~` কী?

Terminal prompt-এর সবচেয়ে গুরুত্বপূর্ণ symbolগুলোর একটি হলো:

এটিকে বলা হয় tilde।

Linux shell-এ ~ সাধারণত current user's Home Directory নির্দেশ করে।

উদাহরণ:

cd ~

মানে:

আমার নিজের home directory-তে চলে যাও।

আর শুধু:

cd

দিলেও সাধারণত home directory-তে ফিরে যাওয়া যায়।

৪. `%`, `$` এবং `#` কী বোঝায়?

Terminal prompt-এর শেষে যে symbol থাকে, সেটিও গুরুত্বপূর্ণ।

`%`

Zsh shell-এ সাধারণ user-এর prompt হিসেবে % দেখা যেতে পারে।

`$`

Bash shell-এ সাধারণ user-এর prompt সাধারণত $ দিয়ে শেষ হয়।

`#`

# সাধারণত বোঝায় আপনি root/superuser হিসেবে কাজ করছেন।

উদাহরণ:

root@container:/#

এখানে:

root → user
container → hostname
/ → current directory
# → root privilege

৫. Root User-এ যাওয়া

Linux-এ administrative কাজের জন্য root privilege প্রয়োজন হতে পারে।

Source-এর উদাহরণে:

sudo su

ব্যবহার করে root user shell-এ যাওয়া দেখানো হয়েছে।

তখন prompt-এর শেষে সাধারণ $ বা %-এর পরিবর্তে:

দেখা যেতে পারে।

তবে root shell-এ কাজ করার সময় সতর্ক থাকতে হয়, কারণ ভুল command system-এর গুরুত্বপূর্ণ file বা directory পরিবর্তন করতে পারে।

৬. Linux File System-এর Root Directory

এবার আসি Linux filesystem-এর সবচেয়ে গুরুত্বপূর্ণ concept-এ।

Linux-এর filesystem শুরু হয়:

এই /-কে বলা হয় Root Directory।

এটিকে Windows-এর C:\-এর সঙ্গে সরাসরি এক করে দেখা ঠিক নয়; Linux-এর filesystem hierarchy সম্পূর্ণ tree structure-এর মতো।

Conceptually:

/
├── bin
├── boot
├── dev
├── etc
├── home
├── lib
├── media
├── proc
├── root
├── sbin
├── tmp
├── usr
└── var

৭. `/bin` — Basic Binary Commands

bin এসেছে binary থেকে।

এখানে basic command-এর executable বা binary পাওয়া যেতে পারে।

যেমন:

/bin
├── ls
├── cat
├── ...

Source-এ ls, cat, pwd-এর মতো basic command-এর উদাহরণ দেওয়া হয়েছে।

যখন আপনি terminal-এ:

ls

লিখছেন, তখন shell command-টি খুঁজে executable হিসেবে চালায়।

৮. `/boot` — Boot-এর প্রয়োজনীয় Files

/boot directory-তে system boot করার সঙ্গে সম্পর্কিত গুরুত্বপূর্ণ files থাকে।

এর মধ্যে থাকতে পারে:

Kernel-related files
Boot loader-related files

সহজভাবে:

/boot
   ↓
System Boot-এর প্রয়োজনীয় files

৯. `/dev` — Device Files

/dev directory-তে বিভিন্ন hardware/device-এর সঙ্গে সম্পর্কিত device files থাকে।

Linux-এ অনেক hardware resource-কে file-like interface-এর মাধ্যমে access করা যায়।

Conceptually:

/dev
├── Storage Devices
├── Terminal Devices
├── Other Device Interfaces
└── ...

এটি Linux-এর "everything is a file"-ধারণার একটি গুরুত্বপূর্ণ অংশ।

১০. `/etc` — Configuration Files

/etc directory মূলত system configuration-এর জন্য গুরুত্বপূর্ণ।

/etc
   ↓
System Configuration

System এবং বিভিন্ন service/application-এর configuration এখানে পাওয়া যেতে পারে।

উদাহরণ হিসেবে:

/etc/...

এর অধীনে বিভিন্ন configuration file থাকতে পারে।

১১. `/home` — সাধারণ User-এর Home Directory

সাধারণ user-এর personal files সাধারণত /home-এর অধীনে থাকে।

যেমন:

/home
├── user1
├── user2
└── user3

একজন user-এর নিজের directory-তে থাকতে পারে:

Documents
Downloads
Pictures
Music
Desktop

১২. `/lib` — Shared Libraries

/lib directory-তে system-এর প্রয়োজনীয় shared libraries থাকতে পারে।

অনেক executable তাদের কাজের জন্য বিভিন্ন library-এর ওপর নির্ভর করে।

Conceptually:

Program
   │
   ├── Library A
   ├── Library B
   └── Library C

১৩. `/media` — Mounted External Devices

External device যেমন USB drive বা external disk system-এ mount হলে /media-এর অধীনে mount point দেখা যেতে পারে।

Conceptually:

USB / External Disk
        ↓
      Mount
        ↓
     /media/...

১৪. `/proc` — Process ও Kernel Information

/proc একটি বিশেষ virtual filesystem, যেখানে running processes এবং kernel-related information পাওয়া যায়।

এটি সাধারণ storage directory-এর মতো নয়।

এখানে system-এর runtime information দেখা যায়।

১৫. `/root` — Root User-এর Home Directory

একটি common confusion:

এবং

/root

এক জিনিস নয়।

/ হলো filesystem-এর root directory।

অন্যদিকে:

/root

হলো root user-এর home directory।

১৬. `/sbin` — System Administration Binaries

/sbin-এ system administration-এর সঙ্গে সম্পর্কিত binary/command পাওয়া যেতে পারে।

সহজভাবে:

/sbin
   ↓
System Administration Commands

১৭. `/tmp` — Temporary Files

/tmp directory temporary files রাখার জন্য ব্যবহৃত হয়।

Conceptually:

Application
    ↓
Temporary Data
    ↓
/tmp

এগুলো সাধারণত permanent user data রাখার জায়গা নয়।

১৮. `/usr` — User Programs ও Applications

/usr-এর অধীনে user programs এবং applications-এর বিভিন্ন file পাওয়া যেতে পারে।

অনেক installed software-এর বিভিন্ন component এখানে থাকতে পারে।

১৯. `/var` — Variable Data, Logs ও Cache

/var এমন data-এর জন্য গুরুত্বপূর্ণ যা সময়ের সঙ্গে পরিবর্তিত হয়।

যেমন:

Logs
Cache
অন্যান্য variable data

Conceptually:

/var
├── logs
├── cache
└── variable data

২০. `pwd` — আমি এখন কোথায় আছি?

Linux terminal-এ সবচেয়ে basic কিন্তু গুরুত্বপূর্ণ command:

pwd

এর অর্থ:

Print Working Directory

এটি আপনার current working directory-এর absolute path দেখায়।

উদাহরণ:

pwd

Output:

/home/user

মানে আপনি বর্তমানে:

/home/user

directory-তে আছেন।

২১. `ls` — Directory-এর ভিতরের জিনিস দেখা

বর্তমান directory-এর file এবং folder দেখতে:

ls

ব্যবহার করা হয়।

উদাহরণ:

ls

Output হতে পারে:

Documents
Downloads
Pictures
project
notes.txt

২২. `ls -l` — Detailed Listing

শুধু নাম দেখার পরিবর্তে বিস্তারিত information দেখতে:

ls -l

এটি long listing format-এ information দেখায়।

যেমন:

permissions
owner
group
size
date/time
filename

Source-এ ls -l-কে long list হিসেবে ব্যাখ্যা করা হয়েছে।

২৩. `ls -a` — Hidden Files দেখা

Linux-এ যেসব file-এর নাম . দিয়ে শুরু হয়, সেগুলো সাধারণ ls output-এ দেখা যায় না।

Hidden file-সহ সব file দেখতে:

ls -a

উদাহরণ:

.
..
.bashrc
.profile
project

২৪. `ls -la` — সবচেয়ে Useful Listing Command

Detailed information + hidden files একসঙ্গে দেখতে:

ls -la

এটি:

-l → Long listing
-a → All files

অর্থাৎ:

ls -la

= Long listing + Hidden files

২৫. `cd` — Directory Change

cd অর্থ:

Change Directory

এক directory থেকে অন্য directory-তে যাওয়ার জন্য cd ব্যবহার করা হয়।

cd Documents

মানে:

Documents directory-তে যাও।

২৬. `cd ~` এবং `cd`

Home directory-তে যেতে:

cd ~

অথবা শুধু:

cd

ব্যবহার করা যায়।

২৭. `cd /` — Root Directory

Filesystem-এর একদম root-এ যেতে:

cd /

এরপর:

pwd

দিলে:

দেখাবে।

২৮. `cd ..` — Parent Directory

ধরুন আপনি আছেন:

/app/habib/rahim

এখন এক ধাপ উপরে যেতে:

cd ..

তাহলে যাবেন:

/app/habib

.. মানে current directory-এর parent directory।

২৯. `cd .` — Current Directory

একটি dot:

মানে current directory।

তাই:

cd .

দিলে আপনি একই directory-তেই থাকবেন।

এটি path manipulation-এর সময় বেশি গুরুত্বপূর্ণ হয়ে ওঠে।

৩০. `cd -` — আগের Directory-তে ফিরে যাওয়া

ধরুন আপনি ছিলেন:

/home/user

তারপর গেলেন:

/var/log

এখন:

cd -

দিলে আগের working directory-তে ফিরে যেতে পারবেন।

এটি দ্রুত navigation-এর জন্য খুব useful।

৩১. Absolute Path কী?

Absolute Path হলো এমন path যা filesystem-এর root / থেকে শুরু হয়।

উদাহরণ:

cd /app/habib/rahim

এখানে পুরো path root থেকে শুরু হয়েছে:

/
└── app
    └── habib
        └── rahim

তাই এটি absolute path।

৩২. Relative Path কী?

Relative path current directory-এর ওপর নির্ভর করে।

উদাহরণ:

cd ../rahim

এখানে আমরা current location থেকে relativeভাবে path তৈরি করছি।

তাই:

Absolute:
 /app/habib/rahim

Relative:
 ../rahim

৩৩. Absolute বনাম Relative Path

সহজ comparison:

বিষয়	Absolute Path	Relative Path
কোথা থেকে শুরু	`/`	Current directory
Current location-এর ওপর নির্ভরশীল	না	হ্যাঁ
Example	`/app/habib/rahim`	`../rahim`

একটি সহজ mental model:

Absolute Path
     ↓
Start from /

Relative Path
     ↓
Start from "আমি এখন যেখানে আছি"

৩৪. `mkdir` — নতুন Directory তৈরি

নতুন folder তৈরি করতে:

mkdir app

এটি app নামে একটি directory তৈরি করবে।

৩৫. `mkdir -p` — Nested Directory তৈরি

ধরুন একসঙ্গে:

habib/
└── rahim/

তৈরি করতে চান।

তাহলে:

mkdir -p habib/rahim

ব্যবহার করা যায়।

-p parent directory প্রয়োজন হলে সেটিও তৈরি করে।

৩৬. `touch` — নতুন File তৈরি

খালি file তৈরি করার জন্য:

touch a.txt

এটি a.txt নামে একটি file তৈরি করবে।

তারপর:

ls

দিলে file-টি দেখতে পারবেন।

৩৭. `cat` — File-এর Content দেখা

কোনো file-এর content terminal-এ দেখতে:

cat a.txt

ব্যবহার করা হয়।

যদি file empty হয়, তাহলে কোনো output দেখা যাবে না।

৩৮. `echo` দিয়ে File-এ লেখা

echo command-এর output file-এ redirect করা যায়।

উদাহরণ:

echo "Hello World" > a.txt

এখানে:

Hello World

a.txt-এর মধ্যে লেখা হবে।

৩৯. `>` এবং `>>` — Overwrite বনাম Append

এখানে দুটি symbol খুব গুরুত্বপূর্ণ।

`>`

echo "Hello World" > a.txt

> ব্যবহার করলে আগের content overwrite হয়ে নতুন content লেখা হয়।

অর্থাৎ:

Old Content
     ↓
     X

New Content
     ↓
  a.txt

`>>`

echo "Another Line" >> a.txt

>> আগের content রেখে file-এর শেষে নতুন content যোগ করে।

অর্থাৎ:

Hello World
Another Line

তাই মনে রাখুন:

>   = Overwrite
>>  = Append

৪০. `head` — File-এর শুরু দেখা

বড় file-এর পুরো content না দেখে প্রথম কয়েকটি line দেখতে:

head -n 5 a.txt

এটি প্রথম ৫টি line দেখাবে।

বড় log file inspect করার সময় এটি খুব useful।

৪১. `tail` — File-এর শেষ দেখা

শেষের কয়েকটি line দেখতে:

tail -n 2 a.txt

এটি শেষ ২টি line দেখাবে।

বিশেষ করে log file দেখার ক্ষেত্রে tail অত্যন্ত গুরুত্বপূর্ণ।

৪২. `cp` — File Copy করা

একটি file অন্য নামে copy করতে:

cp file1.txt file2.txt

এতে file1.txt-এর একটি copy file2.txt নামে তৈরি হবে।

Conceptually:

file1.txt
    │
    │ cp
    ▼
file2.txt

৪৩. Directory Copy করতে `cp -r`

শুধু file নয়, পুরো directory copy করতে হলে recursive option ব্যবহার করতে হয়:

cp -r rahim/ ataur/

এখানে:

-r

মানে recursive।

অর্থাৎ directory-এর ভিতরের file এবং nested directory-সহ copy হবে।

৪৪. `mv` — Move অথবা Rename

mv দিয়ে file বা directory move করা যায়।

কিন্তু একই directory-তে destination name পরিবর্তন করলে এটিই rename-এর কাজও করে।

উদাহরণ:

mv file3.txt file4.txt

এতে:

file3.txt

এর নাম হয়ে যাবে:

file4.txt

তাই:

mv
├── Move
└── Rename

৪৫. `rm` — File Delete

একটি file delete করতে:

rm file.txt

এটি destructive operation।

Delete করার আগে filename/path ভালোভাবে check করা উচিত।

৪৬. `rm -rf` — Directory Delete

Directory-এর ভিতরে file থাকলে সাধারণ:

rm folder

দিয়ে সেটি remove করা যায় না।

Recursive এবং force option ব্যবহার করে:

rm -rf habib/

directory এবং তার ভিতরের content delete করা যায়।

এখানে:

-r = recursive
-f = force

অর্থাৎ:

rm -rf
│
├── ভিতরের file delete
├── nested directory delete
└── parent directory delete

সতর্কতা: rm -rf খুব powerful এবং destructive command। ভুল path-এ চালালে গুরুত্বপূর্ণ data মুছে যেতে পারে।

৪৭. একটি Practical Workflow

এখন আমরা শেখা commandগুলো একসঙ্গে ব্যবহার করি।

প্রথমে current location দেখি:

pwd

তারপর files দেখি:

ls

Detailed listing:

ls -la

একটি directory তৈরি করি:

mkdir -p project/src

Directory-তে যাই:

cd project

তারপর:

pwd

দিয়ে location check করি।

৪৮. File তৈরি ও Content লেখা

এখন src directory-তে যাই:

cd src

একটি file তৈরি করি:

touch app.txt

Content লিখি:

echo "Hello World" > app.txt

এখন content দেখি:

cat app.txt

Output:

Hello World

আরও একটি line যোগ করতে:

echo "Linux is powerful" >> app.txt

আবার:

cat app.txt

তাহলে:

Hello World
Linux is powerful

দেখতে পাব।

৪৯. File-এর নির্দিষ্ট অংশ দেখা

ধরুন file অনেক বড়।

পুরো file দেখতে না চাইলে:

head -n 5 app.txt

প্রথম ৫ line দেখাবে।

শেষের ৫ line দেখতে:

tail -n 5 app.txt

এই technique বিশেষভাবে log এবং large text file inspect করার সময় কার্যকর।

৫০. Copy ও Rename

ধরুন:

app.txt

কে copy করতে চান:

cp app.txt backup.txt

এখন দুইটি file:

app.txt
backup.txt

Rename করতে:

mv backup.txt old-backup.txt

এখন:

app.txt
old-backup.txt

৫১. Linux Navigation-এর Mental Model

Directory navigation বুঝতে সবচেয়ে ভালো উপায় হলো একটি tree কল্পনা করা।

/
└── app
    └── habib
        └── rahim

আপনি যদি rahim-এ থাকেন:

/app/habib/rahim

তাহলে:

cd .

→ একই জায়গায় থাকবেন।

cd ..

→ habib-এ যাবেন।

cd ../..

→ app-এ যাবেন।

cd /

→ root directory-তে যাবেন।

cd ~

→ নিজের home directory-তে যাবেন।

৫২. Essential Linux Commands — Quick Reference

Command	কাজ
`pwd`	Current location দেখায়
`ls`	File ও directory list দেখায়
`ls -l`	Detailed listing
`ls -a`	Hidden files দেখায়
`ls -la`	Detailed + hidden files
`cd`	Directory change
`cd ~`	Home directory
`cd /`	Root directory
`cd ..`	Parent directory
`cd .`	Current directory
`cd -`	Previous directory
`mkdir`	Directory তৈরি
`mkdir -p`	Nested directory তৈরি
`touch`	Empty file তৈরি
`cat`	File content দেখা
`echo`	Output/file-এ text লেখা
`head`	প্রথম কয়েকটি line দেখা
`tail`	শেষ কয়েকটি line দেখা
`cp`	File copy
`cp -r`	Directory recursive copy
`mv`	Move/Rename
`rm`	File delete
`rm -rf`	Directory ও contents delete

৫৩. সবচেয়ে গুরুত্বপূর্ণ Command Combination

বাস্তবে কাজ করার সময় এই combinationগুলো খুব বেশি কাজে লাগবে:

কোথায় আছি?

pwd

এখানে কী আছে?

ls

Hidden file-সহ বিস্তারিত দেখতে চাই

ls -la

Home-এ যেতে চাই

cd ~

Root-এ যেতে চাই

cd /

এক ধাপ উপরে যেতে চাই

cd ..

আগের directory-তে ফিরতে চাই

cd -

Directory তৈরি করতে চাই

mkdir project

Nested directory তৈরি করতে চাই

mkdir -p project/src

File তৈরি করতে চাই

touch app.txt

File দেখতে চাই

cat app.txt

File-এ নতুন content লিখতে চাই

echo "Hello" > app.txt

Existing content-এর শেষে যোগ করতে চাই

echo "World" >> app.txt

File copy করতে চাই

cp app.txt backup.txt

Rename করতে চাই

mv app.txt main.txt

File delete করতে চাই

rm main.txt

৫৪. শেষ কথা

Linux-এর basic command শেখা মানে শুধু কয়েকটি command মুখস্থ করা নয়।

আপনাকে বুঝতে হবে:

Terminal
   ↓
Shell
   ↓
Command
   ↓
Filesystem
   ↓
File / Directory

আর filesystem-এর ক্ষেত্রে:

/
├── bin
├── boot
├── dev
├── etc
├── home
├── lib
├── media
├── proc
├── root
├── sbin
├── tmp
├── usr
└── var

এরপর navigation:

pwd
ls
cd

File ও directory management:

mkdir
touch
cat
echo

Content inspection:

head
tail

File management:

cp
mv
rm

এই commandগুলো Linux-এর command-line workflow-এর foundation তৈরি করে।

বিশেষ করে Docker, Kubernetes এবং system-level কাজ শেখার আগে এই fundamentals ভালোভাবে আয়ত্ত করা অত্যন্ত গুরুত্বপূর্ণ।

এক লাইনে মনে রাখুন

pwd → আমি কোথায়?
ls  → এখানে কী আছে?
cd  → কোথায় যাব?
mkdir → নতুন folder বানাব
touch → নতুন file বানাব
cat → file কী আছে দেখব
echo → file-এ লিখব
head/tail → file-এর অংশ দেখব
cp → copy করব
mv → move/rename করব
rm → delete করব

Linux-এর command line আসলে ভয় পাওয়ার মতো কিছু নয়। একটি filesystem tree এবং কয়েকটি fundamental command-এর relationship পরিষ্কার হয়ে গেলে terminal-এ কাজ করা অনেক বেশি স্বাভাবিক এবং দ্রুত হয়ে যায়।

Linux Package Management: Package, Repository, APT ও DPKG কীভাবে কাজ করে?

Ragib Hasan — Sat, 29 Aug 2026 12:50:50 +0000

Linux শেখার সময় Software Install করা খুব সাধারণ একটি কাজ। কিন্তু Linux-এ software installation-এর পেছনে আসলে কী ঘটে—Package কী, Repository কী, Package Manager কী, APT ও DPKG-এর মধ্যে পার্থক্য কী, Dependency কীভাবে resolve হয়—এসব না বুঝলে Linux-এর package ecosystem সম্পর্কে ধারণা অসম্পূর্ণ থেকে যায়।

এই লেখায় আমরা পুরো বিষয়টি step-by-step বুঝব।

১. প্রথমে একটি সহজ প্রশ্ন: Software কোথা থেকে আসে?

ধরুন আপনি Ubuntu ব্যবহার করছেন এবং আপনার git দরকার।

আপনি terminal-এ লিখলেন:

apt install git

কিন্তু এখানে একটি প্রশ্ন আসবে:

apt Git পেল কোথা থেকে?

Git আপনার computer-এর ভেতরে আগে থেকেই থাকার কথা নয়।

Git একটি package হিসেবে একটি repository-তে সংরক্ষিত থাকে। আর সেই repository থেকে package খুঁজে এনে install করার কাজ করে package manager।

অর্থাৎ পুরো সম্পর্কটি:

Repository
     ↓
Package Manager
     ↓
Package
     ↓
Linux System

এই তিনটি শব্দ তাই খুব গুরুত্বপূর্ণ:

Package → Repository → Package Manager

২. Package কী?

সহজ ভাষায়,

Package হলো software-এর একটি packaged bundle।

যেমন:

git
curl
vim
nano
vlc
nginx

এগুলো Linux system-এ package হিসেবে পাওয়া যায়।

একটি package-এর মধ্যে শুধু program-এর executable অংশ থাকে না। এর সঙ্গে software install এবং পরিচালনা করার জন্য আরও বিভিন্ন information ও file থাকতে পারে।

ধরুন git একটি package।

Conceptually:

Git Package
│
├── Program / Binary
├── Metadata
├── Dependencies
├── Installation Scripts
├── Removal Scripts
└── Configuration Files

৩. Package-এর ভিতরে কী থাকে?

এখন একটু গভীরে যাওয়া যাক।

Binary / Executable

Package-এর মূল software বা executable code এখানে থাকে।

যেমন Git install করার পরে আমরা Git command ব্যবহার করতে পারি।

Metadata

Package-এর সঙ্গে বিভিন্ন metadata থাকে।

যেমন:

Version
Maintainer
Dependencies
Package সম্পর্কিত অন্যান্য তথ্য

ধরুন:

Package: git
Version: X.Y.Z
Maintainer: ...
Dependencies: ...

অর্থাৎ package manager শুধু software-এর নাম জানলেই কাজ শেষ করে না; package সম্পর্কে আরও অনেক তথ্য তার প্রয়োজন হয়।

Installation Scripts

Package install করার সময় কিছু automated operation প্রয়োজন হতে পারে।

সেজন্য package-এর সঙ্গে installation scripts থাকতে পারে।

দুটি গুরুত্বপূর্ণ script হলো:

Pre-Install
Post-Install

Pre-Install installation শুরু হওয়ার আগে কিছু কাজ করতে পারে।

Post-Install installation শেষ হওয়ার পরে প্রয়োজনীয় configuration বা setup করতে পারে।

Removal Scripts

Package remove করার সময়ও script চালানো যেতে পারে:

Pre-Remove
Post-Remove

অর্থাৎ:

Install
   │
   ├── Pre-Install
   ├── Install
   └── Post-Install

Remove
   │
   ├── Pre-Remove
   ├── Remove
   └── Post-Remove

Configuration Files

Package-এর সঙ্গে প্রয়োজনীয় configuration files-ও থাকতে পারে।

সুতরাং একটি package-কে শুধু .deb বা .rpm file হিসেবে না দেখে software-এর installation-এর জন্য প্রয়োজনীয় একটি structured bundle হিসেবে ভাবা ভালো।

৪. Repository কী?

এবার আসি Repository-তে।

Repository হলো এমন একটি remote storage/server যেখানে software packages সংরক্ষণ করা হয়।

সহজ উদাহরণ:

Ubuntu Repository
│
├── git
├── curl
├── vim
├── nginx
├── ...
└── হাজার হাজার package

আপনি যখন কোনো software install করতে চান, package manager repository-এর সঙ্গে যোগাযোগ করে প্রয়োজনীয় package খুঁজে বের করে।

এটি অন্য ecosystem-এর সঙ্গেও তুলনা করা যায়।

যেমন:

Node.js
   ↓
npm Registry

Docker
   ↓
Docker Hub

Ubuntu
   ↓
Ubuntu Package Repository

মূল ধারণাটি একই:

কোথাও package store থাকে এবং package manager সেখান থেকে package সংগ্রহ করে।

৫. Package Manager কী?

Repository-তে package আছে।

কিন্তু সেই package খুঁজবে কে?

এখানে আসে Package Manager।

Package Manager হলো এমন একটি software/tool যা package management-এর বিভিন্ন কাজ পরিচালনা করে। যেমন:

Package search
Package download
Package installation
Package removal
Dependency management
Update
Upgrade
Cache management

Conceptually:

             Repository
                  │
                  │
                  ▼
          Package Manager
                  │
        ┌─────────┼─────────┐
        │         │         │
      Install   Remove   Upgrade
        │
        ▼
    Linux System

৬. Package Manager দুই ধরনের কেন?

Linux package management বুঝতে গেলে একটি গুরুত্বপূর্ণ distinction হলো:

High-Level Package Manager

এবং

Low-Level Package Manager

দুটোর কাজ আলাদা।

Ubuntu/Debian ecosystem-এ:

High-Level
    ↓
APT

Low-Level
    ↓
DPKG

৭. APT — High-Level Package Manager

Ubuntu-তে আমরা সবচেয়ে বেশি যে package manager ব্যবহার করি সেটি হলো:

apt

এছাড়া:

apt-get

ও ব্যবহার করা হয়।

যেমন:

apt install git

APT user-এর জন্য package management-এর বড় অংশ পরিচালনা করে।

সে:

Repository-এর সঙ্গে কাজ করে
Package খুঁজে
Dependencies resolve করে
Package download করে
Package version manage করে
Installation process পরিচালনা করে

এ কারণেই APT-কে High-Level Package Manager বলা হয়।

৮. DPKG — Low-Level Package Manager

Ubuntu/Debian system-এ dpkg হলো low-level package management tool।

dpkg

এর কাজ মূলত package archive unpack এবং system-এ package-এর file install করার মতো low-level operation পরিচালনা করা।

এখন একটি গুরুত্বপূর্ণ প্রশ্ন:

তাহলে আমরা সরাসরি dpkg ব্যবহার করি না কেন?

কারণ DPKG-এর কাজ সীমিত।

৯. Dependency কী?

Dependency হলো এমন একটি package বা software component যেটি অন্য একটি software সঠিকভাবে কাজ করার জন্য প্রয়োজন।

ধরুন:

Git
│
├── Dependency A
├── Dependency B
└── Dependency C

Git install করতে গেলে যদি Dependency A, B, C প্রয়োজন হয়, তাহলে সেগুলোও system-এ থাকতে হবে।

এখন আপনি যদি low-level dpkg দিয়ে একটি package install করেন, missing dependency নিজে থেকে repository থেকে resolve করার কাজ এটি করে না। Dependency missing থাকলে installation fail করতে পারে।

১০. APT কেন এত গুরুত্বপূর্ণ?

APT এই জায়গাতেই powerful।

আপনি লিখলেন:

apt install git

APT প্রথমে বুঝবে:

Git-এর কী কী dependency দরকার?

তারপর:

Dependencies খুঁজে বের করবে
        ↓
প্রয়োজনীয় package download করবে
        ↓
Dependencies install করবে
        ↓
শেষে Git install করবে

Conceptually:

             apt install git
                    │
                    ▼
                   APT
                    │
            Check Dependencies
                    │
       ┌────────────┼────────────┐
       ▼            ▼            ▼
     Dep A        Dep B        Dep C
       │            │            │
       └────────────┼────────────┘
                    ▼
                Install Git

এটাই High-Level Package Manager-এর বড় সুবিধা।

১১. APT এবং DPKG-এর সম্পর্ক

এখন পুরো architecture পরিষ্কার করা যাক।

User
 │
 │ apt install git
 ▼
APT
 │
 │ Dependency Resolution
 │ Repository Management
 │ Package Selection
 ▼
DPKG
 │
 │ Unpack / Install
 ▼
Linux Filesystem

অর্থাৎ:

APT high-level management করে, আর DPKG low-level installation operation সম্পন্ন করে।

এই কারণেই সাধারণ user হিসেবে আমরা বেশিরভাগ সময় apt ব্যবহার করি।

১২. বিভিন্ন Linux Distribution-এর Package Manager

সব Linux distribution-এর package management system এক নয়।

Distribution	High-Level	Low-Level	Package Format
Ubuntu / Debian	`apt`, `apt-get`	`dpkg`	`.deb`
Red Hat / CentOS / Fedora	`yum`, `dnf`	`rpm`	`.rpm`
Arch Linux	`pacman`	—	`.pkg.tar.zst`
OpenSUSE	`zypper`	`rpm`	`.rpm`

তাই আপনি Ubuntu ব্যবহার করলে apt শেখা সবচেয়ে গুরুত্বপূর্ণ।

১৩. Package Format কী?

Package manager-এর সঙ্গে package format-এরও সম্পর্ক আছে।

Ubuntu/Debian:

.deb

Red Hat/Fedora:

.rpm

অর্থাৎ:

Ubuntu / Debian
      │
      ▼
    .deb

RedHat / Fedora
      │
      ▼
    .rpm

Ubuntu Debian ecosystem থেকে derived হওয়ায় Debian-এর .deb package format ব্যবহার করে।

১৪. Ubuntu Repository-এর চারটি প্রধান Section

Ubuntu repository-কে কয়েকটি প্রধান section-এ ভাগ করা হয়:

Ubuntu Repository
│
├── Main
├── Restricted
├── Universe
└── Multiverse

Main

Officially maintained free/open-source packages-এর প্রধান অংশ।

Restricted

Proprietary hardware driver বা restricted software-এর মতো components।

Universe

Community-maintained open-source software।

Multiverse

লাইসেন্স বা অন্যান্য সীমাবদ্ধতার কারণে restricted/unofficial nature-এর software।

১৫. APT Repository URL কীভাবে জানে?

APT-কে জানতে হবে:

Package কোথা থেকে download করতে হবে?

Ubuntu system-এ repository configuration সাধারণত থাকে:

/etc/apt/sources.list

অথবা:

/etc/apt/sources.list.d/ubuntu.sources

Conceptually:

APT
 │
 ▼
Repository Configuration
 │
 ▼
Repository URL
 │
 ▼
Remote Ubuntu Repository

তাই:

apt install git

চালালে APT জানে কোন configured repository থেকে package information এবং package files সংগ্রহ করতে হবে।

১৬. Repository-এর `dists` এবং `pool`

Repository-এর internal structure-এ দুটি গুরুত্বপূর্ণ ধারণা হলো:

Repository
│
├── dists/
│
└── pool/

`dists/`

এখানে package index information থাকে।

APT এই index ব্যবহার করে দ্রুত জানতে পারে কোন package available, কোন version আছে ইত্যাদি।

`pool/`

এখানে মূল package archive files থাকে, যেমন .deb package।

সহজভাবে মনে রাখুন:

dists/
  ↓
Package Information

pool/
  ↓
Actual Package Files

১৭. `apt update` আসলে কী করে?

এখানে beginners-দের একটি common confusion হয়।

অনেকে ভাবেন:

apt update

মানে system-এর software update হয়ে যাবে।

আসলে তা নয়।

apt update মূলত repository থেকে latest package index information সংগ্রহ করে local package index update করে।

অর্থাৎ:

Remote Repository
       │
       │ apt update
       ▼
Local Package Index

এটি সাধারণত package install করে না।

১৮. `apt install` কী করে?

এখন package install করি।

apt install curl

APT package-এর information ব্যবহার করে প্রয়োজনীয় package download এবং installation process পরিচালনা করবে।

যদি confirmation চায়:

Do you want to continue? [Y/n]

তাহলে:

দিয়ে installation continue করা যায়।

১৯. Installation সফল হয়েছে কি না কীভাবে বুঝব?

Package install করার পরে সেটি ব্যবহার করে test করা যায়।

যেমন curl install করার পরে:

curl http://ports.ubuntu.com

দিয়ে test করা যায়।

অর্থাৎ workflow:

apt update
     ↓
apt install curl
     ↓
curl ব্যবহার

২০. Package Remove করা

কোনো package আর প্রয়োজন না হলে:

apt remove curl

ব্যবহার করা যায়।

Workflow:

apt install curl

# কাজ শেষ

apt remove curl

২১. `apt clean`

APT package download করার সময় local cache তৈরি করতে পারে।

এই downloaded package cache পরিষ্কার করতে:

apt clean

ব্যবহার করা যায়।

Conceptually:

Package Cache
     │
     │ apt clean
     ▼
Cache Cleaned

২২. `apt upgrade`

এবার ধরুন আপনার system-এ কিছু package already installed আছে।

কিন্তু সেগুলোর নতুন version repository-তে এসেছে।

তখন:

apt upgrade

চালালে installed packages-এর available newer versions upgrade করা যায়।

এখানে সবচেয়ে গুরুত্বপূর্ণ difference:

apt update
     ↓
Package List / Index Update

apt upgrade
     ↓
Installed Packages Upgrade

দুটিকে কখনো একই জিনিস ভাববেন না।

২৩. একটি বাস্তব উদাহরণ: নতুন Ubuntu Machine

ধরুন আপনি একটি নতুন Ubuntu environment চালু করেছেন।

প্রথমে:

apt update

তারপর:

apt install curl

এখন curl install হয়ে গেছে।

Test:

curl http://ports.ubuntu.com

কাজ শেষ হলে:

apt remove curl

Cache পরিষ্কার করতে:

apt clean

এবং installed packages upgrade করতে:

apt upgrade

এই কয়েকটি command দিয়েই Linux package management-এর basic workflow বোঝা যায়।

২৪. পুরো Process একসঙ্গে

এখন পুরো architecture-টি একবার দেখুন:

                  USER
                   │
                   │ apt install git
                   ▼
          ┌─────────────────┐
          │      APT        │
          │ High-Level PM   │
          └────────┬────────┘
                   │
          Repository Search
                   │
                   ▼
          Dependency Resolution
                   │
                   ▼
          Package Download
                   │
                   ▼
          ┌─────────────────┐
          │      DPKG       │
          │ Low-Level PM    │
          └────────┬────────┘
                   │
             Unpack / Install
                   │
                   ▼
          ┌─────────────────┐
          │  Linux System   │
          └─────────────────┘

এটাই Linux package management-এর মূল mental model।

২৫. সবচেয়ে গুরুত্বপূর্ণ Command Cheat Sheet

# Repository package index update
apt update

# Package install
apt install <package>

# Package remove
apt remove <package>

# Downloaded cache clean
apt clean

# Installed packages upgrade
apt upgrade

উদাহরণ:

apt update

apt install git

apt remove git

apt clean

apt upgrade

২৬. পাঁচটি শব্দ মনে রাখুন

পুরো chapter-এর সবচেয়ে গুরুত্বপূর্ণ পাঁচটি concept:

Package

Software-এর packaged bundle।

Repository

যেখানে package সংরক্ষিত থাকে।

Package Manager

Package search, download, install, remove এবং management করে।

APT

Ubuntu/Debian-এর High-Level Package Manager।

DPKG

Ubuntu/Debian-এর Low-Level Package Manager।

২৭. Final Mental Model

শেষবারের মতো পুরো বিষয়টি একটি diagram দিয়ে মনে রাখুন:

              PACKAGE
                 ▲
                 │
          stored inside
                 │
                 │
            REPOSITORY
                 ▲
                 │
       accessed through
                 │
                 │
          PACKAGE MANAGER
                 │
          ┌──────┴──────┐
          │             │
        APT           DPKG
     High-Level     Low-Level
          │             │
          └──────┬──────┘
                 ▼
            LINUX SYSTEM

আর Ubuntu/Debian-এর ক্ষেত্রে:

APT
 │
 ├── Repository handle করে
 ├── Package খুঁজে
 ├── Dependency resolve করে
 ├── Package download করে
 └── DPKG-এর মাধ্যমে low-level installation সম্পন্ন করতে পারে

অন্যদিকে:

DPKG
 │
 ├── .deb package নিয়ে কাজ করে
 ├── Package unpack করে
 └── Low-level installation operation সম্পন্ন করে

তাই Linux Package Management-এর সবচেয়ে গুরুত্বপূর্ণ equation হলো:

Repository
     +
Package Manager
     +
Package
     +
Dependency
     =
Software Installation

আর Ubuntu ব্যবহার করলে practicalভাবে সবচেয়ে গুরুত্বপূর্ণ command হলো:

apt update
apt install <package>
apt remove <package>
apt upgrade

এই চারটি command এবং Package → Repository → APT → DPKG → Linux System flow পরিষ্কারভাবে বুঝে ফেলতে পারলে Linux-এর package management-এর foundation অনেকটাই তৈরি হয়ে যাবে।

Linux-এর ভিতরের Architecture বুঝি: GNU, Coreutils, Shell, Terminal, Kernel ও Desktop Environment

Ragib Hasan — Sat, 29 Aug 2026 06:40:47 +0000

Linux নিয়ে কাজ করতে গেলে আমরা প্রায়ই কয়েকটি নাম বারবার শুনি—Linux Kernel, GNU, GNU Coreutils, GCC, glibc, Bash, Shell, Terminal, GNOME, KDE ইত্যাদি।

কিন্তু সমস্যা হচ্ছে, এগুলো আসলে কে কোথায় থাকে, কার কাজ কী, আর একজন user যখন Terminal-এ ls লিখে তখন সেই command কীভাবে শেষ পর্যন্ত Kernel এবং Hardware-এর কাছে পৌঁছায়—এটা পরিষ্কার না হলে Linux-এর পুরো architecture-টাই অনেকটা অস্পষ্ট থেকে যায়।

এই লেখায় সেই পুরো বিষয়টাকে ধাপে ধাপে বোঝার চেষ্টা করা হবে।

১. Linux আর Linux Distribution-এর পার্থক্য

Linux এবং Linux Distribution একই জিনিস নয়।

Linux মূলত Kernel-এর কথা বোঝায়, আর একটি সম্পূর্ণ Linux Distribution হলো Kernel-এর সঙ্গে আরও অনেক প্রয়োজনীয় component-এর সমন্বয়।

একটি পূর্ণাঙ্গ Linux distribution-এর মধ্যে শুধু Kernel থাকলেই হয় না। এর সঙ্গে বিভিন্ন ধরনের utilities, package manager, system services, desktop environment, tools এবং configuration প্রয়োজন হয়।

একটি conceptual structure:

Linux Distribution
│
├── Linux Kernel
├── GNU Utilities
├── Package Manager
├── System Services
├── Desktop Environment
├── Applications
└── Other Tools

২. GNU আসলে কী?

GNU বুঝতে হলে GNU project-এর ধারণাটি বুঝতে হবে।

GNU-এর পূর্ণরূপ GNU's Not Unix।

GNU project-এর উদ্দেশ্য ছিল Unix-এর মতো একটি free software ecosystem তৈরি করা, যেখানে operating system তৈরির জন্য প্রয়োজনীয় বিভিন্ন component free software হিসেবে পাওয়া যাবে।

GNU-কে শুধু একটি single software হিসেবে দেখলে ভুল হবে।

বরং এটাকে একটি বড় software ecosystem/project হিসেবে দেখা যায়।

Conceptually:

                 GNU Project
                     │
        ┌────────────┼────────────┐
        │            │            │
       GCC          glibc       Coreutils
        │            │            │
     Compiler     C Library     Commands
        │                         │
        └────────────┬────────────┘
                     │
                  Bash
                     │
                User Space

৩. GNU-এর গুরুত্বপূর্ণ component

GNU ecosystem-এর বিভিন্ন গুরুত্বপূর্ণ component-এর মধ্যে রয়েছে:

GCC
glibc
GNU Coreutils
Bash
GDB

GCC

GCC বা GNU Compiler Collection source code compile করার জন্য ব্যবহৃত হয়।

Conceptually:

C Source Code
      │
      ▼
     GCC
      │
      ▼
Executable / Machine Code

glibc

GNU C Library application এবং operating system-এর বিভিন্ন functionality ব্যবহারের জন্য গুরুত্বপূর্ণ library layer।

Conceptually:

C Program
   │
   ▼
glibc
   │
   ▼
System Calls
   │
   ▼
Linux Kernel

৪. GNU Coreutils

এখন আসি এই আলোচনার অন্যতম গুরুত্বপূর্ণ অংশে:

GNU Coreutils

GNU Coreutils হলো অনেকগুলো fundamental command-line utility/program-এর collection।

এর মধ্যে আমরা প্রতিদিনের Linux কাজের সময় বিভিন্ন command ব্যবহার করি:

ls
cp
rm
cat
grep

সহজভাবে:

GNU Coreutils
│
├── ls
├── cp
├── rm
├── cat
└── grep

এখানে একটি গুরুত্বপূর্ণ বিষয় হলো—ls কোনো magical Linux keyword নয়। এটি একটি command-line utility/program।

৫. Terminal আসলে কী?

এখন প্রশ্ন:

আমি command লিখব কোথায়?

উত্তর:

Terminal-এ।

Terminal হচ্ছে এমন একটি user-facing program/interface যেখানে user command লিখতে পারে এবং output দেখতে পারে।

যেমন:

ls

লিখলে Terminal-এ current directory-এর files এবং directories-এর output দেখা যায়।

কিন্তু Terminal নিজে ls command-এর কাজ করে না।

এখানেই Shell-এর প্রয়োজন হয়।

৬. Terminal আর Shell এক জিনিস নয়

এটি Linux শেখার সময় সবচেয়ে common confusion-এর একটি।

Terminal ≠ Shell

Terminal হলো command input/output interface।

অন্যদিকে Shell হলো command interpreter।

Terminal user-এর input গ্রহণ করে, আর Shell সেই command interpret করে এবং প্রয়োজনীয় program execute করার workflow পরিচালনা করে।

সহজভাবে:

Terminal
   │
   ▼
Shell
   │
   ▼
Command / Program

৭. Bash কী?

Bash = Bourne Again SHell

Bash হলো একটি shell program।

যখন তুমি Terminal-এ লিখো:

ls

তখন Bash command-টি interpret করে এবং প্রয়োজনীয় executable program চালানোর workflow পরিচালনা করে।

Conceptually:

Terminal
   │
   │ command
   ▼
 Bash
   │
   │ interpret
   ▼
Command / Program
   │
   ▼
Kernel

Shell-এর কাজ হলো user-এর command এবং system-এর মধ্যে একটি গুরুত্বপূর্ণ interface হিসেবে কাজ করা।

৮. Shell অনেক ধরনের হতে পারে

শুধু Bash-ই একমাত্র shell নয়।

Linux/Unix ecosystem-এ বিভিন্ন shell পাওয়া যায়, যেমন:

sh
ksh
bash
zsh
csh

একটি গুরুত্বপূর্ণ বিষয় হলো:

Shell এবং Terminal একই জিনিস নয়।

একই Terminal application-এর মাধ্যমে বিভিন্ন shell ব্যবহার করা সম্ভব।

৯. `ls` দিলে আসলে কী হয়?

এখন পুরো architecture-এর সবচেয়ে গুরুত্বপূর্ণ অংশে আসি।

ধরো তুমি Terminal খুলে লিখলে:

ls

আমাদের চোখে মনে হয়:

User → ls → Output

কিন্তু ভিতরে আরও কয়েকটি layer কাজ করছে।

Conceptually:

User
  │
  ▼
Terminal
  │
  ▼
Shell
  │
  ▼
ls
  │
  ▼
Linux Kernel
  │
  ▼
File System / Storage
  │
  ▼
Kernel
  │
  ▼
ls
  │
  ▼
Shell
  │
  ▼
Terminal
  │
  ▼
User

এটাই Linux command-line architecture বোঝার সবচেয়ে গুরুত্বপূর্ণ mental model।

১০. `ls` command-এর complete journey

ধাপে ধাপে দেখি।

Step 1 — User

User keyboard থেকে লিখল:

ls

Step 2 — Terminal

Terminal input গ্রহণ করল।

Step 3 — Shell

Command shell-এর কাছে গেল।

Step 4 — Shell interpretation

Shell বুঝল এটি ls command।

Step 5 — `ls` program

ls executable program চালু হলো।

Step 6 — Kernel interaction

ls প্রয়োজনীয় system functionality ব্যবহারের জন্য Kernel-এর সঙ্গে interact করে।

Step 7 — File System / Storage

Kernel filesystem/storage থেকে প্রয়োজনীয় information সংগ্রহ করে।

Step 8 — Result

Result আবার ফিরে আসে:

Kernel
 ↓
ls
 ↓
Shell
 ↓
Terminal
 ↓
User

শেষে Terminal screen-এ files এবং directories-এর list দেখা যায়।

১১. Kernel কী করে?

এখন প্রশ্ন:

Kernel কেন দরকার?

Computer-এর Hardware-এর মধ্যে রয়েছে:

CPU
RAM
SSD/HDD
Network devices
Keyboard
Mouse
Display

এই Hardware resources সরাসরি সাধারণ user application পরিচালনা করে না।

এখানে Linux Kernel গুরুত্বপূর্ণ ভূমিকা পালন করে।

Conceptually:

USER
 │
 ▼
User-space Software
 │
 ▼
Linux Kernel
 │
 ▼
Hardware

Kernel system-এর resources এবং hardware-এর সঙ্গে কাজ করে।

১২. User Space এবং Kernel Space

Linux architecture বোঝার জন্য User Space এবং Kernel Space-এর distinction গুরুত্বপূর্ণ।

┌──────────────────────────────┐
│          USER SPACE          │
│                              │
│ Applications                 │
│ Terminal                     │
│ Shell                        │
│ GNU Coreutils                │
│ Libraries                    │
│ Other Utilities              │
│                              │
├──────────────────────────────┤
│         KERNEL SPACE         │
│                              │
│ Linux Kernel                 │
│ Process Management           │
│ Memory Management            │
│ File Systems                 │
│ Device Management            │
│                              │
├──────────────────────────────┤
│           HARDWARE           │
│                              │
│ CPU │ RAM │ Storage │ Devices│
└──────────────────────────────┘

User-space-এর program প্রয়োজন অনুযায়ী Kernel-এর services ব্যবহার করে।

১৩. Desktop Environment কেন দরকার?

এখন আরেকটি গুরুত্বপূর্ণ প্রশ্ন:

Terminal কোথা থেকে পেলাম?

Operating system install করার পর আমরা যে graphical desktop দেখি—windows, menus, file manager, panels, graphical applications ইত্যাদি—এসবের বড় অংশ Desktop Environment-এর মাধ্যমে পাওয়া যায়।

একটি Desktop Environment-এর মধ্যে থাকতে পারে:

GUI
Window Management
File Manager
Terminal
Panels
Menus
Desktop tools

১৪. GNOME এবং KDE Plasma

Linux ecosystem-এ একাধিক Desktop Environment ব্যবহার করা যায়।

দুটি পরিচিত উদাহরণ:

GNOME

GNOME
├── GNOME Terminal
├── File Manager
├── GUI
└── Window Management

KDE Plasma

KDE Plasma
├── Konsole
├── File Manager
├── GUI
└── Window Management

অর্থাৎ:

Desktop Environment
        │
   ┌────┴────┐
   ▼         ▼
 GNOME    KDE Plasma
   │         │
Terminal   Konsole

এখানে Desktop Environment পরিবর্তন করলেও underlying Linux Kernel একই থাকতে পারে।

১৫. পুরো Linux Architecture একসঙ্গে

এখন সবগুলো concept এক জায়গায় রাখলে:

                         USER
                           │
                           ▼
              ┌──────────────────────┐
              │  DESKTOP ENVIRONMENT │
              │   GNOME / KDE        │
              └──────────┬───────────┘
                         │
                         ▼
              ┌──────────────────────┐
              │       TERMINAL       │
              │ GNOME Terminal       │
              │ Konsole              │
              └──────────┬───────────┘
                         │
                         ▼
              ┌──────────────────────┐
              │        SHELL         │
              │   Bash / Zsh / sh    │
              └──────────┬───────────┘
                         │
                         ▼
              ┌──────────────────────┐
              │    GNU COREUTILS     │
              │ ls / cp / rm / cat   │
              └──────────┬───────────┘
                         │
                         ▼
              ┌──────────────────────┐
              │     LINUX KERNEL     │
              │ Process / Memory /   │
              │ Filesystem / Devices │
              └──────────┬───────────┘
                         │
                         ▼
              ┌──────────────────────┐
              │       HARDWARE       │
              │ CPU / RAM / Storage  │
              └──────────────────────┘

সবচেয়ে গুরুত্বপূর্ণ mental model:

User
 ↓
Terminal
 ↓
Shell
 ↓
Utility
 ↓
Kernel
 ↓
Hardware / Storage
 ↓
Result

১৬. Final Takeaway

Linux-এর command line বাইরে থেকে খুব simple মনে হয়।

তুমি শুধু লিখছো:

ls

কিন্তু এর পিছনে কাজ করছে একাধিক software layer:

User
 ↓
Terminal
 ↓
Shell
 ↓
GNU Utility
 ↓
Kernel
 ↓
Hardware / File System
 ↓
Result

আর Linux distribution-এর বড় picture:

Linux Distribution
│
├── Linux Kernel
├── GNU / User-space Tools
├── Libraries
├── Package Manager
├── System Services
├── Desktop Environment
└── Applications

এই relationship-গুলো পরিষ্কারভাবে বুঝে ফেলতে পারলে Linux command line, filesystem, processes এবং পরবর্তী Docker-related concepts শেখার foundation অনেক শক্ত হয়ে যায়।

ডকার শেখার আগে লিনাক্স বেসিকস: লিনাক্স কি আসলেই একটি অপারেটিং সিস্টেম? 🐧

Ragib Hasan — Fri, 28 Aug 2026 12:11:54 +0000

ডকার (Docker) ইকোসিস্টেম নিয়ে কাজ করতে গেলে একটি বিষয় খুব দ্রুত পরিষ্কার হয়ে যায়— ডকার ইঞ্জিন মূলত লিনাক্স অপারেটিং সিস্টেমের উপর রান করে। যদি আপনার হোস্ট ওএস (Host OS) উইন্ডোজ বা ম্যাক হয়, তবে ডকার ডেস্কটপ ব্যাকএন্ডে একটি ভার্চুয়াল মেশিন বা লিনাক্স কার্নেল তৈরি করে তার উপর রান হয়।

এর মানে হলো, ডকারকে খুব ভালোভাবে বুঝতে হলে এর পেছনের ফাউন্ডেশন অর্থাৎ লিনাক্স (Linux) সম্পর্কে ক্লিয়ার ধারণা থাকা জরুরি। বিল্ডিংয়ের ফাউন্ডেশন যেমন মজবুত হওয়া দরকার, ডকার বা ডেভপস (DevOps) জার্নিতে লিনাক্স কার্নেলের আর্কিটেকচার বোঝাও ঠিক তেমনই গুরুত্বপূর্ণ।

লিনাক্স (Linux) কি একটি অপারেটিং সিস্টেম?

আমরা কথায় কথায় বলি "লিনাক্স অপারেটিং সিস্টেম", কিন্তু সত্যি বলতে লিনাক্স কখনোই কোনো অপারেটিং সিস্টেম ছিল না!

লিনাক্স হচ্ছে মূলত একটি কার্নেল (Kernel)। ১৯৯১ সালে 'লিনাস টরভল্ডস' (Linus Torvalds) নামক একজন কম্পিউটার সায়েন্টিস্ট এই কার্নেলটির কোড লেখেন এবং পরবর্তীতে এটিকে ওপেন-সোর্স করে দেন।

যেহেতু লিনাক্স শুধু একটি কার্নেল, তাই এটিকে ব্যবহার উপযোগী অপারেটিং সিস্টেমে রূপান্তর করতে আরও অনেক কিছুর প্রয়োজন হয়। আর তখনই আসে লিনাক্স ডিস্ট্রিবিউশন (Linux Distribution) বা সংক্ষেপে ডিস্ট্রো (Distro) এর ধারণা।

লিনাক্স ডিস্ট্রিবিউশন (Linux Distro) কী?

একটি সম্পূর্ণ বা কমপ্লিট অপারেটিং সিস্টেম তৈরি করতে একটি কোর কার্নেলের সাথে আরও বেশ কিছু কম্পোনেন্ট যুক্ত করতে হয়। একটি কমপ্লিট লিনাক্স ডিস্ট্রিবিউশনে সাধারণত নিচের ৬টি জিনিস থাকে:

Linux Kernel: সিস্টেমের কোর বা হার্ট।
GNU Utilities: সিস্টেমের ব্যাসিক কমান্ড ও টুলস।
Package Manager: সফটওয়্যার ইনস্টল, আপডেট বা ডিলিট করার মাধ্যম (যেমন: apt, yum)।
Init System: সিস্টেম বুট হওয়ার পর প্রসেস ম্যানেজ করার সিস্টেম।
Desktop Environment: গ্রাফিক্যাল ইউজার ইন্টারফেস (GUI)।
Other Tools & Configurations: অন্যান্য প্রয়োজনীয় টুলস এবং কনফিগারেশন ফাইল।

এই সবগুলো কম্পোনেন্ট যখন লিনাক্স কার্নেলের সাথে যুক্ত হয়, তখনই আমরা উবুন্টু (Ubuntu), ফেডোরা (Fedora) বা কালি লিনাক্সের (Kali Linux) মতো একটি কমপ্লিট অপারেটিং সিস্টেম বা ডিস্ট্রিবিউশন পাই।

নিচের ডায়াগ্রামটি দেখলে লিনাক্স ডিস্ট্রিবিউশনের আর্কিটেকচার আরও ক্লিয়ার হবে:

Base System এবং Derived System

লিনাক্সের দুনিয়ায় অনেক ডিস্ট্রিবিউশন রয়েছে। এতগুলো ডিস্ট্রো কীভাবে এলো? এর পেছনে রয়েছে Base এবং Derived সিস্টেমের কনসেপ্ট।

বেস সিস্টেম (Base System):
যেসব অপারেটিং সিস্টেম একদম স্ক্র্যাচ থেকে কোর কার্নেল ও অন্যান্য কম্পোনেন্ট দিয়ে তৈরি করা হয়, সেগুলো হলো বেস সিস্টেম। যেমন:

Debian (ডেবিয়ান ফ্যামিলি)
Red Hat (রেড হ্যাট ফ্যামিলি)
Alpine (অ্যালপাইন ফ্যামিলি)
Arch Linux

ডিরাইভড সিস্টেম (Derived System):
যখন একটি স্টেবল বেস সিস্টেমকে ভিত্তি করে নতুন কোনো অপারেটিং সিস্টেম বানানো হয়, তখন তাকে ডিরাইভড সিস্টেম বলে।

যেমন, Debian হলো একটি বেস সিস্টেম। এই ডেবিয়ানের প্যাকেজ ম্যানেজার ও ইউটিলিটি ব্যবহার করে এবং নতুন ডেস্কটপ এনভায়রনমেন্ট ও কনফিগারেশন যোগ করে তৈরি করা হয়েছে Ubuntu।
আবার Ubuntu-কে বেস করে তৈরি করা হয়েছে Linux Mint, Pop!_OS, Zorin OS ইত্যাদি।

এ কারণেই যারা উবুন্টু ব্যবহার করেন, তারা সফটওয়্যার ইনস্টলের জন্য apt বা apt-get প্যাকেজ ম্যানেজার ব্যবহার করেন, যা মূলত ডেবিয়ানের। অন্যদিকে Red Hat ফ্যামিলির ডিস্ট্রোগুলোতে (যেমন: CentOS, Fedora) yum বা rpm কাজ করে। আবার Alpine লিনাক্সে কাজ করে apk এবং Arch লিনাক্সে pacman।

শেষ কথা

লিনাক্সের এই বিষয়গুলো (যেমন: প্যাকেজ ম্যানেজার কী, ইনভায়রনমেন্ট কীভাবে কাজ করে) গভীরভাবে বুঝতে পারলে ডকার শেখা পানির মতো সহজ হয়ে যাবে। ডকারফাইল (Dockerfile) লেখা বা কন্টেইনার ইমেজ তৈরি করার সময় লিনাক্সের এই বেসিক জ্ঞানগুলোই আপনাকে ম্যাজিকের মতো সাহায্য করবে!

ডকার ইকোসিস্টেম (Docker Ecosystem): ডকার আসলে কী এবং কীভাবে এর অভ্যন্তরীণ চেইন কাজ করে?

Ragib Hasan — Tue, 25 Aug 2026 16:52:27 +0000

অনেকেই মনে করেন ডকার (Docker) সাধারণ একটি টুল, সফটওয়্যার বা ছোটখাটো কোনো অ্যাপ্লিকেশন। কিন্তু আপনি যদি ডকারের গভীরে গিয়ে বুঝতে চান, তবে প্রথমেই এই ভুল ধারণাটি মাথা থেকে ঝেড়ে ফেলতে হবে। ডকার কোনো একক টুল বা সফটওয়্যার নয়—ডকার হচ্ছে একটি পূর্ণাঙ্গ প্ল্যাটফর্ম (Platform) বা ইকোসিস্টেম (Ecosystem)।

আজকের ব্লগে আমরা সহজ বাংলা ভাষায় বিস্তারিত জানব ডকার ইকোসিস্টেম কী, এর ভেতরের প্রতিটি কম্পোনেন্ট কীভাবে একে অপরের সাথে চেইনের মতো যুক্ত হয়ে কাজ করে এবং টার্মিনালে যখন আমরা docker run hello-world লিখি, তখন ঠিক কী কী ঘটে।

১. ইকোসিস্টেম (Ecosystem) বা প্ল্যাটফর্ম কী?

সহজ কথায়, যখন একাধিক উপাদান বা সত্তা একে অপরের ওপর নির্ভর করে একটি অবিচ্ছেদ্য চেইন বা শৃঙ্খল তৈরি করে কাজ করে, তখন তাকে ইকোসিস্টেম বলে।

প্রকৃতির খাদ্যশৃঙ্খলের (Food Chain) একটি চমৎকার উদাহরণ দেওয়া যাক:

কেঁচো → কেঁচো খায় হাঁস → হাঁসকে খায় সাপ → সাপকে খায় বেজি → বেজিকে খায় ইগল → ইগলকে আবার শিকার করে মানুষ।

এখানে প্রত্যেকে প্রত্যেকের সাথে একটি চেইনে যুক্ত। টেকনোলজির দুনিয়াতেও যখন অনেকগুলো স্বতন্ত্র কম্পোনেন্ট (টুলস, ইঞ্জিন, ডেটাবেজ, ভার্চুয়াল মেশিন) একসাথে একটি চেইনের মাধ্যমে সম্পূর্ণ পরিবেশ গড়ে তোলে, তখন টেকনিক্যাল ভাষায় তাকে আমরা বলি প্ল্যাটফর্ম বা ইকোসিস্টেম।

২. ডকার প্ল্যাটফর্মের মূল কম্পোনেন্টসমূহ

ডকার ইকোসিস্টেম মূলত নিচের প্রধান কম্পোনেন্টগুলোর সমন্বয়ে গঠিত:

Docker Client (CLI): এটি ডকারের ক্লায়েন্ট বা কমান্ড লাইন ইন্টারফেস। ব্যবহারকারী হিসেবে আমরা টার্মিনালে যেসব ডকার কমান্ড (যেমন: docker run, docker build, docker pull) লিখি, ডকার ক্লায়েন্ট সেই কমান্ডগুলো গ্রহণ করে।
Docker Engine (ডকার ইঞ্জিন): ডকারের মূল চালিকাশক্তি। এর ভেতরে থাকে ব্যাকগ্রাউন্ড সার্ভিস dockerd (Docker Daemon) এবং কন্টেইনার রানটাইম (containerd, runc)।
Docker Desktop (ডকার ডেস্কটপ): ম্যাক (macOS) বা উইন্ডোজ (Windows) ব্যবহারকারীদের জন্য ডকার ডেস্কটপ একটি লাইটওয়েট লিনাক্স ভার্চুয়াল মেশিন (Linux VM) তৈরি করে দেয়, যাতে লিনাক্স কার্নেল ব্যবহারের মাধ্যমে ডকার ইঞ্জিন কাজ করতে পারে।
Docker Image (ডকার ইমেজ): একটি কন্টেইনারের ব্লুপ্রিন্ট বা স্ন্যাপশট। ইমেজ থেকেই কন্টেইনার তৈরি করা যায়, আবার কন্টেইনার থেকে নতুন ইমেজ তৈরি করা সম্ভব।
Docker Hub (ডকার হাব): এটি ডকারের একটি কেন্দ্রীয় ক্লাউড রেজিস্ট্রি বা ডেটাবেজ। এখানে বিশ্বজুড়ে তৈরি হওয়া সব ধরনের ইমেজ (যেমন: Ubuntu, Python, Golang, Redis, PostgreSQL, Hello-World) সংরক্ষিত থাকে।
Docker Compose (ডকার কম্পোজ): একাধিক কন্টেইনারবিশিষ্ট জটিল অ্যাপ্লিকেশন সহজে কনফিগার ও রান করার টুল।

৩. ডকার ইকোসিস্টেম আর্কিটেকচার ডায়াগ্রাম

নিচে ডকার ইকোসিস্টেমের অভ্যন্তরীণ প্রবাহ ও উপাদানগুলোর সংযোগ দেখানো হলো:

৪. `docker run hello-world` দিলে ভেতরে কী ঘটে? (Step-by-Step Flow)

ডকার ইকোসিস্টেমের চেইন কীভাবে ধাপে ধাপে কাজ করে, তা একটি প্র্যাকটিক্যাল কমান্ডের মাধ্যমে বোঝা যাক:

docker run hello-world

যখনই আপনি এই কমান্ডটি টার্মিনালে রান করবেন, ব্যাকগ্রাউন্ডে নিচের চেইনটি বাস্তবায়িত হয়:

[User / Terminal]
       │
       ▼ (Command: docker run hello-world)
[Docker Client / CLI]
       │
       ▼ (REST API Request)
[Docker Daemon: dockerd]
       │
       ▼
[Container Runtime: containerd]
       ├───► (Local Cache Check: ইমেজটি কি লোকালি আছে?)
       │           │
       │           ├─► [নাই] ──► [Docker Hub] (Pull Image -> Cache locally)
       │           └─► [আছে] ──► (সরাসরি ইমেজ ব্যবহার করো)
       │
       ▼
[Low-Level Runtime: runc]
       │
       ▼ (Kernel Features: Namespaces & Cgroups)
[Linux Kernel]
       │
       ▼ (Creates isolated process)
[Running Container: Hello-World]
       │
       ▼ (Response Flow back: Kernel -> runc -> containerd -> dockerd -> Docker CLI)
[Terminal Output: "Hello from Docker!"]

বিস্তারিত ধাপসমূহ:

কমান্ড গ্রহণ: Docker CLI কমান্ডটি গ্রহণ করে REST API রিকোয়েস্টের মাধ্যমে ডকার ইঞ্জিনের ব্যাকগ্রাউন্ড ডেমন dockerd-এর কাছে পাঠায়।
কন্টেইনার ডেমনের কাজ: dockerd সার্বক্ষণিক রিকোয়েস্ট হ্যান্ডেল করে এবং কমান্ডটি হাই-লেভেল কন্টেইনার রানটাইম containerd-এর কাছে হস্তান্তর করে।
লোকাল ক্যাশ যাচাই: containerd চেক করে তার লোকাল স্টোরেজে বা ক্যাশে hello-world ইমেজটি সংরক্ষিত আছে কি না।
ডকার হাব থেকে পুল করা (যদি লোকালি না থাকে):
- প্রথমবার রান করার সময় লোকাল ক্যাশে ইমেজটি থাকে না। তাই টার্মিনালে মেসেজ আসে: Unable to find image 'hello-world:latest' locally।
- তখন containerd ডকার হাবে (Docker Hub) রিকোয়েস্ট পাঠিয়ে ইমেজটি ডাউনলোড (Pull) করে এবং লোকাল মেশিনে ক্যাশ/স্টোর করে রাখে।
লো-লেভেল রানটাইম ও কার্নেল কমিউনিকেশন:
- containerd তখন লো-লেভেল কন্টেইনার রানটাইম runc-কে বলে কন্টেইনার তৈরি করতে।
- runc সরাসরি অপারেটিং সিস্টেমের Linux Kernel-এর সাথে কথা বলে:
  - Namespaces: কন্টেইনারের জন্য সম্পূর্ণ পৃথক ও আইসোলেটেড একটি পরিবেশ তৈরি করে।
  - Cgroups (Control Groups): কন্টেইনারটি সর্বোচ্চ কতটুকু CPU, RAM বা ডিস্ক ব্যবহার করতে পারবে তার লিমিট নির্ধারণ করে দেয়।
প্রসেস এক্সিকিউশন ও রেসপন্স ব্যাক:
- কার্নেলের ভেতর একটি আইসোলেটেড প্রসেস চালু হয় এবং hello-world প্রোগ্রামটি রান করে।
- আউটপুট তৈরি হলে তা নিচ থেকে ওপরে চেইনের মাধ্যমে ফিরে যায়: Kernel $\rightarrow$ runc $\rightarrow$ containerd $\rightarrow$ dockerd $\rightarrow$ Docker CLI।
- পরিশেষে Docker CLI আমাদের টার্মিনালে সুন্দর মেসেজ প্রিন্ট করে দেখায়: > "Hello from Docker! This message shows that your installation appears to be working correctly."

৫. দ্বিতীয়বার একই কমান্ড রান করলে কী হয়?

আপনি যখন দ্বিতীয়বার পুনরায় docker run hello-world কমান্ডটি রান করবেন:

containerd লোকাল ক্যাশে দেখবে যে hello-world ইমেজটি ইতিমধ্যে স্টোর করা আছে।
ফলে এটি আর ডকার হাবে যাবে না এবং Unable to find image... মেসেজটিও আর আসবে না।
লোকাল ইমেজ থেকেই সরাসরি runc ও কার্নেলের মাধ্যমে এক পলকে নতুন একটি কন্টেইনার তৈরি হয়ে মুহূর্তেই আউটপুট চলে আসবে।

৬. ম্যাক বা উইন্ডোজে লিনাক্স কার্নেল কীভাবে আসে?

কন্টেইনার প্রযুক্তির মূল চাবিকাঠি হলো লিনাক্স কার্নেলের ফিচার (Namespaces এবং Control Groups)। ম্যাক (macOS) বা উইন্ডোজ (Windows) এ যেহেতু নিজস্ব লিনাক্স কার্নেল থাকে না, তাই Docker Desktop ব্যাকগ্রাউন্ডে একটি লাইটওয়েট লিনাক্স ভার্চুয়াল মেশিন (Linux VM) চালায়। এই ভিএম-এর লিনাক্স কার্নেলের সাথেই ডকার ইঞ্জিন যুক্ত হয়ে পুরো ইকোসিস্টেমের কার্যকারিতা বজায় রাখে।

এক নজরে মূল পয়েন্টগুলো:

ডকার কী? ডকার কোনো সাধারণ সফটওয়্যার বা টুল নয়; এটি একটি প্ল্যাটফর্ম / ইকোসিস্টেম।
চেইন কাঠামো: Docker CLI → dockerd → containerd → Docker Hub / Local Cache → runc → Linux Kernel (Namespace & Cgroups) → Container।

DEV Community: Ragib Hasan

ডকারফাইল বিল্ডের ভেতরের জাদু: ইন্টারমিডিয়েট লেয়ার ও ক্যাশিং মেকানিজম (Building Magic Behind Dockerfile)

১. ডকার বিল্ডের অভ্যন্তরীণ জীবনচক্র (Internal Execution Lifecycle)

২. ডকারফাইলের প্রতিটি লাইনের লেয়ার আর্কিটেকচার

লেয়ারভিত্তিক বিস্তারিত বিশ্লেষণ:

৩. ডকার লেয়ার ক্যাশিংয়ের ম্যাজিক (Docker Layer Caching)

ক্যাশ ইনভ্যালিডেশনের মূল নীতি:

৪. প্রোডাকশন ডকারফাইল অপ্টিমাইজেশন স্ট্র্যাটেজি

বেস্ট প্র্যাকটিস:

সংক্ষেপ চিত্র (Cheat Sheet)

ডকারফাইলে WORKDIR-এর গভীর বিশ্লেষণ (WORKDIR Deep Dive)

১. ডিফল্ট আচরণ: WORKDIR ছাড়া কী ঘটে?

২. কেস স্টাডি ১: WORKDIR ছাড়া ডকারফাইল কনফিগারেশন

এর সীমাবদ্ধতাসমূহ:

৩. কেস স্টাডি ২: WORKDIR দিয়ে আদর্শ ডকারফাইল কনফিগারেশন

৪. WORKDIR ব্যবহারের মূল সুবিধাসমূহ

৫. হ্যান্ডস-অন প্র্যাকটিস: বিল্ড, রান ও ভেরিফিকেশন

১. ইমেজ বিল্ড করা

২. কন্টেইনার রান করা

৩. কন্টেইনারে প্রবেশ ও পাথ যাচাই

ডকারফাইল কমান্ড সারসংক্ষেপ

Dockerfile CMD Explained: Build-Time vs Runtime and How CMD Override Works

CMD

1. The Problem: Why Does the Container Exit?

2. What Does CMD Actually Do?

3. Our Complete Dockerfile

4. The Most Important Concept: RUN vs CMD

RUN

CMD

5. What Happens During docker build?

6. Then What Happens During docker run?

7. Understanding the Exec Form

8. A Critical Mental Model

RUN

CMD

9. CMD Does NOT Run During Build

10. The Magic of Default Commands

11. But What If I Want Another Command?

12. CMD Override: A Practical Example

13. CMD Override মানে Image পরিবর্তন নয়

14. Hands-On: Build the New Image

15. Run Without -it

16. Verify the Running Container

17. docker run বনাম docker exec

docker run

docker exec

18. Complete Lifecycle

19. RUN vs CMD: Final Comparison

20. The Three Most Important Commands

Build

Normal Run

Debug / Override

21. The Most Important Mental Model

22. Why This Matters Beyond This Example

23. One Last Look at Our Go Server

Final Takeaway

docker build

docker run

Dockerfile CMD Explained: Build-Time vs Runtime and How CMD Override Works

CMD

1. The Problem: Why Does the Container Exit?

2. What Does CMD Actually Do?

3. Our Complete Dockerfile

4. The Most Important Concept: RUN vs CMD

RUN

CMD

5. What Happens During docker build?

6. Then What Happens During docker run?

7. Understanding the Exec Form

8. A Critical Mental Model

RUN

CMD

9. CMD Does NOT Run During Build

10. The Magic of Default Commands

11. But What If I Want Another Command?

12. CMD Override: A Practical Example

13. CMD Override মানে Image পরিবর্তন নয়

14. Hands-On: Build the New Image

15. Run Without -it

16. Verify the Running Container

২. কেস স্টাডি ১: `WORKDIR` ছাড়া ডকারফাইল কনফিগারেশন

৩. কেস স্টাডি ২: `WORKDIR` দিয়ে আদর্শ ডকারফাইল কনফিগারেশন

৪. `WORKDIR` ব্যবহারের মূল সুবিধাসমূহ

`CMD`

2. What Does `CMD` Actually Do?

4. The Most Important Concept: `RUN` vs `CMD`

`RUN`

`CMD`

5. What Happens During `docker build`?

6. Then What Happens During `docker run`?

`RUN`

`CMD`

9. `CMD` Does NOT Run During Build

15. Run Without `-it`

17. `docker run` বনাম `docker exec`

`docker run`

`docker exec`

19. `RUN` vs `CMD`: Final Comparison

`docker build`

`docker run`

`CMD`

2. What Does `CMD` Actually Do?

4. The Most Important Concept: `RUN` vs `CMD`

`RUN`

`CMD`

5. What Happens During `docker build`?

6. Then What Happens During `docker run`?

`RUN`

`CMD`

9. `CMD` Does NOT Run During Build

15. Run Without `-it`

17. `docker run` বনাম `docker exec`

`docker run`

`docker exec`

19. `RUN` vs `CMD`: Final Comparison

`docker build`

`docker run`

5. Move `server.go` into the Container

8. `docker commit`: Take a Snapshot

9. The Problem with `docker commit`

`FROM`

`RUN`

12. `WORKDIR`: A Better Way to Handle `/app`

13. `COPY`: Bring the Application into the Image

16. What Happens During `docker build`?

`server.go`

`Dockerfile`

`docker run`

`ubuntu:24.04`

`bash`

`-it`

5. `-it` আসলে কী?

`-i` → Interactive / STDIN

`-t` → Pseudo-TTY