DEV Community: Ragib Hasan

Mental Health Score Prediction Project — সম্পূর্ণ Bangla Explanation

Ragib Hasan — Sun, 20 Sep 2026 08:02:19 +0000

এই guide-টি তোমার দেওয়া video transcript এবং Mental-Health-Score-main project-এর notebook, FastAPI backend, frontend JavaScript এবং deployment flow দেখে তৈরি করা হয়েছে। লক্ষ্য হলো তুমি যেন শুধু code copy না করো, বরং প্রতিটি step কেন করা হচ্ছে, কোন concept কোথায় লাগছে, input থেকে prediction পর্যন্ত data কীভাবে যাচ্ছে—সব পরিষ্কারভাবে বুঝতে পারো।

সূচিপত্র

Project Overview
End-to-End Architecture
Problem Statement ও Regression
Dataset বোঝা
Libraries
Data Loading ও Initial Inspection
Missing Value, Duplicate, Data Types
Descriptive Statistics ও Invalid Value
EDA — কেন এবং কীভাবে
Target Distribution
Correlation Heatmap
Stress vs Mental Health
Social Media Usage vs Mental Health
Sleep vs Mental Health
Platform Count Plot
Outlier ও IQR
Data Cleaning
Skewness
Feature Engineering
Country Grouping / High Cardinality
Encoding Strategy
Train-Test Split ও Data Leakage
Pipeline এবং ColumnTransformer
Preprocessing Pipelines
Linear Regression
Random Forest
Overfitting / Underfitting
Hyperparameter Tuning
RandomizedSearchCV ও Cross Validation
Model Evaluation — R², MAE, RMSE
Actual Project Results
Model Saving with Joblib
FastAPI Backend
Pydantic Validation
/predict Endpoint
Frontend — HTML/CSS/JavaScript
Frontend Validation ও API Call
Result Gauge ও UI State
CORS
Deployment on Render
Complete Request Flow
Important Project Mismatches / Bugs / Improvements
Viva / Interview Questions
Final Mental Model

1. Project Overview

এই project-এর মূল কাজ হলো একজন student-এর social media habit, study habit, sleep, physical activity, stress level এবং কিছু demographic information ব্যবহার করে একটি numerical Mental Health Score predict করা।

সহজভাবে:

Student-এর তথ্য
      ↓
Machine Learning Model
      ↓
Mental Health Score

উদাহরণ:

Age                  = 23
Gender               = Female
Country              = Bangladesh
Academic Level       = Undergraduate
Most Used Platform   = Instagram
Purpose              = Entertainment
Daily Usage          = 6.5 hours
Daily Unlocks        = 90
Study Hours          = 4
Physical Activity    = 1 hour
Sleep                = 6 hours
Stress               = High

Model output দিতে পারে:

Predicted Mental Health Score = 5.82 / 10

এখানে 5.82 শুধু একটি numerical prediction। এটি কোনো clinical diagnosis নয়।

2. কেন এই project শুধু “ML notebook project” না

ভিডিওতে শুরুতেই emphasize করা হয়েছে যে এটা শুধু Jupyter Notebook-এ model train করার project না। এখানে পুরো end-to-end workflow আছে:

Dataset
  ↓
EDA + Cleaning
  ↓
Feature Engineering
  ↓
Preprocessing
  ↓
Machine Learning
  ↓
Model Evaluation
  ↓
Model Save (.pkl)
  ↓
FastAPI Backend
  ↓
Pydantic Validation
  ↓
HTML + CSS + JavaScript Frontend
  ↓
Deployment

অর্থাৎ তুমি এক project-এ Data Science + Machine Learning + Backend + Frontend + Deployment—সবকিছুর সংযোগ দেখছ।

3. Problem Statement — Regression কেন?

Project-এর target column:

Mental_Health_Score

এটি category নয়; এটি একটি continuous numerical value।

উদাহরণ:

3.8
5.4
7.2
8.9

তাই এটি Regression Problem।

Classification হলে কেমন হতো?

যদি target হতো:

Healthy / Unhealthy

অথবা:

Low / Medium / High Risk

তাহলে problem classification হতো।

Regression-এর সাধারণ algorithm

ভিডিওতে basic হিসেবে বলা হয়েছে:

Linear Regression
KNN Regressor
Decision Tree Regressor
Random Forest Regressor

এই project-এ মূল comparison:

Linear Regression
Random Forest
Tuned Random Forest

4. Dataset

Dataset file:

Student Social Media And Mental Health Impact.csv

Notebook অনুযায়ী dataset-এর shape:

5000 rows × 13 columns

অর্থাৎ 5000 student এবং 13টি columns।

Target বাদ দিলে 12টি input feature-এর ধারণা পাওয়া যায়।

প্রধান columns:

Age
Gender
Country
Academic_Level
Most_Used_Platform
Purpose_Of_Use
Avg_Daily_Usage_Hours
Daily_Unlocks
Study_Hours
Physical_Activity_Hours
Sleep_Hours_Per_Night
Stress_Level
Mental_Health_Score

Input vs Target

Input Features (X)
        ↓
Machine Learning Algorithm
        ↓
Target (y)

এখানে:

X = student information

y = Mental_Health_Score

5. Libraries Import

Notebook শুরু হয় data manipulation ও visualization libraries দিয়ে:

import numpy as np
import pandas as pd
import matplotlib.pyplot as plt
import seaborn as sns

NumPy

Numerical operation-এর জন্য। যেমন:

np.log1p()
np.sqrt()

Pandas

Tabular data নিয়ে কাজ করার জন্য:

pd.read_csv()
df.head()
df.info()
df.describe()

Matplotlib

Graph/plot তৈরির foundation library।

Seaborn

Statistical visualization সহজ ও সুন্দরভাবে করতে ব্যবহৃত হয়:

sns.histplot()
sns.heatmap()
sns.boxplot()
sns.scatterplot()
sns.countplot()

ভিডিওতে একটি ভালো practice বলা হয়েছে: সব library শুরুতে randomly import না করে প্রয়োজন অনুযায়ী import করা যায়। তবে grouped imports readability বাড়ায়।

6. Dataset Load

df = pd.read_csv('Student Social Media And Mental Health Impact.csv')

এই line-এর মানে:

CSV File
   ↓
pandas read_csv
   ↓
DataFrame
   ↓
df variable

এখন df-এর মধ্যে পুরো dataset আছে।

7. Shape Check

df.shape

Output:

(5000, 13)

মানে:

5000 rows
13 columns

এটি dataset understand করার প্রথম basic step।

8. First 5 Rows

df.head()

head() default 5 rows দেখায়।

কেন দরকার?

Column name ঠিক আছে কি না
Data কেমন format-এ আছে
String/numeric mix আছে কি না
Weird value চোখে পড়ে কি না
Target কোথায় আছে

উদাহরণ:

Age Gender Country ... Stress_Level Mental_Health_Score
22  Female India  ... Medium        7.2
24  Male   USA    ... High          5.9

9. Missing Values

df.isnull().sum()

এটি প্রতিটি column-এ কতটি null/missing value আছে দেখায়।

উদাহরণ:

Age                   0
Gender                0
Sleep_Hours           5
Stress_Level          2

Project dataset মোটামুটি clean।

Real-world data-তে কী হতে পারে?

Age = NaN
Sleep = NaN
Country = empty

তখন imputation দরকার হতে পারে।

Numeric missing value example

Age missing → median age দিয়ে fill

Categorical missing value example

Country missing → "Unknown" বা most frequent category

ভিডিওতে emphasize করা হয়েছে Kaggle dataset অনেক সময় pre-cleaned হয়; real-world raw data সাধারণত অনেক messy হয়।

10. Duplicate Rows

df.duplicated().sum()

Duplicate মানে একই row একাধিকবার আছে।

কেন problem?

ধরো একই student record 20 বার duplicate আছে। তাহলে model মনে করতে পারে ওই pattern অনেক বেশি important।

সাধারণ fix:

df = df.drop_duplicates()

Notebook-এর markdown-এ zero duplicate বলা থাকলেও actual execution/history-তে transcript-এর একটি অংশে duplicate count নিয়ে mismatch দেখা যায়। তাই নিজের run-এর output-কে source of truth ধরবে।

11. `df.info()` — Data Type বোঝা

df.info()

এখান থেকে জানতে পারি:

Column names
Non-null count
Data types

উদাহরণ:

Age                  int64
Gender               object
Country              object
Study_Hours          float64
Stress_Level         object
Mental_Health_Score  float64

`object` মানে কী?

Pandas-এ object প্রায়ই string/text data বোঝায়।

যেমন:

Male
Female
Instagram
Facebook
High
Low

Machine Learning model সরাসরি text বোঝে না। তাই categorical text feature encode করতে হয়।

12. `df.describe()` — Descriptive Statistics

df.describe()

Numerical columns-এর জন্য দেয়:

count
mean
std
min
25%
50%
75%
max

এখানেই project-এর একটি বাস্তব data issue ধরা পড়ে।

Physical Activity-এর invalid value

Physical_Activity_Hours min = -0.4

এটা physically impossible। মানুষ negative hour exercise করতে পারে না।

তাই এটি real observation না, data-entry error।

13. EDA কী?

EDA = Exploratory Data Analysis

EDA-এর উদ্দেশ্য শুধু সুন্দর graph বানানো না। প্রতিটি plot ideally একটি প্রশ্নের উত্তর দেবে।

Notebook-এর philosophy:

“Chart-এর wall বানাব না; focused plots বানাব।”

Project-এ ছয়টি প্রধান plot করা হয়েছে।

14. Plot 1 — Target Distribution

sns.histplot(df['Mental_Health_Score'], kde=True)

Question:

Mental Health Score কীভাবে distributed?

Histogram কী দেখায়?

Data-এর value কোন range-এ কতবার এসেছে তা bar আকারে দেখায়।

উদাহরণ:

Score 3–4 → 300 students
Score 4–5 → 700 students
Score 5–6 → 1200 students
...

KDE কী?

KDE = Kernel Density Estimate

Histogram-এর উপর smooth curve দেয়, distribution-এর shape বোঝা সহজ হয়।

কেন target distribution দেখা দরকার?

Prediction করার আগে target:

balanced কি না
heavily skewed কি না
strange range আছে কি না
outlier আছে কি না

বোঝা দরকার।

15. Correlation Heatmap

sns.heatmap(df.corr(numeric_only=True), annot=True)

Correlation কী?

দুই numerical variable একসাথে কীভাবে পরিবর্তিত হয় তার linear relationship-এর একটি measure।

Range:

-1 ←—— 0 ——→ +1

Positive Correlation

একটা বাড়লে অন্যটা generally বাড়ে।

Sleep ↑
Mental Health Score ↑

Negative Correlation

একটা বাড়লে অন্যটা generally কমে।

Social Media Usage ↑
Mental Health Score ↓

Near Zero

Strong linear relation নেই।

`numeric_only=True` কেন?

DataFrame-এ string columns আছে। যেমন:

Gender
Country
Platform

Correlation numeric data-তে apply করা হয়। তাই:

df.corr(numeric_only=True)

ব্যবহার করা হয়েছে।

`annot=True` কেন?

Heatmap cell-এর ভেতরে correlation number দেখায়।

ভিডিওতে sleep বনাম score প্রায় positive 0.77 এবং daily usage বনাম score প্রায় -0.82 ধরনের strong relationship discuss করা হয়েছে।

গুরুত্বপূর্ণ সতর্কতা

Correlation ≠ Causation

Dataset-এ দুই feature correlated হলেই একটি অন্যটির সরাসরি কারণ প্রমাণ হয় না।

16. Stress Level vs Mental Health Score

প্রথমে categories দেখা হয়েছে:

df['Stress_Level'].unique()

Categories:

Low
Medium
High
Very High

তারপর order manually define:

order = ['Low', 'Medium', 'High', 'Very High']

Boxplot:

sns.boxplot(
    x='Stress_Level',
    y='Mental_Health_Score',
    data=df,
    order=order
)

কেন Boxplot?

Boxplot group-wise distribution compare করতে সাহায্য করে।

এতে দেখা যায়:

median
quartiles
spread
outliers

Project-এর observed pattern:

Stress বাড়ছে
      ↓
Mental Health Score কমছে

এটা dataset-level relationship। Clinical conclusion নয়।

17. Daily Social Media Usage vs Mental Health

sns.scatterplot(
    x='Avg_Daily_Usage_Hours',
    y='Mental_Health_Score',
    data=df
)

Scatter plot দুটি numerical variable-এর relationship visually দেখায়।

ভিডিওর interpretation:

Low usage → comparatively higher scores
High usage → comparatively lower scores

অর্থাৎ graph top-left থেকে bottom-right trend করলে negative relation বোঝা যায়।

18. Sleep vs Mental Health

sns.scatterplot(
    x='Sleep_Hours_Per_Night',
    y='Mental_Health_Score',
    data=df
)

Observed pattern:

Sleep Hours ↑
Score ↑

Graph bottom-left → top-right গেলে positive relationship-এর visual indication পাওয়া যায়।

19. Most Used Platform

df['Most_Used_Platform'].value_counts()

এটি প্রতিটি platform কতবার এসেছে দেখায়।

তারপর:

plt.figure(figsize=(8, 4))
sns.countplot(
    x=df['Most_Used_Platform'],
    order=df['Most_Used_Platform'].value_counts().index
)

`value_counts().index` কেন?

value_counts() result roughly:

Instagram    1130
TikTok        918
Facebook      800
...

Countplot নিজে count করে, তাই count values pass করার দরকার নেই। শুধু desired order দরকার। সেই order পাওয়া যায় .index থেকে।

20. Outlier কী?

Outlier হলো এমন value যা অন্য observations-এর তুলনায় অস্বাভাবিক দূরে।

উদাহরণ:

Study Hours:
2, 3, 4, 5, 4, 3, 50

50 suspicious outlier।

Project-এ IQR method ব্যবহার করা হয়েছে।

21. IQR Method

num_features = df.select_dtypes(include='number')
Q1 = num_features.quantile(0.25)
Q3 = num_features.quantile(0.75)
IQR = Q3 - Q1

lower_bound = Q1 - 1.5 * IQR
upper_bound = Q3 + 1.5 * IQR

outliers = (num_features < lower_bound) | (num_features > upper_bound)
print(outliers.sum())

Formula

IQR = Q3 - Q1

Lower Bound = Q1 - 1.5 × IQR
Upper Bound = Q3 + 1.5 × IQR

যদি value:

value < Lower Bound

অথবা:

value > Upper Bound

তাহলে potential outlier।

Example

ধরো:

Q1 = 3
Q3 = 7

তাহলে:

IQR = 7 - 3 = 4
Lower = 3 - 1.5×4 = -3
Upper = 7 + 1.5×4 = 13

20 → outlier।

গুরুত্বপূর্ণ

Outlier detect হলেই delete করতে হবে—এমন না। প্রথমে দেখতে হবে value logically possible কি না।

22. Data Cleaning

Notebook-এ দুইটি cleaning step আছে:

df = df.drop_duplicates()

df['Physical_Activity_Hours'] = \
    df['Physical_Activity_Hours'].clip(lower=0)

`clip(lower=0)` কেন?

Suppose:

Physical Activity = -0.4

এটি invalid।

clip(lower=0) করলে:

-0.4 → 0

কেন পুরো row drop করা হয়নি?

কারণ একই student-এর:

Age
Sleep
Stress
Study time
Platform

সব valid হতে পারে। শুধু একটি field ভুল হওয়ায় পুরো row delete করা data waste।

23. Skewness

Skewness distribution-এর asymmetry measure।

num_cols = df.select_dtypes(include='number')
num_cols.skew()

Rough interpretation:

Skew ≈ 0     → roughly symmetric
Skew > 0     → right skewed
Skew < 0     → left skewed

Right Skew example

1 1 2 2 3 4 5 10 20 50

ডান দিকে long tail।

Left Skew example

1 2 10 18 19 20 20 20

বাম দিকে tail।

কেন Linear Regression-এর জন্য relevant?

Tree-based model যেমন Random Forest skewness নিয়ে খুব sensitive নয়। কিন্তু Linear Regression baseline-এর জন্য feature transformation helpful হতে পারে।

Project-এ Study_Hours skewed column হিসেবে separate pipeline-এ গেছে।

24. Feature Engineering — Country Grouping

Dataset-এ Country-এর unique value অনেক—Notebook markdown অনুযায়ী প্রায় 111টি।

যদি সরাসরি One-Hot Encoding করি:

Country_India
Country_USA
Country_Canada
Country_Bangladesh
...

100+ sparse columns তৈরি হতে পারে। একে High Cardinality problem বলা হয়।

Solution

Top 10 frequent countries আলাদা রাখা, বাকিগুলো Other:

top_countries = df['Country'].value_counts().index[:10].tolist()

Function:

def group_countries(country):
    if country in top_countries:
        return country
    else:
        return 'Other'

Apply:

df['Grouped_country'] = df['Country'].apply(group_countries)

ফলে:

111 categories
      ↓
Top 10 + Other
      ↓
11 categories

কেন original Country পুরো drop করা হলো না?

Country-এর কিছু useful signal থাকতে পারে। কিন্তু full high-cardinality version model unnecessarily complex করতে পারে। Grouping balance তৈরি করে।

25. Encoding Strategy

Machine Learning model text বুঝে না। তাই categorical data numerical representation-এ convert করতে হয়।

দুই ধরনের encoding ব্যবহার হয়েছে:

Ordinal Encoding
One-Hot Encoding

26. Ordinal Encoding — Stress Level

Stress level-এর natural order আছে:

Low < Medium < High < Very High

তাই:

Low       → 0
Medium    → 1
High      → 2
Very High → 3

Code:

OrdinalEncoder(
    categories=[['Low', 'Medium', 'High', 'Very High']]
)

কেন One-Hot না?

One-Hot করলে ordering information হারিয়ে যায়। Stress-এর meaningful rank আছে, তাই ordinal encoding logical।

27. One-Hot Encoding

Columns:

Gender
Academic_Level
Most_Used_Platform
Purpose_Of_Use
Grouped_country

এই categories-এর natural ranking নেই।

উদাহরণ:

Instagram > Facebook

এমন relationship নেই। তাই arbitrary number দেওয়া dangerous।

One-Hot Encoding:

Platform_Instagram = 1
Platform_Facebook  = 0
Platform_TikTok    = 0

Code:

OneHotEncoder(handle_unknown='ignore')

`handle_unknown='ignore'`

Production-এ training-এ না থাকা নতুন category এলে pipeline যেন crash না করে।

28. Train-Test Split

Feature group define করা হয়েছে:

skwewd_col = ['Study_Hours']

other_numeric_cols = [
    'Age',
    'Avg_Daily_Usage_Hours',
    'Daily_Unlocks',
    'Physical_Activity_Hours',
    'Sleep_Hours_Per_Night'
]

ordinal_col = ['Stress_Level']

normal_col = [
    'Gender',
    'Academic_Level',
    'Most_Used_Platform',
    'Purpose_Of_Use',
    'Grouped_country'
]

তারপর:

feature_col = skwewd_col + other_numeric_cols + ordinal_col + normal_col
X = df[feature_col]
y = df['Mental_Health_Score']

Actual split code:

X_train, X_test, y_train, y_test = train_test_split(
    X,
    y,
    test_size=0.30,
    random_state=42
)

অর্থাৎ:

70% Training
30% Testing

Note

Notebook markdown-এ 80/20 লেখা আছে, কিন্তু actual code 70/30। Implementation বোঝার সময় code-এর actual parameter follow করবে।

29. Train/Test কেন?

Training set দিয়ে model শেখে।

Testing set model আগে দেখে না।

Full Dataset
     ↓
 ┌──────────────┬──────────────┐
 │              │
Train          Test
70%            30%
 │              │
Fit model       Final evaluation

যদি training data-তেই evaluation করো, model memorize করে artificially ভালো score দিতে পারে।

30. Data Leakage

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

Wrong approach:

Full Data
   ↓
Scaling / Encoding fit
   ↓
Train-Test Split

এখানে test set-এর statistics preprocessing-এ leak হয়ে যেতে পারে।

Correct approach:

Full Data
   ↓
Train/Test Split
   ↓
Preprocessing fitted only on training data
   ↓
Same fitted transformer applied to test data

Pipeline এই risk কমায়।

31. Pipeline এবং ColumnTransformer

ভিডিওর সবচেয়ে important নতুন concept দুটো:

ColumnTransformer
Pipeline

Problem

সব feature-এর preprocessing একই না।

Study_Hours      → log + scaling
Age              → scaling
Stress_Level     → ordinal encoding
Gender           → one-hot encoding
Platform         → one-hot encoding

একটা single scaler বা encoder সব column-এ apply করা যাবে না।

ColumnTransformer কী করে?

এটি different columns-কে different pipelines-এ পাঠায়।

                  Raw Data
                     │
     ┌───────────────┼────────────────┐
     ↓               ↓                ↓
Study_Hours       Numeric        Categorical
     ↓               ↓                ↓
 log1p            scale         encode
     │               │                │
     └───────────────┴────────────────┘
                     ↓
             Combined Features

32. Skewed Feature Pipeline

skew_pipeline = Pipeline(steps=[
    ('log_transform', FunctionTransformer(np.log1p)),
    ('scale', StandardScaler())
])

Flow:

Study_Hours
    ↓
np.log1p
    ↓
StandardScaler

`np.log1p(x)` কী?

এটি:

log(1 + x)

ব্যবহার করে। x=0 হলেও safe।

Example:

x = 0 → log(1) = 0
x = 10 → log(11)

Large values compress হয়, right skew কমতে পারে।

33. Numeric Pipeline

plain_numeric_pipeline = Pipeline(steps=[
    ('scale', StandardScaler())
])

StandardScaler কী করে?

Feature-কে roughly zero mean এবং unit variance scale-এ আনে:

z = (x - mean) / standard_deviation

উদাহরণ:

Daily Unlocks = 120
Age = 23
Sleep = 7

raw scale খুব ভিন্ন। Scaling linear model-এর জন্য useful।

34. Ordinal Pipeline

ordinal_pipeline = Pipeline(steps=[
    ('encode', OrdinalEncoder(
        categories=[['Low', 'Medium', 'High', 'Very High']]
    ))
])

Natural order preserve করে।

35. Nominal Pipeline

nominal_pipeline = Pipeline(steps=[
    ('encode', OneHotEncoder(handle_unknown='ignore'))
])

যেসব category-এর order নেই তাদের জন্য।

36. ColumnTransformer

preprocessor = ColumnTransformer(transformers=[
    ('Skewed_Pipeline', skew_pipeline, skwewd_col),
    ('Plain_Numeric', plain_numeric_pipeline, other_numeric_cols),
    ('Ordinal', ordinal_pipeline, ordinal_col),
    ('Normal', nominal_pipeline, normal_col)
])

এখানে tuple pattern:

(name, transformer, columns)

মানে:

এই নামের transformer → এই columns-এর উপর apply করো

37. Final Model Pipeline কেন?

ভিডিওর key idea:

Backend যেন scaling, encoding, log transformation কিছুই আলাদা করে না জানে। সে শুধু raw input দেবে এবং .predict() call করবে।

Pipeline:

Raw User Input
      ↓
ColumnTransformer
      ↓
Scaling + Encoding + Log transform
      ↓
Machine Learning Model
      ↓
Prediction

এটা deployment অনেক safer করে।

38. Linear Regression Baseline

lr_pipeline = Pipeline(steps=[
    ('preprocessor', preprocessor),
    ('regressor', LinearRegression())
])

Fit:

lr_pipeline.fit(X_train, y_train)

Predict:

lr_preds = lr_pipeline.predict(X_test)

Training predictions:

lr_preds_train = lr_pipeline.predict(X_train)

কেন baseline?

Linear Regression simple model। যদি simple model-ই ভালো করে, unnecessarily complex model দরকার নাও হতে পারে।

39. Linear Regression Result

Saved notebook output:

Training R² ≈ 0.7237
Testing R²  ≈ 0.7398
MAE         ≈ 0.5362
RMSE        ≈ 0.6760

Interpretation:

Train এবং test score কাছাকাছি
Severe overfitting নেই
কিন্তু Random Forest-এর তুলনায় weaker performance

40. Random Forest

rf_pipeline = Pipeline(steps=[
    ('preprocessor', preprocessor),
    ('random forest', RandomForestRegressor(random_state=42))
])

Random Forest অনেক Decision Tree combine করে।

Simple mental model:

Tree 1 → prediction
Tree 2 → prediction
Tree 3 → prediction
...
Tree N → prediction
       ↓
Average
       ↓
Final Regression Output

Tree-based model nonlinear relation ও feature interaction ধরতে পারে।

41. Default Random Forest Result

Notebook output:

Training R² ≈ 0.9808
Testing R²  ≈ 0.8776
MAE         ≈ 0.3472
RMSE        ≈ 0.4637

এটি Linear Regression-এর চেয়ে test set-এ ভালো।

কিন্তু training R² 0.98 আর testing R² 0.88 — gap আছে। এটি কিছু overfitting-এর sign হতে পারে।

42. Overfitting কী?

Model training data খুব ভালো শিখে ফেলেছে, কিন্তু unseen data-তে performance noticeably কম।

Train R² = 0.99
Test R²  = 0.70

→ strong overfitting indication।

এই project-এ:

Train ≈ 0.98
Test  ≈ 0.88

gap আছে, কিন্তু test performance still strong।

Underfitting কী?

Train এবং test দুটোতেই poor:

Train = 0.50
Test  = 0.48

মানে model pattern ধরতেই পারছে না।

43. Hyperparameter Tuning

Random Forest-এর parameters model behavior control করে।

Project-এ tune করা হয়েছে:

param_grid = {
    'random forest__n_estimators': [100, 200, 300],
    'random forest__max_depth': [5, 10, 15],
    'random forest__min_samples_split': [2, 5, 10],
    'random forest__min_samples_leaf': [1, 2, 4]
}

Parameters সহজভাবে

`n_estimators`

কতটি tree থাকবে।

`max_depth`

একটি tree কত deep যেতে পারবে।

`min_samples_split`

একটি node split করার জন্য minimum samples।

`min_samples_leaf`

Leaf node-এ minimum samples।

44. Pipeline parameter name-এ `__` কেন?

Pipeline step name:

('random forest', RandomForestRegressor(...))

তাই parameter refer করতে:

random forest__n_estimators

দুই underscore __ দিয়ে:

pipeline_step__parameter

format ব্যবহার হয়।

45. RandomizedSearchCV

random_search = RandomizedSearchCV(
    estimator=rf_pipeline,
    param_distributions=param_grid,
    n_iter=15,
    cv=5,
    scoring='r2',
    random_state=42,
    n_jobs=-1
)

`n_iter=15`

সব possible combination test না করে 15টি random combination try করবে।

`cv=5`

5-fold cross validation।

`scoring='r2'`

Best model select করার metric R²।

`n_jobs=-1`

সব available CPU cores ব্যবহার করতে পারে।

46. Cross Validation

Training data 5 ভাগ:

Fold 1
Fold 2
Fold 3
Fold 4
Fold 5

Round 1:

Train = Fold 2–5
Validate = Fold 1

Round 2:

Train = 1,3,4,5
Validate = 2

এভাবে প্রতিটি fold একবার validation হয়।

একটি single split-এর luck-এর উপর dependency কমে।

47. Best Hyperparameters

Notebook output:

{
 'random forest__n_estimators': 200,
 'random forest__min_samples_split': 5,
 'random forest__min_samples_leaf': 2,
 'random forest__max_depth': 15
}

Best estimator:

rf_best_pipeline = random_search.best_estimator_

48. Tuned Random Forest Result

Test R²      ≈ 0.8650
Training R²  ≈ 0.9547
MAE          ≈ 0.3689
RMSE         ≈ 0.4869

Interesting finding:

Default Random Forest test result tuned model-এর চেয়ে সামান্য ভালো।

এটা শেখায়:

Hyperparameter tuning করলেই performance অবশ্যই improve করবে—এমন guarantee নেই।

Tuning overfitting gap reduce করতে পারে, কিন্তু chosen search space বা random combinations test score কমাতেও পারে।

49. Evaluation Metrics

R² Score

Target variation-এর কতটা model explain করছে তার measure।

R² = 1 → perfect prediction
R² = 0 → naive mean baseline-এর মতো
R² < 0 → mean prediction-এর থেকেও খারাপ

Simple interpretation:

R² = 0.88

মানে model dataset-এর variation-এর বড় অংশ explain করছে।

50. MAE

MAE = Mean Absolute Error

Formula idea:

|Actual - Prediction|

সব absolute error-এর mean।

Example:

Actual      Prediction   Error
8.0         7.5          0.5
6.0         6.2          0.2
5.0         4.6          0.4

Average:

(0.5 + 0.2 + 0.4) / 3
= 0.3667

MAE original score unit-এ understandable।

51. RMSE

RMSE = Root Mean Squared Error

Large mistakes-কে বেশি penalty দেয়।

Error 0.5 → squared 0.25
Error 2.0 → squared 4.0

তাই rare large error থাকলে RMSE বেড়ে যায়।

52. Model Comparison Table

Actual notebook output:

Model	Test R²	Train R²	MAE	RMSE
Linear Regression	0.7398	0.7237	0.5362	0.6760
Random Forest Default	0.8776	0.9808	0.3472	0.4637
Random Forest Tuned	0.8650	0.9547	0.3689	0.4869

Dataset/test split অনুযায়ী default Random Forest এখানে strongest test metrics দিয়েছে।

53. Model Save with Joblib

import joblib
joblib.dump(rf_pipeline, 'Mental_Health_Model.pkl')

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

শুধু Random Forest object save করা হয়নি। rf_pipeline save হওয়ায় preprocessing + model একসাথে save হয়।

Mental_Health_Model.pkl
        │
        ├── ColumnTransformer
        ├── log1p transform
        ├── StandardScaler
        ├── OrdinalEncoder
        ├── OneHotEncoder
        └── RandomForestRegressor

কেন ভালো?

FastAPI শুধু:

model.predict(raw_dataframe)

call করবে। Backend-এ preprocessing পুনরায় manually লিখতে হবে না।

54. Important Model Save Mismatch

Notebook tuned model বানিয়েছে:

rf_best_pipeline = random_search.best_estimator_

কিন্তু save করেছে:

joblib.dump(rf_pipeline, 'Mental_Health_Model.pkl')

অর্থাৎ default Random Forest pipeline save হয়েছে, tuned one না।

এটি intentional হতে পারে কারণ default model-এর test metrics better ছিল। তবে code-এ comment দিয়ে reason clear করা উচিত ছিল।

যদি tuned model save করতে চাই:

joblib.dump(rf_best_pipeline, 'Mental_Health_Model.pkl')

55. FastAPI Backend

Backend file:

main.py

Imports:

import joblib
import pandas as pd
from fastapi import FastAPI
from pydantic import BaseModel, Field
from typing import Literal
from fastapi.middleware.cors import CORSMiddleware

56. Load Model

model = joblib.load('Mental_Health_Model.pkl')

Server start হলে saved pipeline memory-তে load হয়।

তারপর প্রতিটি prediction request-এ নতুন করে model load করতে হয় না।

57. FastAPI App

app = FastAPI()

এটাই application object।

Run command সাধারণত:

uvicorn main:app --reload

Project JS error message-এ port example:

uvicorn main:app --port 2200 --reload

58. Pydantic কেন?

Pydantic request body validate করে।

class StudentData(BaseModel):

এটি বলে:

/predict-এ কী shape-এর data আসবে এবং কোন field-এর type/range কী হবে।

59. Age Validation

age: int = Field(..., ge=10, le=100)

মানে:

Required
Integer
Age >= 10
Age <= 100

যদি আসে:

{"age": 5}

FastAPI/Pydantic 422 validation error দিতে পারে।

60. Literal Validation

gender: Literal['Male', 'Female']

Valid:

Male
Female

Invalid:

ABC
Unknown

একইভাবে academic level, platform, purpose এবং stress level predefined category-তে restricted।

61. Numeric Field Validation

avg_daily_usage_hours: float = Field(..., ge=0, le=24)
daily_unlocks: int = Field(..., ge=0)
study_hours: float = Field(..., ge=0, le=24)
physical_activity_hours: float = Field(..., ge=0, le=24)
sleep_hours_per_night: float = Field(..., ge=0, le=24)

এতে physically impossible বা clearly invalid inputs prevent করা হয়।

62. Prediction Response Model

class PredictionResponse(BaseModel):
    predicted_mental_health_score: float

এটি API response-এর shape define করে।

Expected response:

{
  "predicted_mental_health_score": 6.78
}

63. Root Route

@app.get('/')
def greet():
    return {'Welcome to Sheryians AI School Guys'}

Browser-এ root URL hit করলে simple JSON response আসে।

এটা backend alive কি না basic check হিসেবে useful।

64. `/predict` Route

@app.post('/predict', response_model=PredictionResponse)
def predict(data: StudentData):

এখানে:

Method = POST
Endpoint = /predict
Request validated by StudentData
Response validated by PredictionResponse

65. Backend Country Grouping

Training-এ Country grouping করা হয়েছিল। Prediction-এর সময় একই logic দরকার।

country_group = data.country if data.country in top_countries else 'Other'

Training এবং inference preprocessing consistency খুব গুরুত্বপূর্ণ।

66. Input DataFrame তৈরি

input_row = pd.DataFrame([{
    'Age': data.age,
    'Gender': data.gender,
    'Country': data.country,
    'Academic_Level': data.academic_level,
    'Most_Used_Platform': data.most_used_platform,
    'Purpose_Of_Use': data.purpose_of_use,
    'Avg_Daily_Usage_Hours': data.avg_daily_usage_hours,
    'Daily_Unlocks': data.daily_unlocks,
    'Study_Hours': data.study_hours,
    'Physical_Activity_Hours': data.physical_activity_hours,
    'Sleep_Hours_Per_Night': data.sleep_hours_per_night,
    'Stress_Level': data.stress_level,
    'Grouped_country': country_group
}])

কেন DataFrame?

Saved pipeline column names দিয়ে preprocessing route করে। তাই raw user data-কে training-এর মতো DataFrame schema-তে convert করা হচ্ছে।

67. Prediction

prediction = model.predict(input_row)[0]

Flow:

input_row
   ↓
Saved Pipeline
   ↓
Feature preprocessing
   ↓
Random Forest
   ↓
Array-like prediction
   ↓
[0] দিয়ে first prediction

তারপর:

round(float(prediction), 2)

যেমন:

6.777777
   ↓
6.78

68. CORS

Backend:

app.add_middleware(
    CORSMiddleware,
    allow_origins=['*'],
    allow_methods=['*'],
    allow_headers=['*'],
)

Browser security কারণে frontend এবং backend আলাদা origin/domain হলে request block হতে পারে। CORS policy দিয়ে অনুমতি দেওয়া হয়।

Production note

allow_origins=['*'] demo project-এর জন্য easy, কিন্তু production-এ specific frontend domain allow করা safer।

69. Frontend Technologies

ভিডিওতে বলা হয়েছে Streamlit ব্যবহার করা হয়নি। Frontend:

HTML
CSS
JavaScript

এতে project traditional web app architecture follow করছে।

70. Frontend Form

User form-এ data দেয়:

Age
Gender
Country
Academic Level
Most Used Platform
Purpose of Use
Average Daily Usage Hours
Daily Unlocks
Study Hours
Physical Activity Hours
Sleep Hours
Stress Level

Submit button চাপলে JavaScript payload বানায়।

71. `collectPayload()`

JavaScript form values collect করে exact Pydantic shape বানায়:

return {
  age: ..., 
  gender: ...,
  country: ...,
  academic_level: ...,
  most_used_platform: ...,
  purpose_of_use: ...,
  avg_daily_usage_hours: ...,
  daily_unlocks: ...,
  study_hours: ...,
  physical_activity_hours: ...,
  sleep_hours_per_night: ...,
  stress_level: ...
};

এখানে frontend field names backend Pydantic model-এর field names-এর সাথে match করা খুব গুরুত্বপূর্ণ।

72. Client-side Validation

JavaScript backend-এ পাঠানোর আগে numeric ranges check করে:

Age                  10–100
Daily Usage           0–24
Daily Unlocks         >= 0
Study Hours           0–24
Physical Activity     0–24
Sleep                 0–24

এতে user instant feedback পায়।

কিন্তু frontend validation security boundary না; backend Pydantic validation still required।

73. Stress Segmented Control

JavaScript stress level button click handle করে:

Low
Medium
High
Very High

Selected value hidden input-এ রাখা হয়।

এটি UI সুন্দর করে, কিন্তু backend শেষ পর্যন্ত string value-টাই পায়।

74. API Call with `fetch`

Core code:

const res = await fetch(`${API_BASE}/predict`, {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify(payload),
});

Flow:

JavaScript Object
      ↓
JSON.stringify
      ↓
HTTP POST
      ↓
FastAPI /predict

75. API Base URL

Project frontend:

const API_BASE = 'https://mansik-santulan-score.onrender.com';

মানে backend Render-এ deployed।

Local development-এ এটি হতে পারে:

const API_BASE = 'http://127.0.0.1:8000';

অথবা project-specific port।

76. 422 Validation Error Handling

FastAPI Pydantic validation fail করলে HTTP 422 দেয়।

Frontend code response-এর detail array parse করে relevant field-এর পাশে error message দেখানোর চেষ্টা করে।

এটি UX-এর জন্য ভালো design।

77. Loading / Result / Error UI States

JavaScript চারটি state manage করে:

idle
loading
result
error

Submit:

Idle
 ↓
Loading
 ↓
Success → Result
     অথবা
Failure → Error

এটি user-কে application কী করছে বুঝতে সাহায্য করে।

78. Result Gauge

Prediction score clamp করা হয়:

const clamped = Math.max(0, Math.min(10, score));

মানে UI gauge 0–10 range-এর বাইরে যাবে না।

তারপর arc fill score অনুযায়ী animate হয়।

79. UI Score Bands

Frontend code-এ:

score < 4
→ Signal: strained

4 ≤ score < 7
→ Signal: balanced

score ≥ 7
→ Signal: strong

এগুলো product UI labels; medical diagnosis না।

Mental-health-related application হলে এই distinction খুব important।

80. Complete Request-Response Example

ধরো user input:

Age = 23
Gender = Female
Country = Bangladesh
Academic Level = Undergraduate
Platform = Instagram
Purpose = Entertainment
Usage = 7 hours
Unlocks = 95
Study = 3 hours
Physical Activity = 1 hour
Sleep = 5.5 hours
Stress = High

Step 1 — Frontend Payload

{
  "age": 23,
  "gender": "Female",
  "country": "Bangladesh",
  "academic_level": "Undergraduate",
  "most_used_platform": "Instagram",
  "purpose_of_use": "Entertainment",
  "avg_daily_usage_hours": 7,
  "daily_unlocks": 95,
  "study_hours": 3,
  "physical_activity_hours": 1,
  "sleep_hours_per_night": 5.5,
  "stress_level": "High"
}

Step 2 — FastAPI

Pydantic validate করবে।

Step 3 — Country grouping

Bangladesh top list-এ না থাকলে:

Grouped_country = Other

Step 4 — DataFrame

Input training schema-এর মতো row হবে।

Step 5 — Saved Pipeline

Study_Hours
   ↓ log1p + scale

Numeric features
   ↓ scale

Stress
   ↓ ordinal encode

Other categorical
   ↓ one-hot encode

Step 6 — Random Forest

Transformed feature vector থেকে numerical score predict করবে।

Step 7 — API Response

{
  "predicted_mental_health_score": 5.43
}

Step 8 — Frontend

Gauge এবং label update হবে।

81. Deployment Concept

ভিডিওতে project Render-এ deploy করার কথা বলা হয়েছে।

Basic deployment flow:

GitHub Repository
      ↓
Render Web Service
      ↓
Install requirements.txt
      ↓
Start FastAPI using Uvicorn
      ↓
Public API URL

requirements.txt project-এ:

fastapi
uvicorn
pydantic
joblib
pandas
scikit-learn

Typical Render Start Command

uvicorn main:app --host 0.0.0.0 --port $PORT

Frontend-এ deployed API URL set করা হয়।

82. End-to-End Architecture Diagram

┌─────────────────────────────────────┐
│             USER / BROWSER          │
└──────────────────┬──────────────────┘
                   │
                   ▼
┌─────────────────────────────────────┐
│       HTML + CSS + JavaScript       │
│ Form, validation, loading, gauge    │
└──────────────────┬──────────────────┘
                   │ JSON POST /predict
                   ▼
┌─────────────────────────────────────┐
│              FASTAPI                │
│ Pydantic validation + route logic   │
└──────────────────┬──────────────────┘
                   │
                   ▼
┌─────────────────────────────────────┐
│     pandas DataFrame input row      │
└──────────────────┬──────────────────┘
                   │
                   ▼
┌─────────────────────────────────────┐
│        SAVED SKLEARN PIPELINE       │
│                                     │
│ ColumnTransformer                   │
│ ├── Study_Hours → log + scale       │
│ ├── Numeric → scale                 │
│ ├── Stress → ordinal encoding       │
│ └── Categories → one-hot encoding   │
│                 ↓                   │
│       RandomForestRegressor         │
└──────────────────┬──────────────────┘
                   │
                   ▼
┌─────────────────────────────────────┐
│        Predicted Score 0–10         │
└──────────────────┬──────────────────┘
                   │ JSON
                   ▼
┌─────────────────────────────────────┐
│         Frontend Result Gauge       │
└─────────────────────────────────────┘

83. Video-এর Important Learning Philosophy

ভিডিওতে technical content-এর পাশাপাশি কয়েকটি mindset point repeated হয়েছে:

শুধু notebook model বানানো যথেষ্ট না—deployment পর্যন্ত গেলে project অনেক stronger হয়।
EDA random graph collection না; প্রতিটি graph-এর একটি question থাকা উচিত।
Kaggle data clean হলেও real-world data messy—cleaning mindset develop করতে হবে।
Categorical text model সরাসরি বুঝে না; encoding দরকার।
Different columns-এর জন্য different preprocessing দরকার হতে পারে।
Pipeline production deployment-এর জন্য খুব useful।
Training score একা দেখে model choose করা উচিত না; unseen test data performance বেশি important।
Single metric-এর উপর model decision না নেওয়া ভালো; R² + MAE + RMSE together দেখা উচিত।
Hyperparameter tuning মানেই automatically better test score নয়।
Frontend, backend এবং ML pipeline-এর schema consistent থাকা অত্যন্ত গুরুত্বপূর্ণ।

84. Important Mismatch / Improvement Notes

এগুলো project ভালোভাবে বুঝতে সবচেয়ে useful অংশগুলোর একটি।

84.1 80/20 লেখা, code 70/30

Markdown বলে 80/20। Actual code:

test_size=0.30

অর্থাৎ 70/30। Documentation update করা উচিত।

84.2 Tuned model বানানো হলেও default pipeline save

joblib.dump(rf_pipeline, ...)

এটি default RF। Notebook output-এ default model test metrics tuned model-এর চেয়ে better, তাই choice reasonable; কিন্তু explicit explanation থাকা উচিত।

84.3 Country list consistency

Training-এ top_countries dynamically dataset থেকে বের করা হয়েছে। Backend-এ list hard-coded:

top_countries = ['Other','India','USA','Canada','Australia','UK','Germany','Mexico','Turkey','France']

Best practice:

Country grouping logic pipeline-এর ভেতরে রাখা, অথবা
fitted metadata save করা

যাতে training এবং inference mismatch না হয়।

84.4 Original `Country` input_row-এ আছে, কিন্তু model features-এ ব্যবহার হয় না

Model Grouped_country ব্যবহার করে; raw Country ColumnTransformer feature list-এ নেই। এটি harmless extra column হতে পারে, কিন্তু cleaner schema রাখা ভালো।

84.5 CORS `*`

Demo-র জন্য okay, production-এ specific origin safer।

84.6 Medical Interpretation

এই model educational dataset-এর statistical prediction। User-এর real mental health assessment হিসেবে present করা উচিত না। UI-তে clear disclaimer থাকা দরকার।

85. কীভাবে project explain করবে Viva-তে

Short answer:

“আমি একটি end-to-end regression application তৈরি করেছি যেখানে student-এর social media usage, study, sleep, physical activity, stress এবং demographic data থেকে Mental Health Score predict করা হয়। Data cleaning এবং EDA-এর পরে categorical variables ordinal ও one-hot encoding করেছি, numerical features scale করেছি, skewed study-hours feature log transform করেছি এবং এগুলো sklearn ColumnTransformer ও Pipeline-এর মধ্যে combine করেছি। Linear Regression baseline এবং Random Forest compare করেছি, RandomizedSearchCV দিয়ে tuning করেছি এবং R², MAE, RMSE দিয়ে evaluate করেছি। পুরো trained pipeline Joblib দিয়ে save করে FastAPI/Pydantic backend-এ expose করেছি এবং HTML/CSS/JavaScript frontend থেকে /predict endpoint call করে live prediction দেখিয়েছি।”

86. Viva Questions + Answers

Q1. কেন regression?

কারণ target Mental_Health_Score continuous numerical value।

Q2. কেন classification না?

Target class label না; number predict করছি।

Q3. `df.info()` কেন?

Column types, non-null count এবং schema বুঝতে।

Q4. negative physical activity কীভাবে handle করেছ?

clip(lower=0) ব্যবহার করেছি যাতে invalid negative hour zero হয় এবং পুরো row না হারায়।

Q5. Correlation কী?

দুই numerical feature-এর linear relationship-এর strength/direction।

Q6. Correlation causation প্রমাণ করে?

না।

Q7. IQR কেন?

Potential outlier detect করতে robust statistical method।

Q8. Country grouping কেন?

High cardinality reduce করতে।

Q9. Stress level-এ Ordinal Encoding কেন?

কারণ natural order আছে: Low < Medium < High < Very High।

Q10. Platform-এ One-Hot কেন?

কারণ natural order নেই।

Q11. ColumnTransformer কেন?

Different column groups-এ different preprocessing apply করতে।

Q12. Pipeline কেন?

Preprocessing + model এক object-এ chain করতে এবং training/inference consistency রাখতে।

Q13. Data leakage কী?

Test data-এর information training/preprocessing fitting-এ accidentally চলে যাওয়া।

Q14. Random Forest Linear Regression-এর চেয়ে কেন ভালো করতে পারে?

Nonlinear relation এবং feature interaction ধরতে পারে।

Q15. Hyperparameter কী?

Training-এর আগে configured model setting, যেমন max_depth, n_estimators।

Q16. RandomizedSearchCV কেন?

সব combination exhaustive search না করে selected random combinations efficiently test করতে।

Q17. R² কী?

Target variation-এর কতটা model explain করছে তার measure।

Q18. MAE কী?

Average absolute prediction error।

Q19. RMSE কী?

Squared error-based metric যা large mistakes বেশি penalize করে।

Q20. Joblib দিয়ে পুরো pipeline save কেন?

Backend-এ preprocessing manually recreate না করতে।

Q21. Pydantic কেন?

API request validation ও type/range enforcement-এর জন্য।

Q22. POST কেন?

Prediction request-এ structured JSON payload পাঠাতে সুবিধাজনক এবং semantics অনুযায়ী data processing action।

Q23. CORS কেন?

Browser-এর cross-origin request restriction handle করতে।

Q24. 422 error কী?

FastAPI/Pydantic validation fail হলে সাধারণত Unprocessable Entity response।

87. Beginner-এর জন্য Project শেখার Order

তুমি যদি raw থেকে শিখতে চাও:

1. Python basics
2. NumPy basics
3. Pandas
4. Matplotlib / Seaborn
5. Basic Statistics
6. Regression concept
7. Data Cleaning
8. EDA
9. Encoding
10. Scaling
11. Train/Test Split
12. Linear Regression
13. Decision Tree
14. Random Forest
15. Evaluation Metrics
16. ColumnTransformer
17. Pipeline
18. Hyperparameter Tuning
19. Joblib
20. FastAPI
21. Pydantic
22. Basic HTML/CSS/JS
23. Fetch API
24. CORS
25. Render Deployment

88. সবচেয়ে Important 4 Concepts

এই project থেকে যদি চারটি জিনিস সবচেয়ে ভালোভাবে শিখতে চাও:

1. ColumnTransformer

Different feature group → different preprocessing।

2. Pipeline

Preprocessing + model → single reliable object।

3. Train/Test + Leakage

Unseen data দিয়ে honest evaluation।

4. FastAPI Integration

ML model → usable real-world web API।

89. Full Project Mental Model

সবকিছু ভুলে গেলেও এই flow মনে রাখবে:

UNDERSTAND PROBLEM
       ↓
LOAD DATA
       ↓
CHECK SHAPE / HEAD / INFO
       ↓
MISSING / DUPLICATE / INVALID VALUES
       ↓
EDA
       ↓
OUTLIERS
       ↓
CLEAN DATA
       ↓
CHECK SKEWNESS
       ↓
FEATURE ENGINEERING
       ↓
DEFINE X AND y
       ↓
TRAIN / TEST SPLIT
       ↓
COLUMN TRANSFORMER
       ↓
PIPELINE
       ↓
LINEAR REGRESSION BASELINE
       ↓
RANDOM FOREST
       ↓
HYPERPARAMETER TUNING
       ↓
R² + MAE + RMSE
       ↓
SAVE PIPELINE
       ↓
FASTAPI
       ↓
PYDANTIC VALIDATION
       ↓
POST /predict
       ↓
HTML/CSS/JS FRONTEND
       ↓
FETCH API
       ↓
RESULT GAUGE
       ↓
RENDER DEPLOYMENT

90. One Final Example — Raw Input থেকে Final Prediction

ধরো user:

Age = 21
Gender = Male
Country = Bangladesh
Academic Level = Undergraduate
Platform = TikTok
Purpose = Entertainment
Usage = 8 h/day
Unlocks = 120
Study = 2 h/day
Exercise = 0.5 h/day
Sleep = 5 h/night
Stress = Very High

Backend Request

{
  "age": 21,
  "gender": "Male",
  "country": "Bangladesh",
  "academic_level": "Undergraduate",
  "most_used_platform": "TikTok",
  "purpose_of_use": "Entertainment",
  "avg_daily_usage_hours": 8,
  "daily_unlocks": 120,
  "study_hours": 2,
  "physical_activity_hours": 0.5,
  "sleep_hours_per_night": 5,
  "stress_level": "Very High"
}

Internal transformation conceptually

Study_Hours = 2
   ↓ log1p
   ↓ scale

Age = 21
Usage = 8
Unlocks = 120
Exercise = 0.5
Sleep = 5
   ↓ StandardScaler

Stress = Very High
   ↓ OrdinalEncoder
   ↓ 3

Gender = Male
Platform = TikTok
Purpose = Entertainment
Academic = Undergraduate
Country Group = Other
   ↓ OneHotEncoder

সব transformed features merge হয়।

Feature Vector
      ↓
Random Forest
      ↓
Predicted Mental Health Score

ধরো result:

4.72

FastAPI:

{
  "predicted_mental_health_score": 4.72
}

Frontend result gauge update করবে।

এই পুরো sequence বুঝতে পারলে তুমি project-এর মূল architecture সত্যিই বুঝে গেছ, শুধু code মুখস্থ করোনি।

91. Summary Cheat Sheet

Problem Type       : Regression
Target             : Mental_Health_Score
Dataset Size       : ~5000 rows, 13 columns
EDA                : Histogram, Heatmap, Boxplot, Scatterplot, Countplot
Outlier Method     : IQR
Invalid Value Fix  : clip(lower=0)
Skew Fix           : log1p for Study_Hours
High Cardinality   : Country → Top 10 + Other
Ordinal Encoding   : Stress_Level
One-Hot Encoding   : Gender, Academic, Platform, Purpose, Grouped Country
Scaling            : StandardScaler
Split              : Actual code 70/30
Baseline           : Linear Regression
Main Model         : Random Forest Regressor
Tuning             : RandomizedSearchCV, 5-fold CV
Metrics            : R², MAE, RMSE
Serialization      : joblib / .pkl
Backend            : FastAPI
Validation         : Pydantic
Frontend           : HTML + CSS + JavaScript
API Method         : POST
Endpoint           : /predict
Deployment         : Render

92. Final Takeaway

এই project-এর সবচেয়ে বড় lesson কোনো একটি algorithm না। সবচেয়ে বড় lesson হলো Machine Learning model কীভাবে একটি complete application-এর অংশ হয়।

একজন beginner সাধারণত দেখে:

CSV → Model → Accuracy

কিন্তু real project flow:

Problem Understanding
→ Data Quality
→ EDA
→ Cleaning
→ Feature Engineering
→ Correct Preprocessing
→ Leakage-free Training
→ Multiple Model Comparison
→ Evaluation
→ Serialization
→ Backend Validation
→ API
→ Frontend
→ Error Handling
→ Deployment

তুমি যদি এই flow বুঝে নিজের ভাষায় explain করতে পারো, তাহলে project-টা সত্যিকার অর্থে বুঝেছ।

🐧 Linux for DevOps — Complete Learning & Interview Preparation

Ragib Hasan — Fri, 18 Sep 2026 11:54:47 +0000

Goal: একদম raw level থেকে Linux শিখে DevOps/SRE/Cloud/Kubernetes কাজের জন্য production-ready foundation তৈরি করা।

📌 Table of Contents

Linux কী?
Linux Architecture
Linux Distribution
Terminal & Shell
Filesystem
Essential Commands
File & Directory Management
File Permissions
Users & Groups
Ownership
Processes
Jobs & Signals
System Monitoring
Package Management
Environment Variables
Shell & Bash
Pipes & Redirection
grep, sed, awk
Networking
Ports & Sockets
DNS
SSH
SCP & Rsync
File Compression
Disk & Storage
Mounting
/proc, /sys, /dev
systemd & Services
Logs & journald
Cron & Scheduling
Linux Security
Firewall
TLS/SSL Basics
Web Server Basics
Reverse Proxy
Linux for Docker
Linux for Kubernetes
Performance Troubleshooting
Production Troubleshooting
Bash Automation
DevOps Practical Tasks
Interview Questions
Scenario-Based Interview
Hands-on Projects
Final Checklist

1. Linux কী?

Linux একটি open-source Unix-like operating system kernel।

Linux system সাধারণত:

User
  ↓
Shell
  ↓
System Calls
  ↓
Linux Kernel
  ↓
Hardware

Linux কেন DevOps-এ গুরুত্বপূর্ণ?

বেশিরভাগ:

Cloud server
Web server
Docker container
Kubernetes node
CI/CD runner
Database server
Monitoring server
Production infrastructure

Linux-এর উপর চলে।

তাই DevOps engineer-এর জন্য Linux হলো foundational skill।

2. Linux Architecture

Basic architecture:

+-------------------------+
|        Applications     |
+-------------------------+
|        Shell            |
+-------------------------+
|     System Libraries    |
+-------------------------+
|     Linux Kernel        |
+-------------------------+
|        Hardware         |
+-------------------------+

Kernel

Kernel manage করে:

CPU
Memory
Processes
Filesystem
Networking
Devices
Security

3. Linux Distribution

জনপ্রিয় distributions:

Ubuntu
Debian
Fedora
RHEL
Rocky Linux
AlmaLinux
Arch Linux
Amazon Linux

DevOps-এ বিশেষভাবে:

Ubuntu
Amazon Linux
RHEL-based systems
Debian

জানা useful।

4. Terminal & Shell

Terminal হলো interface যেখানে command চালানো হয়।

Shell command interpret করে।

Popular shells:

bash
zsh
fish
sh

DevOps-এর জন্য Bash অবশ্যই শিখতে হবে।

Check:

echo $SHELL

Current shell:

ps -p $$

5. Linux Filesystem

Linux filesystem tree:

/
├── bin
├── boot
├── dev
├── etc
├── home
├── lib
├── opt
├── proc
├── root
├── run
├── sbin
├── srv
├── sys
├── tmp
├── usr
└── var

গুরুত্বপূর্ণ directories

`/`

Root filesystem।

`/home`

User files।

/home/ragib

`/etc`

System configuration।

Examples:

/etc/hosts
/etc/fstab
/etc/ssh/
/etc/systemd/

`/var`

Frequently changing data।

Examples:

/var/log
/var/cache
/var/lib

`/tmp`

Temporary files।

`/usr`

Applications, libraries, utilities।

`/opt`

Optional/third-party applications।

`/dev`

Device files।

`/proc`

Kernel/process information।

`/sys`

Kernel/device information।

6. Navigation Commands

Current directory:

pwd

List:

ls

Detailed:

ls -l

Hidden:

ls -la

Change directory:

cd /etc

Home:

cd ~

Previous directory:

cd -

Parent:

cd ..

7. File Management

Create file:

touch app.log

Create directory:

mkdir project

Nested directories:

mkdir -p project/src/app

Copy:

cp file.txt backup.txt

Copy directory:

cp -r project backup/

Move:

mv file.txt /tmp/

Rename:

mv old.txt new.txt

Delete:

rm file.txt

Delete directory:

rm -r directory/

Force:

rm -rf directory/

⚠️ rm -rf production server-এ অত্যন্ত সতর্কতার সাথে ব্যবহার করতে হবে।

8. Reading Files

Small file:

cat file.txt

Large file:

less file.txt

First lines:

head file.txt

Last lines:

tail file.txt

Last 100:

tail -n 100 app.log

Follow log:

tail -f app.log

9. Searching Files

Find:

find /var/log -name "*.log"

Search by type:

find . -type f

Search directory:

find . -type d

Search recently modified:

find . -mtime -1

10. grep

Text search:

grep "error" app.log

Case insensitive:

grep -i "error" app.log

Recursive:

grep -r "database" /etc/

Line number:

grep -n "error" app.log

Invert match:

grep -v "INFO" app.log

Multiple patterns:

grep -E "error|failed|critical" app.log

11. Pipes

Pipe একটি command-এর output অন্য command-এর input হিসেবে দেয়।

ps aux | grep nginx

Example:

cat app.log | grep ERROR

Better:

grep ERROR app.log

Multiple:

ps aux | grep python | grep -v grep

12. Redirection

Output file:

ls > files.txt

Append:

ls >> files.txt

Error redirect:

command 2> error.log

Both stdout + stderr:

command > output.log 2>&1

Modern Bash:

command &> output.log

13. Permissions

Linux permission:

r = read
w = write
x = execute

Example:

-rwxr-xr--

Breakdown:

Owner      Group      Others
rwx        r-x        r--

Numeric permissions:

r = 4
w = 2
x = 1

Examples:

7 = rwx
6 = rw-
5 = r-x
4 = r--

Therefore:

chmod 755 script.sh

Means:

Owner:  rwx
Group:  r-x
Others: r-x

14. chmod

Add execute:

chmod +x script.sh

Remove write:

chmod -w file.txt

Recursive:

chmod -R 755 directory/

Symbolic:

chmod u+x script.sh

15. chown

Change owner:

sudo chown user file.txt

Owner + group:

sudo chown user:group file.txt

Recursive:

sudo chown -R user:group directory/

16. Users

Current user:

whoami

User ID:

id

Logged-in users:

who

User information:

/etc/passwd

Password information:

/etc/shadow

/etc/shadow sensitive; normally readable only by privileged users.

17. Groups

Current groups:

groups

Add user:

sudo useradd -m devops

Set password:

sudo passwd devops

Add to group:

sudo usermod -aG docker devops

List groups:

getent group

18. sudo

sudo allows authorized users to execute commands with elevated privileges.

Example:

sudo systemctl restart nginx

Configuration:

/etc/sudoers

Edit safely:

sudo visudo

19. Processes

List processes:

ps

All processes:

ps aux

Tree:

pstree

Interactive:

top

Better interactive monitor:

htop

20. Process IDs

Every process has PID.

ps aux

Find process:

pgrep nginx

Process details:

ps -p 1234

21. kill

Terminate:

kill 1234

Force:

kill -9 1234

Important signals:

SIGTERM = 15
SIGKILL = 9
SIGHUP  = 1
SIGINT  = 2

Prefer:

kill PID

before:

kill -9 PID

because SIGTERM allows graceful shutdown।

22. Background Processes

Run background:

command &

Jobs:

jobs

Bring foreground:

fg

Background:

bg

Detach process:

nohup command &

23. System Monitoring

CPU:

top

Memory:

free -h

Disk:

df -h

Directory size:

du -sh directory/

Load average:

uptime

System information:

uname -a

CPU:

lscpu

Memory:

free -h

24. Load Average

Check:

uptime

Example:

load average: 1.20, 0.80, 0.50

এগুলো সাধারণত:

1 minute
5 minutes
15 minutes

load average।

Interview-এ মনে রাখবে:

Load average শুধু CPU utilization নয়; runnable এবং কিছু ক্ষেত্রে uninterruptible tasks-এর চাপও reflect করতে পারে।

25. Package Management

Ubuntu/Debian:

sudo apt update
sudo apt install nginx
sudo apt remove nginx

RHEL/Fedora:

dnf install nginx

Arch:

sudo pacman -S nginx

Package query:

pacman -Qs nginx

DevOps engineer-এর জন্য distribution অনুযায়ী package manager জানা useful।

26. Environment Variables

Show:

env

Specific:

echo $PATH

Set:

export APP_ENV=production

Check:

echo $APP_ENV

Permanent shell variable সাধারণত:

~/.bashrc
~/.zshrc

server/application configuration-এর ক্ষেত্রে environment variables খুব গুরুত্বপূর্ণ।

27. PATH

Check:

echo $PATH

কোন executable কোথায়:

which python

আরও reliable:

command -v python

PATH-এর প্রতিটি directory:

echo $PATH | tr ':' '\n'

28. Bash Scripting

Basic:

#!/bin/bash

echo "Hello DevOps"

Variable:

NAME="DevOps"

echo "$NAME"

Condition:

if [ -f app.log ]; then
    echo "File exists"
fi

Loop:

for file in *.log; do
    echo "$file"
done

Function:

backup() {
    echo "Running backup"
}

29. Exit Codes

শেষ command-এর exit code:

echo $?

Generally:

0 = success
non-zero = failure

Script:

command

if [ $? -ne 0 ]; then
    echo "Command failed"
fi

Better:

if ! command; then
    echo "Failed"
fi

Production scripts:

set -euo pipefail

এর meaning বুঝতে হবে।

30. awk

Column processing:

awk '{print $1}' file.txt

Example:

ps aux | awk '{print $1, $2}'

Useful for:

logs
metrics
CSV-like text
command output

31. sed

Text replacement:

sed 's/old/new/g' file.txt

Delete line:

sed '3d' file.txt

Configuration automation-এ sed frequently দেখা যায়।

32. cut

echo "devops:linux:docker" | cut -d ':' -f 1

Output:

devops

33. sort

sort file.txt

Reverse:

sort -r file.txt

Numeric:

sort -n numbers.txt

34. uniq

sort file.txt | uniq

Count:

sort file.txt | uniq -c

35. Networking Fundamentals

DevOps-এর জন্য networking অবশ্যই জানতে হবে।

শিখতে হবে:

IP
MAC
TCP
UDP
HTTP
HTTPS
DNS
DHCP
NAT
Routing
Ports
Sockets
Firewall

36. IP Address

IPv4 example:

192.168.1.10

Private ranges:

10.0.0.0/8

172.16.0.0/12

192.168.0.0/16

Interface:

ip addr

Short:

ip a

37. Routing

Routes:

ip route

Default route:

default via 192.168.1.1

Important interview concept:

Default gateway হলো এমন router যেখানে system unknown destinations-এর traffic পাঠায়।

38. Connectivity

Ping:

ping google.com

Trace:

traceroute google.com

বা:

tracepath google.com

39. Ports

Listening ports:

ss -tulpn

Specific port:

ss -lntp | grep :8000

Common ports:

22   SSH
53   DNS
80   HTTP
443  HTTPS
3306 MySQL
5432 PostgreSQL
6379 Redis
8000 FastAPI
8080 Common HTTP alternative

40. DNS

DNS domain → IP resolve করে।

Check:

dig google.com

বা:

nslookup google.com

Simple:

getent hosts google.com

DNS configuration:

/etc/resolv.conf

Hosts:

/etc/hosts

41. curl

HTTP request:

curl https://example.com

Headers:

curl -I https://example.com

POST:

curl -X POST \
  -H "Content-Type: application/json" \
  -d '{"name":"Ragib"}' \
  http://localhost:8000/predict

DevOps troubleshooting-এর জন্য curl অত্যন্ত গুরুত্বপূর্ণ।

42. wget

Download:

wget https://example.com/file.zip

43. SSH

Remote server access:

ssh user@server-ip

Specific key:

ssh -i key.pem user@server-ip

SSH config:

~/.ssh/config

44. SSH Keys

Generate:

ssh-keygen -t ed25519

Public key:

~/.ssh/id_ed25519.pub

Private key:

~/.ssh/id_ed25519

Private key কখনো share বা Git repository-তে commit করা যাবে না।

45. SCP

Copy local → remote:

scp file.txt user@server:/tmp/

Remote → local:

scp user@server:/tmp/file.txt .

46. rsync

Efficient synchronization:

rsync -av project/ server:/backup/project/

Delete destination extras:

rsync -av --delete source/ destination/

Production backup/deployment workflows-এ useful।

47. Compression

tar:

tar -cvf archive.tar directory/

Extract:

tar -xvf archive.tar

gzip:

tar -czvf archive.tar.gz directory/

Extract:

tar -xzvf archive.tar.gz

48. Disk Management

Disk usage:

df -h

Directory:

du -sh /var/*

Block devices:

lsblk

Partitions:

sudo fdisk -l

49. Mount

Mount filesystem:

sudo mount /dev/sdb1 /mnt

Unmount:

sudo umount /mnt

Persistent mounts:

/etc/fstab

50. Inodes

Filesystem শুধু file size দিয়ে manage করে না; inode-ও ব্যবহার করে।

Check:

df -i

Possible problem:

Disk space available
BUT
Inodes exhausted

তখন নতুন file তৈরি করতে সমস্যা হতে পারে।

51. `/proc`

/proc virtual filesystem।

Process:

/proc/<PID>/

CPU:

/proc/cpuinfo

Memory:

/proc/meminfo

Uptime:

/proc/uptime

52. `/dev`

Device files।

Examples:

/dev/sda
/dev/nvme0n1
/dev/null
/dev/zero

/dev/null:

command > /dev/null

53. `/dev/null`

Anything written এখানে discard হয়।

echo "hello" > /dev/null

Suppress output:

command > /dev/null 2>&1

54. systemd

Modern Linux systems-এ systemd service manager হিসেবে ব্যবহৃত হয়।

Service status:

systemctl status nginx

Start:

sudo systemctl start nginx

Stop:

sudo systemctl stop nginx

Restart:

sudo systemctl restart nginx

Enable on boot:

sudo systemctl enable nginx

Disable:

sudo systemctl disable nginx

55. systemd Logs

journalctl

Specific service:

journalctl -u nginx

Follow:

journalctl -u nginx -f

Recent:

journalctl --since "1 hour ago"

Boot logs:

journalctl -b

56. Linux Logs

Common location:

/var/log/

Examples:

/var/log/syslog
/var/log/auth.log
/var/log/nginx/

Distribution অনুযায়ী filenames ভিন্ন হতে পারে।

57. Log Rotation

Long-running production systems-এ logs unlimited growth করলে disk full হতে পারে।

Concepts:

logrotate
rotation
compression
retention

Configuration:

/etc/logrotate.conf
/etc/logrotate.d/

58. Cron

Scheduled jobs।

Edit:

crontab -e

Format:

minute hour day month weekday command

Example:

0 2 * * * /home/user/backup.sh

মানে প্রতিদিন রাত ২টায়।

59. Linux Security

Must know:

Users
Groups
Permissions
sudo
SSH
Firewall
SELinux/AppArmor
Secrets
Updates
Least privilege

60. Firewall

Common tools:

ufw
firewalld
nftables
iptables

Ubuntu example:

sudo ufw status

Allow SSH:

sudo ufw allow 22

Allow HTTP:

sudo ufw allow 80

61. SELinux / AppArmor

Linux security frameworks।

Know the concepts:

Mandatory Access Control
Policies
Security Context
Least Privilege

RHEL ecosystem-এ SELinux গুরুত্বপূর্ণ।

Ubuntu-তে AppArmor commonly দেখা যায়।

62. Web Server Basics

Popular:

Nginx
Apache

Nginx can act as:

Web Server
Reverse Proxy
Load Balancer
TLS Termination

63. Reverse Proxy

Architecture:

Client
  ↓
Nginx
  ↓
FastAPI
  ↓
ML Model

Nginx backend-এর সামনে থাকে।

Benefits:

TLS termination
routing
load balancing
buffering
security controls

64. Linux + Docker

Docker Linux-এর নিচের অনেক core concept ব্যবহার করে:

Namespaces
cgroups
filesystem layers
networking
process isolation
capabilities

তাই Docker শেখার আগে Linux fundamentals শক্ত হওয়া খুব useful।

65. Docker-এর জন্য Linux Knowledge

বিশেষভাবে জানতে হবে:

Process
PID
Namespace
cgroups
Filesystem
permissions
networking
ports
mounts
signals

Container-এর ভিতরের process সাধারণত host-এর kernel ব্যবহার করে।

66. Linux + Kubernetes

Kubernetes node troubleshooting-এর জন্য:

ps
top
free
df
du
ss
ip
journalctl
systemctl
curl
grep

খুব ভালোভাবে জানতে হবে।

67. Kubernetes Troubleshooting Example

Pod:

CrashLoopBackOff

তখন:

kubectl logs pod-name
kubectl describe pod pod-name

কিন্তু underlying node problem হলে Linux:

journalctl
df -h
free -h
top
systemctl

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

68. CPU Troubleshooting

Problem:

CPU = 100%

Check:

top

বা:

htop

Process:

ps aux --sort=-%cpu | head

তারপর determine করতে হবে:

Which process?
Why?
Application issue?
Infinite loop?
Too much traffic?
CPU throttling?

69. Memory Troubleshooting

Check:

free -h

Processes:

ps aux --sort=-%mem | head

OOM-related logs:

dmesg | grep -i oom

বা:

journalctl | grep -i oom

70. Disk Full Troubleshooting

প্রথম:

df -h

তারপর:

du -sh /*

Specific:

du -sh /var/*

Large files:

find /var -type f -size +1G

Check inode:

df -i

Potential causes:

Huge logs
Docker images
Docker volumes
Deleted-but-open files
Temporary files
Backups

71. Deleted File Still Using Disk

একটি process file delete করার পরেও file descriptor open রাখতে পারে।

Check:

lsof +L1

এটা production troubleshooting interview-এ useful scenario।

72. Port Already in Use

Error:

Address already in use

Check:

ss -lntp | grep :8000

বা:

lsof -i :8000

Process identify করে graceful stop করতে হবে।

73. Service Not Starting

ধাপ:

systemctl status service

তারপর:

journalctl -u service

তারপর:

systemctl cat service

তারপর configuration validate।

74. Server Reachable কিন্তু Website কাজ করছে না

Layer-by-layer troubleshoot:

1. DNS
2. Network
3. Port
4. Firewall
5. Web server
6. Reverse proxy
7. Application
8. Database

Commands:

dig domain.com
ping server
ss -lntp
curl localhost
curl backend:8000

75. HTTP Status Codes

Must know:

200 OK
201 Created
204 No Content

301/302 Redirect

400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
405 Method Not Allowed
408 Request Timeout
409 Conflict
429 Too Many Requests

500 Internal Server Error
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout

76. 502 vs 503 vs 504

502 Bad Gateway

Proxy backend থেকে valid response পায়নি।

503 Service Unavailable

Service available নয় বা overloaded হতে পারে।

504 Gateway Timeout

Upstream response দিতে বেশি সময় নিয়েছে।

DevOps interview-এ এগুলোর পার্থক্য জানা গুরুত্বপূর্ণ।

77. TCP vs UDP

TCP

Connection-oriented
Reliable
Ordered
Retransmission

UDP

Connectionless
Lower overhead
No guaranteed delivery
Faster for suitable workloads

Examples:

TCP → HTTP/HTTPS, SSH
UDP → DNS queries commonly, streaming/real-time workloads

78. TCP Connection States

Know:

LISTEN
SYN-SENT
SYN-RECEIVED
ESTABLISHED
FIN-WAIT
TIME-WAIT
CLOSE-WAIT

Check:

ss -tan

79. TIME_WAIT

Connection close হওয়ার পর TCP কিছু সময় state ধরে রাখে যাতে delayed packets সমস্যা না করে।

High traffic systems-এ অনেক TIME_WAIT দেখা যেতে পারে।

Interview-এ শুধু “TIME_WAIT is bad” বলা ভুল।

80. File Descriptors

Linux-এ process files, sockets ইত্যাদি file descriptors হিসেবে handle করে।

Check limits:

ulimit -n

Process open files:

lsof -p PID

81. Hard Link vs Soft Link

Soft link:

ln -s original.txt link.txt

Hard link:

ln original.txt hardlink.txt

Soft link

আলাদা inode
target-এর path reference করে
target delete হলে broken হতে পারে

Hard link

একই inode
একই filesystem-এর মধ্যে সাধারণত
original filename delete হলেও data থাকতে পারে

82. Symbolic Links in DevOps

Common examples:

/etc/nginx/sites-enabled/

Configuration management এবং system files-এ symbolic links দেখতে পাবে।

83. Process vs Thread

Process

Independent execution context।

Thread

একই process-এর মধ্যে execution unit।

Threads সাধারণত একই process-এর memory share করে।

84. Zombie Process

Parent process child-এর exit status collect না করলে zombie process হতে পারে।

Check:

ps aux | grep Z

Zombie kill করার বদলে সাধারণত parent process-এর issue investigate করতে হয়।

85. Orphan Process

Parent process terminate হলে child orphan হতে পারে এবং system-এর init/systemd process তাকে adopt করতে পারে।

86. Context Switching

CPU এক execution context থেকে অন্যটিতে switch করে।

Too many processes/threads context-switch overhead তৈরি করতে পারে।

Tools:

vmstat
pidstat

87. vmstat

vmstat 1

Useful for:

CPU
memory
swap
processes
I/O
context switching

88. iostat

Disk I/O troubleshooting:

iostat

Useful metrics:

IOPS
throughput
utilization
latency

89. sar

Historical/current system performance statistics-এর জন্য useful।

sar

CPU:

sar -u

Memory:

sar -r

Network:

sar -n DEV

90. Network Troubleshooting Toolkit

Must know:

ip
ss
ping
traceroute
tracepath
dig
nslookup
curl
wget
nc
tcpdump

91. netcat

Port testing:

nc -zv server 8000

Useful for checking TCP connectivity।

92. tcpdump

Packet capture:

sudo tcpdump -i any port 8000

HTTP traffic investigation:

sudo tcpdump -i any host 10.0.0.5

Advanced networking troubleshooting-এর জন্য গুরুত্বপূর্ণ।

93. Linux Security Checklist

Production server:

[ ] Disable unnecessary services
[ ] Use SSH keys
[ ] Avoid root login
[ ] Use least privilege
[ ] Keep packages updated
[ ] Configure firewall
[ ] Protect secrets
[ ] Monitor logs
[ ] Rotate credentials
[ ] Backup critical data

94. DevOps-এ Linux-এর সবচেয়ে গুরুত্বপূর্ণ Commands

এই commandগুলো মুখস্থ না হলেও confidently ব্যবহার করতে পারতে হবে:

pwd
ls
cd
cp
mv
rm
mkdir
touch
cat
less
head
tail
grep
find
awk
sed
cut
sort
uniq
chmod
chown
sudo
ps
top
htop
kill
pkill
pgrep
free
df
du
lsblk
mount
ip
ss
ping
curl
wget
dig
nc
tcpdump
ssh
scp
rsync
tar
systemctl
journalctl
crontab
lsof
uname
uptime

95. Production Troubleshooting Method

কখনো random command চালানো উচিত নয়।

এই framework follow করবে:

1. Identify the symptom
        ↓
2. Determine scope
        ↓
3. Check recent changes
        ↓
4. Check logs
        ↓
5. Check metrics
        ↓
6. Check resource usage
        ↓
7. Check network
        ↓
8. Reproduce if possible
        ↓
9. Fix
        ↓
10. Verify
        ↓
11. Document

96. DevOps Incident Example

Problem

Application suddenly slow।

Step 1

Check CPU:

top

Step 2

Memory:

free -h

Step 3

Disk:

df -h

Step 4

Network:

ss -s

Step 5

Application logs:

journalctl -u app

Step 6

Recent deployment:

What changed?

Step 7

Check upstream/database.

এভাবে systematic troubleshooting করতে হবে।

97. Linux + ML Inference Platform

তোমার ML inference project-এ Linux knowledge সরাসরি লাগবে।

Architecture:

Linux Server
    ↓
Docker
    ↓
Kubernetes
    ↓
FastAPI
    ↓
ML Model

Troubleshooting:

High CPU
    ↓
top

High memory
    ↓
free / ps

Disk full
    ↓
df / du

Port issue
    ↓
ss

Service issue
    ↓
systemctl / journalctl

Network issue
    ↓
ip / ss / curl / dig

Container issue
    ↓
docker logs / docker stats

98. Interview Preparation — Basic Questions

Q1. Linux কী?

Linux একটি open-source Unix-like operating system kernel; Linux distributions kernel-এর সাথে user-space tools ও package ecosystem প্রদান করে।

Q2. Kernel কী?

Kernel hardware এবং applications-এর মধ্যে প্রধান interface হিসেবে কাজ করে এবং CPU, memory, processes, devices ও networking-এর মতো resources manage করে।

Q3. Linux-এ `/etc` কী?

System configuration files-এর প্রধান directory।

Q4. `/var` কী?

Variable data যেমন logs, caches এবং application state-এর জন্য ব্যবহৃত হয়।

Q5. Process কী?

Running program-এর একটি execution instance।

Q6. PID কী?

Process Identifier।

Q7. `kill -9` কী করে?

SIGKILL পাঠায়। Process graceful cleanup করার সুযোগ পায় না।

Q8. `chmod 755` কী?

Owner  = rwx
Group  = r-x
Other  = r-x

Q9. `chmod 644` কী?

Owner  = rw-
Group  = r--
Other  = r--

Q10. `sudo` কী?

Authorized user-কে privileged command execute করার সুযোগ দেয়।

99. Intermediate Interview Questions

Q11. Hard link এবং soft link-এর difference?

Hard link একই inode-এর দিকে নির্দেশ করে; symbolic link একটি path reference করে এবং আলাদা inode ব্যবহার করে।

Q12. Zombie process কী?

Child process terminate করেছে কিন্তু parent তার exit status collect করেনি—তখন zombie state হতে পারে।

Q13. Load average কী?

System-এর runnable এবং কিছু uninterruptible work-এর queue/load-এর একটি time-windowed indication।

Q14. `/proc` কী?

Kernel এবং process information expose করা virtual filesystem।

Q15. `df` এবং `du` difference?

df → filesystem-level disk usage
du → directory/file-level usage

Q16. `systemctl` কী?

systemd-managed services এবং system state control করার command।

Q17. `journalctl` কী?

systemd journal-এর logs query করার tool।

Q18. `ss` কী?

Network sockets এবং listening connections inspect করার tool।

100. Advanced Interview Questions

Q19. Linux-এ একটি process CPU 100% ব্যবহার করলে কীভাবে troubleshoot করবে?

top/htop
   ↓
identify PID
   ↓
ps
   ↓
inspect process
   ↓
logs
   ↓
application behavior
   ↓
profiling/metrics

Q20. Disk 100% full। কী করবে?

df -h
du -sh /*
find /var -type f -size +1G
df -i
lsof +L1

তারপর identify করে safe cleanup।

Q21. Port 8080 already in use। কী করবে?

ss -lntp | grep :8080

অথবা:

lsof -i :8080

তারপর owning process identify করে root cause অনুযায়ী ব্যবস্থা নেব।

Q22. Server ping করা যাচ্ছে কিন্তু application access করা যাচ্ছে না। কেন?

Possible layers:

DNS
Firewall
Port
Service
Application
Reverse Proxy
Routing
Security Group

Q23. Nginx 502 দিচ্ছে। কীভাবে troubleshoot করবে?

Nginx status
    ↓
Nginx logs
    ↓
Backend service
    ↓
Backend port
    ↓
curl backend directly
    ↓
Application logs

Q24. Memory শেষ হয়ে গেলে Linux কী করতে পারে?

System swap ব্যবহার করতে পারে; extreme memory pressure-এ OOM killer process terminate করতে পারে।

Q25. Docker container-এর Linux process কেন host-এর kernel ব্যবহার করে?

Containers সাধারণত full VM নয়; Linux kernel-এর isolation primitives যেমন namespaces এবং cgroups ব্যবহার করে process/environment isolate করে।

101. Scenario-Based Interview

Scenario 1

Production API suddenly returning 500.

তুমি বলবে:

1. Check application logs
2. Check recent deployment
3. Check dependencies
4. Check CPU/memory/disk
5. Check database/network
6. Reproduce request
7. Rollback if necessary
8. Verify recovery

Scenario 2

API latency suddenly increased.

Check:

CPU
Memory
Load
Network
Disk I/O
Database latency
Upstream services
Application logs
Recent changes

Scenario 3

Server disk full.

Check:

df -h
du -sh /var/*
df -i
lsof +L1

Common causes:

Logs
Docker
Backups
Temporary files
Deleted open files

Scenario 4

Kubernetes Pod বারবার restart করছে।

Linux-level এবং Kubernetes-level দুটো দিক:

kubectl logs
kubectl describe pod
        ↓
Application logs
        ↓
OOM?
CPU?
Configuration?
Dependency?
        ↓
Node health
        ↓
journalctl

102. Hands-on Lab 1 — Linux Server

একটি VM বা cloud server তৈরি করে:

Ubuntu

Install:

nginx
git
docker
curl
htop

তারপর:

SSH করো
user তৈরি করো
permissions change করো
Nginx চালাও
logs দেখো
port check করো

103. Hands-on Lab 2 — Nginx

Install:

sudo apt install nginx

Check:

systemctl status nginx

Test:

curl localhost

Port:

ss -lntp | grep :80

Logs:

journalctl -u nginx

104. Hands-on Lab 3 — Deploy FastAPI

Flow:

Linux VM
   ↓
Python
   ↓
FastAPI
   ↓
Uvicorn
   ↓
Nginx
   ↓
Internet

এটা তোমার ML inference platform-এর foundation হিসেবে ব্যবহার করতে পারো।

105. Hands-on Lab 4 — Monitoring

একটি application চালিয়ে:

top
free -h
df -h
ss -lntp

observe করবে।

তারপর artificial load তৈরি করে CPU/memory behavior দেখবে।

106. Hands-on Lab 5 — Bash Automation

একটি script বানাও:

backup.sh

যা:

1. Application directory backup করবে
2. Timestamp যোগ করবে
3. tar.gz বানাবে
4. পুরনো backup delete করবে
5. success/failure log করবে

তারপর cron দিয়ে schedule করো।

107. Hands-on Lab 6 — Linux Troubleshooting

নিজে intentionally problem তৈরি করো:

Stop nginx
Kill application
Fill temporary disk
Block a port
Wrong permissions
Wrong environment variable
Wrong DNS entry

তারপর নিজে troubleshoot করো।

এটা interview preparation-এর জন্য সবচেয়ে valuable exerciseগুলোর একটি।

108. DevOps Linux Skill Matrix

Topic	Priority
Linux basics	⭐⭐⭐⭐⭐
Filesystem	⭐⭐⭐⭐⭐
Permissions	⭐⭐⭐⭐⭐
Users/Groups	⭐⭐⭐⭐⭐
Processes	⭐⭐⭐⭐⭐
Networking	⭐⭐⭐⭐⭐
SSH	⭐⭐⭐⭐⭐
systemd	⭐⭐⭐⭐⭐
Logs	⭐⭐⭐⭐⭐
Bash	⭐⭐⭐⭐⭐
Docker/Linux relationship	⭐⭐⭐⭐⭐
Troubleshooting	⭐⭐⭐⭐⭐
Disk/storage	⭐⭐⭐⭐
Security	⭐⭐⭐⭐
DNS	⭐⭐⭐⭐
TCP/IP	⭐⭐⭐⭐
Nginx	⭐⭐⭐⭐
cron	⭐⭐⭐
awk/sed	⭐⭐⭐
tcpdump	⭐⭐⭐
SELinux/AppArmor	⭐⭐⭐

109. 30-Day Linux → DevOps Foundation Plan

Week 1 — Linux Basics

Day 1
Linux + filesystem

Day 2
Navigation + file management

Day 3
Permissions + ownership

Day 4
Users + groups + sudo

Day 5
Processes + signals

Day 6
Package management

Day 7
Revision + practical lab

Week 2 — Linux Administration

Day 8
Environment variables

Day 9
Bash basics

Day 10
grep + pipes

Day 11
awk + sed

Day 12
systemd

Day 13
journalctl + logs

Day 14
cron + automation

Week 3 — Networking + Storage

Day 15
IP + subnet basics

Day 16
TCP/UDP + ports

Day 17
DNS

Day 18
SSH

Day 19
curl + wget + nc

Day 20
Disk + filesystem

Day 21
mount + inode + troubleshooting

Week 4 — DevOps Linux

Day 22
Nginx

Day 23
Reverse proxy

Day 24
Linux security

Day 25
Docker + Linux

Day 26
Kubernetes + Linux

Day 27
Performance troubleshooting

Day 28
Production troubleshooting

Day 29
Interview preparation

Day 30
Complete practical project

110. Final Linux Project

একটি complete mini-production environment বানাও:

                    Internet
                       |
                       v
                    Nginx
                       |
                       v
                   FastAPI
                       |
                       v
                  ML Model
                       |
                  +----+----+
                  |         |
                Logs      Metrics

Server-এ:

Ubuntu
Nginx
FastAPI
systemd
SSH
Firewall
Bash
cron
logging
monitoring

Implement:

[ ] SSH authentication
[ ] Non-root application user
[ ] FastAPI service
[ ] systemd service
[ ] Nginx reverse proxy
[ ] HTTPS
[ ] firewall
[ ] log rotation
[ ] backup script
[ ] cron
[ ] monitoring
[ ] troubleshooting documentation

111. Final Interview Checklist

Interview-এর আগে confidently explain করতে পারবে:

Linux

[ ] Linux architecture
[ ] Kernel
[ ] Filesystem
[ ] /etc
[ ] /var
[ ] /proc
[ ] permissions
[ ] users/groups
[ ] sudo

Processes

[ ] PID
[ ] signals
[ ] zombie
[ ] orphan
[ ] process vs thread
[ ] CPU troubleshooting
[ ] memory troubleshooting

Networking

[ ] IP
[ ] subnet
[ ] routing
[ ] TCP/UDP
[ ] DNS
[ ] ports
[ ] sockets
[ ] HTTP/HTTPS
[ ] firewall

Administration

[ ] SSH
[ ] systemd
[ ] journalctl
[ ] cron
[ ] package management
[ ] storage
[ ] mount
[ ] inode

DevOps

[ ] Linux + Docker
[ ] Linux + Kubernetes
[ ] Nginx
[ ] reverse proxy
[ ] Bash automation
[ ] monitoring
[ ] troubleshooting
[ ] security

🎯 Final Goal

Linux শেখার উদ্দেশ্য শুধু command মুখস্থ করা নয়।

তোমার goal হবে:

"I can operate and troubleshoot a Linux production server."

তারপর:

Linux
   ↓
Git
   ↓
Docker
   ↓
Kubernetes
   ↓
Terraform
   ↓
GitHub Actions
   ↓
ArgoCD
   ↓
Prometheus/Grafana
   ↓
Production DevOps

Linux-এর ক্ষেত্রে বিশেষ করে command মুখস্থ করার চেয়ে troubleshooting skill বেশি গুরুত্বপূর্ণ।

একজন DevOps engineer হিসেবে তুমি যেন একটি সমস্যা দেখে বলতে পারো:

What is broken?
        ↓
Where is it broken?
        ↓
Why is it broken?
        ↓
How can I verify it?
        ↓
How can I fix it safely?
        ↓
How can I prevent it from happening again?

এটাই এই Linux roadmap-এর মূল লক্ষ্য।

A Complete Guide to Writing Dockerfiles from Beginner to Production

Ragib Hasan — Mon, 07 Sep 2026 19:37:15 +0000

Docker শিখতে গেলে সবচেয়ে গুরুত্বপূর্ণ জিনিসগুলোর একটি হলো Dockerfile।

অনেকে Dockerfile-কে শুধু কয়েকটি command-এর file হিসেবে দেখে:

FROM node:22
COPY . .
RUN npm install
CMD ["npm", "start"]

কিন্তু আসলে Dockerfile-এর প্রতিটি instruction-এর পেছনে একটি নির্দিষ্ট ধারণা আছে।

কেন FROM লাগবে?

COPY আর ADD-এর পার্থক্য কী?

RUN আর CMD কি একই জিনিস?

CMD এবং ENTRYPOINT কখন ব্যবহার করব?

ARG আর ENV কখন?

কেন COPY package*.json ./ আগে লিখলে build অনেক দ্রুত হয়?

.dockerignore কেন গুরুত্বপূর্ণ?

Production-এ কেন multi-stage build ব্যবহার করা হয়?

এই blog-এর শেষে তুমি শুধু Dockerfile পড়তে পারবে না—নিজে requirement দেখে Dockerfile design করতে পারবে।

1. Dockerfile আসলে কী?

সহজ ভাষায়:

Dockerfile হলো একটি text file যেখানে Docker image কীভাবে তৈরি হবে তার instructions লেখা থাকে।

উদাহরণ:

FROM python:3.12

WORKDIR /app

COPY . .

RUN pip install -r requirements.txt

CMD ["python", "app.py"]

Docker এই instructions-গুলো উপর থেকে নিচে execute করে image তৈরি করে। Docker-এর documentation অনুযায়ী Dockerfile একটি ordered set of instructions, এবং প্রতিটি instruction build-এর অংশ তৈরি করে।

একটি সাধারণ flow:

Dockerfile
     ↓
docker build
     ↓
Docker Image
     ↓
docker run
     ↓
Container

2. Dockerfile এবং Docker Image-এর সম্পর্ক

ধরো তোমার কাছে একটি Python application আছে।

তুমি Dockerfile লিখলে:

FROM python:3.12

WORKDIR /app

COPY . .

RUN pip install -r requirements.txt

CMD ["python", "app.py"]

তারপর:

docker build -t my-python-app .

এখানে Docker:

Dockerfile
   ↓
FROM
   ↓
WORKDIR
   ↓
COPY
   ↓
RUN
   ↓
CMD
   ↓
Image

তৈরি করবে।

তারপর:

docker run my-python-app

Image থেকে container তৈরি হবে।

3. Dockerfile-এর basic structure

একটি সাধারণ Dockerfile-এর structure:

FROM base-image

WORKDIR /app

COPY files .

RUN commands

ENV VARIABLE=value

EXPOSE 8000

USER appuser

CMD ["command"]

সব Dockerfile-এ সব instruction থাকতে হবে—এমন নয়।

4. Dockerfile-এর সবচেয়ে গুরুত্বপূর্ণ instructions

Dockerfile-এ অনেক instruction আছে। সবচেয়ে বেশি যেগুলো ব্যবহার করবে:

FROM
RUN
COPY
ADD
WORKDIR
ENV
ARG
EXPOSE
USER
CMD
ENTRYPOINT
HEALTHCHECK
VOLUME
LABEL
SHELL
ONBUILD
STOPSIGNAL

Docker-এর official reference-এ এসব instruction-এর পাশাপাশি তাদের syntax ও behaviour বিস্তারিতভাবে দেওয়া আছে।

শেখার priority হিসেবে:

FROM
 ↓
WORKDIR
 ↓
COPY
 ↓
RUN
 ↓
ENV / ARG
 ↓
EXPOSE
 ↓
CMD
 ↓
ENTRYPOINT
 ↓
USER
 ↓
HEALTHCHECK
 ↓
Multi-stage build

5. FROM — Dockerfile-এর starting point

প্রায় সব সাধারণ Dockerfile শুরু হয়:

FROM image

উদাহরণ:

FROM ubuntu:24.04

অথবা:

FROM python:3.12

অথবা:

FROM node:22-alpine

FROM বলে:

"আমার image কোন existing image-এর উপর তৈরি হবে?"

Docker-এর নিয়ম অনুযায়ী FROM একটি নতুন build stage শুরু করে এবং সাধারণ Dockerfile-এ এটিই প্রথম মূল instruction। একাধিক FROM ব্যবহার করেও multi-stage build করা যায়।

6. Image tag কেন গুরুত্বপূর্ণ?

এটি দেখো:

FROM python

এখানে version নির্দিষ্ট করা হয়নি।

তার বদলে:

FROM python:3.12

আরও predictable।

আরও specific:

FROM python:3.12.6

তাহলে কোন version ব্যবহার হচ্ছে তা নির্দিষ্ট থাকে।

আরও reproducible build-এর জন্য image digest-ও ব্যবহার করা যায়:

FROM python:3.12@sha256:...

তবে beginner হিসেবে শুরু করো:

FROM python:3.12

7. Alpine image কী?

অনেক language-এর Alpine variant পাওয়া যায়:

FROM node:22-alpine

FROM python:3.12-alpine

Alpine সাধারণত ছোট base image হিসেবে ব্যবহৃত হয়।

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

"ছোট image" মানেই সব ক্ষেত্রে "best image" নয়।

কিছু package বা native dependency-এর ক্ষেত্রে Debian/Ubuntu-based image ব্যবহার করা সহজ হতে পারে।

তাই blindly alpine ব্যবহার না করে application compatibility পরীক্ষা করতে হবে।

8. WORKDIR — container-এর working directory

ধরো তুমি লিখলে:

WORKDIR /app

এর পরে পরবর্তী অনেক instruction-এর জন্য working directory হবে:

/app

উদাহরণ:

FROM python:3.12

WORKDIR /app

COPY . .

RUN pip install -r requirements.txt

এখানে:

WORKDIR /app

এর কারণে:

COPY . .

মানে বর্তমান working location হবে /app.

Docker-এর documentation-ও unintended directory-তে কাজ এড়াতে explicit WORKDIR ব্যবহারের best practice উল্লেখ করে।

9. WORKDIR path manually mkdir করতে হয়?

সাধারণত না।

এটি:

WORKDIR /app

প্রয়োজনে directory তৈরি করে ব্যবহার করে।

তাই সাধারণত:

RUN mkdir /app
WORKDIR /app

লেখার দরকার নেই।

10. COPY — local files image-এ নেওয়া

সবচেয়ে বেশি ব্যবহৃত instruction:

COPY source destination

উদাহরণ:

COPY . .

মানে:

build context-এর files বর্তমান working directory-তে copy করো।

আরেকটি উদাহরণ:

COPY app.py /app/

অথবা:

COPY requirements.txt .

11. COPY . . মানে কী?

এই line:

COPY . .

অনেক beginner-কে confuse করে।

ধরো project:

my-project/
├── Dockerfile
├── app.py
├── requirements.txt
└── config/
    └── settings.json

তুমি run করছ:

docker build -t myapp .

শেষের . হলো:

build context = current directory

তারপর Dockerfile-এ:

WORKDIR /app
COPY . .

ফলে image-এ হতে পারে:

/app/
├── Dockerfile
├── app.py
├── requirements.txt
└── config/
    └── settings.json

তবে .dockerignore থাকলে কিছু file বাদ যাবে।

12. Build context বুঝতেই হবে

এই command:

docker build -t myapp .

এখানে শেষের:

খুব গুরুত্বপূর্ণ।

এটি Docker-কে বলে:

"এই directory-কে build context হিসেবে ব্যবহার করো।"

তুমি যদি চালাও:

docker build -t myapp ./backend

তাহলে ./backend build context হবে।

সুতরাং Dockerfile-এ:

COPY . .

লিখলে . বলতে সেই build context-কে বোঝাবে।

13. .dockerignore

ধরো project directory-তে আছে:

node_modules/
.git/
.env
logs/
dist/
Dockerfile
README.md

সবকিছু Docker build context-এ পাঠানোর দরকার নেই।

তাই:

.dockerignore

file তৈরি করো।

উদাহরণ:

node_modules
.git
.env
*.log
dist
coverage

Docker-এর documentation অনুযায়ী .dockerignore build context থেকে files/directories বাদ দিতে ব্যবহার করা হয়।

14. কেন .dockerignore এত গুরুত্বপূর্ণ?

কারণ build context-এ unnecessary file পাঠালে:

Build slow
+
Large context
+
Potential secret exposure
+
Unnecessary data

ধরো:

node_modules = 500 MB

কিন্তু application build করতে এটি context-এ পাঠানোরই দরকার নেই, কারণ container-এর ভেতরে dependency install করা যেতে পারে।

তাই:

.dockerignore

node_modules
.git
.env

খুব সাধারণ এবং গুরুত্বপূর্ণ setup।

15. RUN — image build করার সময় command চালানো

RUN Dockerfile-এর অন্যতম গুরুত্বপূর্ণ instruction।

উদাহরণ:

RUN apt-get update

অথবা:

RUN pip install -r requirements.txt

অথবা:

RUN npm install

এগুলো image build-এর সময় execute হয়।

অর্থাৎ:

docker build .

চালানোর সময় RUN execute হবে।

16. RUN বনাম CMD

এখানে beginners-এর সবচেয়ে common confusion।

RUN

RUN npm install

মানে:

image build করার সময় npm install করো।

CMD

CMD ["npm", "start"]

মানে:

container চালু হলে default হিসেবে npm start execute করো।

অর্থাৎ:

docker build
    ↓
RUN
    ↓
Image তৈরি

docker run
    ↓
CMD / ENTRYPOINT
    ↓
Application start

17. RUN দিয়ে application start করা উচিত?

সাধারণত না।

খারাপ:

RUN npm start

কারণ এটি build-এর সময় application start করবে।

সঠিক:

RUN npm install

CMD ["npm", "start"]

18. RUN-এর command combine করা

ধরো:

RUN apt-get update

RUN apt-get install -y curl

RUN apt-get install -y git

করা যায়:

RUN apt-get update && \
    apt-get install -y curl git

এর ফলে Dockerfile clean থাকে এবং package-manager সম্পর্কিত state একই build step-এ handle করা যায়।

Debian/Ubuntu package installation-এর ক্ষেত্রে stale package index রেখে যাওয়ার বদলে update/install একসাথে করা সাধারণত ভালো practice:

RUN apt-get update && \
    apt-get install -y --no-install-recommends curl git && \
    rm -rf /var/lib/apt/lists/*

19. Shell form এবং Exec form

Dockerfile-এ command লেখার দুটি গুরুত্বপূর্ণ style আছে।

Shell form

RUN echo hello

CMD npm start

এগুলো shell-এর মাধ্যমে execute হতে পারে।

Exec form

CMD ["npm", "start"]

এখানে JSON-array style ব্যবহার করা হয়েছে।

বিশেষ করে CMD এবং ENTRYPOINT-এর ক্ষেত্রে exec form খুব গুরুত্বপূর্ণ।

Docker-এর official reference shell form ও exec form দুটোই আলাদা করে ব্যাখ্যা করে।

20. CMD — container-এর default command

উদাহরণ:

FROM python:3.12

WORKDIR /app

COPY . .

CMD ["python", "app.py"]

এখন:

docker run myapp

করলে:

python app.py

চলবে।

21. CMD overwrite করা যায়

ধরো:

CMD ["python", "app.py"]

কিন্তু তুমি চালালে:

docker run myapp python test.py

তাহলে default CMD পরিবর্তিত হয়ে নতুন command execute হতে পারে।

এই কারণেই CMD-কে সাধারণত:

default command

হিসেবে ভাবতে পারো।

22. ENTRYPOINT — container-এর executable

উদাহরণ:

ENTRYPOINT ["python", "app.py"]

এখন container-এর primary executable হিসেবে এটিকে ধরা হচ্ছে।

ENTRYPOINT এবং CMD একসঙ্গেও ব্যবহার করা যায়।

উদাহরণ:

ENTRYPOINT ["python"]
CMD ["app.py"]

এখন effectively:

python app.py

চলবে।

আর user command-line argument দিলে CMD অংশ replace হতে পারে।

23. CMD বনাম ENTRYPOINT

সহজ mental model:

ENTRYPOINT = আমি কী চালাব?
CMD        = default argument / default command কী?

একটি practical example:

ENTRYPOINT ["python"]
CMD ["app.py"]

Default:

python app.py

আর:

docker run myapp test.py

দিলে:

python test.py

হতে পারে।

24. কখন শুধু CMD ব্যবহার করব?

Simple application হলে:

CMD ["python", "app.py"]

যথেষ্ট হতে পারে।

25. কখন ENTRYPOINT ব্যবহার করব?

যখন container-কে একটি নির্দিষ্ট executable/tool হিসেবে package করতে চাও।

উদাহরণ:

ENTRYPOINT ["python"]
CMD ["app.py"]

অথবা:

ENTRYPOINT ["./server"]

26. ENV — runtime environment variable

উদাহরণ:

ENV APP_ENV=production

Container-এর মধ্যে:

APP_ENV=production

থাকবে।

আরেকটি:

ENV PORT=8080

Application এটি ব্যবহার করতে পারে।

27. ENV আর ARG-এর পার্থক্য

এটি অবশ্যই বুঝতে হবে।

ARG

ARG VERSION=1.0

ARG মূলত build-time variable।

Build করার সময়:

docker build --build-arg VERSION=2.0 .

দেওয়া যায়।

ENV

ENV APP_ENV=production

ENV image/container environment-এর অংশ।

সহজভাবে:

ARG → build-time
ENV → runtime environment

Docker-এর documentation অনুযায়ী ARG build-time variable, এবং এটি final container environment-এ automatically available নয়; ENV আলাদা behaviour রাখে।

28. ARG-এর গুরুত্বপূর্ণ security warning

এটা অত্যন্ত গুরুত্বপূর্ণ।

এভাবে secret দেওয়া উচিত নয়:

docker build \
  --build-arg API_KEY=secret123 \
  .

কারণ Docker documentation অনুযায়ী build arguments secrets pass করার জন্য recommended নয়; এগুলো image history বা build provenance-এ প্রকাশিত হতে পারে। Secret-এর জন্য BuildKit secret mounts ব্যবহার করা উচিত।

অর্থাৎ:

ARG ≠ Secret storage

29. ENV-এও password রাখা উচিত?

এটিও avoid করা উচিত।

খারাপ:

ENV DB_PASSWORD=supersecret

Credentials management-এর জন্য environment variables, secret manager, Docker secrets অথবা orchestration platform-এর secret mechanism ব্যবহার করা উচিত—application ও deployment environment অনুযায়ী।

30. EXPOSE — port সম্পর্কে documentation

উদাহরণ:

EXPOSE 8080

এর মানে:

Application এই container port-এ listen করার কথা।

কিন্তু EXPOSE নিজে host port publish করে না।

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

31. EXPOSE বনাম -p

Dockerfile:

EXPOSE 8080

কিন্তু run:

docker run -p 8080:8080 myapp

এখানে:

Host:8080
     ↓
Container:8080

হচ্ছে।

অর্থাৎ:

EXPOSE = metadata/documentation
-p      = actual port publishing

32. USER — container কোন user হিসেবে চলবে

Default ভাবে অনেক base image-এ root user থাকতে পারে।

Production-এর জন্য non-root user ব্যবহার করা security-এর দিক থেকে ভালো practice।

উদাহরণ:

RUN useradd -m appuser

USER appuser

এর পরে container-এর process appuser হিসেবে চলবে।

তবে application-এর file permission ঠিকভাবে configure করতে হবে।

33. LABEL — image metadata

উদাহরণ:

LABEL maintainer="example"
LABEL version="1.0"

অথবা:

LABEL org.opencontainers.image.source="https://github.com/example/project"

Metadata রাখতে useful।

34. HEALTHCHECK

Container process চলছে মানেই application healthy—এমন নয়।

ধরো application process চলছে:

PID exists ✅

কিন্তু HTTP server response দিচ্ছে না:

Application ❌

তাই HEALTHCHECK ব্যবহার করা যায়।

উদাহরণ:

HEALTHCHECK --interval=30s --timeout=5s \
  CMD curl -f http://localhost:8080/health || exit 1

তখন Docker application-এর health যাচাই করতে পারে।

35. ADD — কেন আলাদা?

ADD এবং COPY দেখতে কাছাকাছি।

উদাহরণ:

COPY app.py /app/

সাধারণ local file copy-এর ক্ষেত্রে:

COPY-কে default choice হিসেবে ব্যবহার করো।

ADD কিছু অতিরিক্ত behaviour দেয়, যেমন archive extraction এবং remote URL-related capabilities। Docker-এর reference-এ ADD এবং COPY আলাদা instruction হিসেবে defined।

সাধারণ application-এর জন্য:

COPY

বেশিরভাগ সময় যথেষ্ট।

36. প্রথম একটি Python Dockerfile

ধরো project:

project/
├── Dockerfile
├── requirements.txt
└── app.py

app.py:

print("Hello Docker")

Dockerfile:

FROM python:3.12

WORKDIR /app

COPY requirements.txt .

RUN pip install --no-cache-dir -r requirements.txt

COPY . .

CMD ["python", "app.py"]

Build:

docker build -t hello-python .

Run:

docker run hello-python

Output:

Hello Docker

37. এই Dockerfile কীভাবে কাজ করল?

লাইন ধরে:

FROM python:3.12

Python environment নিলাম।

WORKDIR /app

working directory /app করলাম।

COPY requirements.txt .

শুধু dependency file copy করলাম।

RUN pip install --no-cache-dir -r requirements.txt

dependency install করলাম।

COPY . .

application code copy করলাম।

CMD ["python", "app.py"]

container start হলে application চালালাম।

এটাই Dockerfile-এর fundamental pattern:

Base
 ↓
Directory
 ↓
Dependencies
 ↓
Application
 ↓
Start command

38. Node.js Dockerfile

Project:

project/
├── Dockerfile
├── package.json
├── package-lock.json
└── src/
    └── index.js

Dockerfile:

FROM node:22-alpine

WORKDIR /app

COPY package*.json ./

RUN npm ci

COPY . .

EXPOSE 3000

CMD ["node", "src/index.js"]

39. কেন package.json আগে copy করা হলো?

এই pattern:

COPY package*.json ./
RUN npm ci
COPY . .

খুব গুরুত্বপূর্ণ।

কারণ Docker build cache reuse করতে পারে।

ধরো তুমি শুধু:

src/index.js

পরিবর্তন করেছ।

যদি dependency file অপরিবর্তিত থাকে, Docker cached dependency installation reuse করতে পারে।

Docker-এর build cache instruction/layer reuse করে, এবং একটি layer invalidated হলে পরবর্তী layers-ও rebuild হতে পারে।

তাই:

খারাপ pattern:

COPY . .

RUN npm ci

আর সাধারণভাবে ভালো pattern:

COPY package*.json ./

RUN npm ci

COPY . .

40. Docker layer কী?

Dockerfile:

FROM node:22

WORKDIR /app

COPY package*.json ./

RUN npm ci

COPY . .

CMD ["npm", "start"]

এখানে প্রতিটি build instruction image-এর build process-এর একটি layer/cacheable step তৈরি করতে পারে।

ভাবতে পারো:

Layer 1 → FROM
Layer 2 → WORKDIR
Layer 3 → COPY package.json
Layer 4 → npm ci
Layer 5 → COPY source
Layer 6 → CMD

Docker cache ব্যবহার করে unchanged parts পুনরায় তৈরি না করে reuse করতে পারে।

41. Cache invalidation বুঝে Dockerfile লিখো

ধরো:

COPY . .

RUN npm install

তুমি code-এর একটি ছোট file পরিবর্তন করলেও:

COPY . .

layer পরিবর্তিত হবে।

তারপর পরের:

RUN npm install

এটিও আবার execute হতে পারে।

তাই dependency ও source code আলাদা করা ভালো:

COPY package*.json ./

RUN npm install

COPY . .

এতে source পরিবর্তন করলে dependency installation cache করা সম্ভব।

42. Dockerfile order কেন এত গুরুত্বপূর্ণ?

একটি ভালো Dockerfile সাধারণত:

Least-changing files
        ↓
Most-changing files

এই order অনুসরণ করে।

উদাহরণ:

COPY package.json package-lock.json ./
RUN npm ci

COPY src ./src

এখানে dependency file কম change হয়।

Source code বেশি change হয়।

তাই expensive dependency installation আগে রেখে cache benefit পাওয়া যায়।

43. Python dependency caching pattern

ভালো structure:

FROM python:3.12

WORKDIR /app

COPY requirements.txt .

RUN pip install --no-cache-dir -r requirements.txt

COPY . .

CMD ["python", "app.py"]

কারণ source code change হলেও:

requirements.txt

না বদলালে dependency install cache reuse হতে পারে।

44. Dockerfile-এ comments

Comment:

# Base image
FROM python:3.12

# Application directory
WORKDIR /app

Comments readability বাড়ায়।

45. Environment variable ব্যবহার

ধরো application:

import os

port = os.getenv("PORT", "8000")

print(port)

Dockerfile:

FROM python:3.12

WORKDIR /app

COPY . .

ENV PORT=8000

CMD ["python", "app.py"]

Run:

docker run myapp

অথবা runtime override:

docker run -e PORT=9000 myapp

46. Build ARG ব্যবহার

Dockerfile:

ARG PYTHON_VERSION=3.12

FROM python:${PYTHON_VERSION}

WORKDIR /app

COPY . .

CMD ["python", "app.py"]

Build:

docker build \
  --build-arg PYTHON_VERSION=3.13 \
  -t myapp .

এখানে build-time configuration পরিবর্তন করা যায়।

47. ARG এবং FROM

একটি বিশেষ case:

ARG VERSION=3.12

FROM python:${VERSION}

FROM-এর আগে globally scoped ARG ব্যবহার করা যায়। Docker-এর official reference-এ ARG এবং FROM interaction আলাদাভাবে documented।

48. Multi-stage build — production-এর জন্য অত্যন্ত গুরুত্বপূর্ণ

ধরো Go application build করতে compiler লাগবে।

Development stage:

Go compiler
Source code
Build tools
Dependencies

কিন্তু final application চালাতে শুধু:

Binary

দরকার।

তাহলে কেন final image-এ compiler রাখবে?

এখানেই multi-stage build।

49. Multi-stage build-এর basic structure

FROM golang:1.26 AS builder

WORKDIR /src

COPY . .

RUN go build -o app .

FROM alpine:3.22

WORKDIR /app

COPY --from=builder /src/app .

CMD ["./app"]

এখানে:

Stage 1
builder
 ↓
compile application

Stage 2
runtime
 ↓
copy only binary

Docker-এর official documentation অনুযায়ী multi-stage build-এ একাধিক FROM ব্যবহার করে build environment এবং final runtime environment আলাদা করা যায়; COPY --from দিয়ে আগের stage থেকে প্রয়োজনীয় artifact আনা যায়।

50. Multi-stage build কেন দরকার?

এতে final image-এ থাকতে পারে:

Only runtime dependencies
+
Application

এগুলো থাকে না:

Compiler
Source build tools
Development dependencies
Debug tools

ফলে:

Smaller image
+
Smaller attack surface
+
Cleaner production image

Docker-এর current guidance multi-stage builds-কে build বনাম runtime separation এবং final image optimization-এর জন্য recommended approach হিসেবে দেখায়।

51. Node.js production multi-stage example

একটি frontend application ধরো।

FROM node:22-alpine AS builder

WORKDIR /app

COPY package*.json ./

RUN npm ci

COPY . .

RUN npm run build


FROM nginx:alpine

COPY --from=builder /app/dist /usr/share/nginx/html

Flow:

Node image
   ↓
Install dependencies
   ↓
Build frontend
   ↓
dist/
   ↓
Nginx image
   ↓
Production

Final image-এ Node compiler/development dependencies রাখার দরকার নেই।

52. Python production multi-stage ধারণা

Python-এ multi-stage একটু application-dependent।

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

FROM python:3.12 AS builder

WORKDIR /app

COPY requirements.txt .

RUN pip install --prefix=/install \
    --no-cache-dir \
    -r requirements.txt


FROM python:3.12-slim

WORKDIR /app

COPY --from=builder /install /usr/local

COPY . .

CMD ["python", "app.py"]

এখানে dependency install একটি builder stage-এ করা হচ্ছে এবং runtime image-এ তা copy করা হচ্ছে।

53. Development এবং production Dockerfile এক নয়

Development-এ তুমি চাইতে পারো:

Debugger
Hot reload
Source code
Development dependencies
CLI tools

Production-এ চাইতে পারো:

Small image
Only required dependencies
Non-root user
Healthcheck
Deterministic dependencies
No secrets

তাই development এবং production requirements আলাদা করে চিন্তা করতে হবে।

54. Dockerfile security-এর মূল ধারণা

একটি production Dockerfile-এর checklist:

Use trusted base image
Pin appropriate versions
Use .dockerignore
Do not bake secrets
Use non-root user
Use multi-stage builds
Keep image minimal
Remove unnecessary packages
Use vulnerability scanning
Define healthcheck where appropriate

55. Secret কখনো COPY কোরো না

এই project:

.env

থাকলে:

COPY . .

এর মাধ্যমে accidentally secret image-এর build context-এ ঢুকে যেতে পারে।

তাই:

.dockerignore

-এ অন্তত:

.env
*.pem
*.key

জাতীয় sensitive files বাদ দেওয়ার কথা বিবেচনা করো।

56. Secrets-এর জন্য ARG ব্যবহার না করা

খারাপ:

ARG SECRET_KEY
RUN echo "$SECRET_KEY" > secret.txt

বা:

docker build --build-arg SECRET_KEY=abc123 .

কারণ sensitive data build metadata/history-তে expose হওয়ার risk আছে। Docker সরাসরি build arguments-এর মাধ্যমে secrets pass না করার সতর্কতা দেয়।

57. BuildKit secret mount

Sensitive build-time secret প্রয়োজন হলে BuildKit-এর secret mount ব্যবহার করা যায়।

ধারণাগত example:

RUN --mount=type=secret,id=mysecret \
    cat /run/secrets/mysecret

Build command environment অনুযায়ী secret:

docker build \
  --secret id=mysecret,src=secret.txt \
  .

এটি Docker-এর modern build tooling-এর secure secret mechanism-এর অংশ।

58. Non-root container

উদাহরণ:

FROM python:3.12-slim

WORKDIR /app

RUN useradd --create-home appuser

COPY --chown=appuser:appuser . .

USER appuser

CMD ["python", "app.py"]

এখানে application root হিসেবে চলছে না।

এটি security hardening-এর একটি গুরুত্বপূর্ণ layer।

59. HEALTHCHECK practical example

ধরো API server:

FROM python:3.12-slim

WORKDIR /app

COPY requirements.txt .

RUN pip install --no-cache-dir -r requirements.txt

COPY . .

EXPOSE 8000

HEALTHCHECK --interval=30s --timeout=5s \
    CMD python -c "import urllib.request; urllib.request.urlopen('http://localhost:8000/health')" \
    || exit 1

CMD ["python", "app.py"]

এখানে /health endpoint application-এর health report করবে।

60. একটি complete production-oriented example

ধরো FastAPI application:

project/
├── Dockerfile
├── .dockerignore
├── requirements.txt
└── app/
    └── main.py

Dockerfile:

FROM python:3.12-slim

WORKDIR /app

ENV PYTHONDONTWRITEBYTECODE=1
ENV PYTHONUNBUFFERED=1

RUN useradd --create-home appuser

COPY requirements.txt .

RUN pip install --no-cache-dir -r requirements.txt

COPY --chown=appuser:appuser ./app ./app

USER appuser

EXPOSE 8000

CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]

এখানে আমরা অনেক concept একসাথে ব্যবহার করেছি:

FROM
WORKDIR
ENV
RUN
COPY
USER
EXPOSE
CMD

61. CMD-এর একটি common ভুল

খারাপ:

CMD ["uvicorn app.main:app --host 0.0.0.0 --port 8000"]

এখানে পুরো command একটিমাত্র argument হয়ে যেতে পারে।

বরং:

CMD [
    "uvicorn",
    "app.main:app",
    "--host",
    "0.0.0.0",
    "--port",
    "8000"
]

অথবা single line:

CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]

62. Dockerfile-এ `cd` ব্যবহার করার প্রয়োজন কমাও

খারাপ:

RUN cd /app && npm install

ভালো:

WORKDIR /app

RUN npm install

WORKDIR Dockerfile-কে cleaner এবং predictable করে।

63. Relative path বনাম absolute path

যেমন:

WORKDIR /app
COPY app.py .

এখানে . মানে:

/app

আর:

COPY app.py /app/

explicit।

দুটিই valid, কিন্তু consistent style গুরুত্বপূর্ণ।

64. `COPY . .` সবসময় best নয়

এটি কাজ করে:

COPY . .

কিন্তু অনেক production Dockerfile-এ আরও precise হওয়া ভালো।

যেমন:

COPY package*.json ./
COPY src ./src
COPY public ./public

এর সুবিধা:

Clear
+
Less accidental files
+
Better control

তবে .dockerignore সঠিক থাকলে COPY . .-ও practical।

65. Dependency lock file ব্যবহার করো

Node:

package-lock.json

Python ecosystem-এ:

requirements.txt

Poetry:

poetry.lock

Modern dependency managers-এ lock file ব্যবহার reproducibility বাড়ায়।

উদাহরণ:

COPY package.json package-lock.json ./
RUN npm ci

সাধারণভাবে:

npm install

এর বদলে CI/production build-এ lockfile-respecting:

npm ci

ভালো choice হতে পারে।

66. Package install এবং cache

Python:

RUN pip install --no-cache-dir -r requirements.txt

এখানে pip-এর local package cache image-এ unnecessarily রেখে না দেওয়ার উদ্দেশ্য থাকে।

Node:

RUN npm ci

এবং multi-stage production build-এ dev dependencies final image থেকে বাদ দিতে পারো।

67. One process per container?

Docker-এর প্রচলিত design philosophy অনুযায়ী একটি container-কে একটি primary service/process-এর চারপাশে design করা সাধারণ এবং operationally সহজ।

উদাহরণ:

Container 1 → Nginx
Container 2 → API
Container 3 → PostgreSQL
Container 4 → Redis

একটি giant container-এর মধ্যে:

Nginx
+
API
+
Database
+
Redis

ঢোকানো সাধারণত ভালো architecture নয়।

Multi-container application-এর জন্য পরে Docker Compose/Kubernetes-এর মতো orchestration layer শেখা দরকার।

68. Dockerfile এবং Docker Compose এক জিনিস নয়

Dockerfile:

একটি image কীভাবে build হবে?

Compose:

একাধিক container/service কীভাবে একসাথে চলবে?

উদাহরণ:

Dockerfile
   ↓
Build API image

Compose:

API
 ↓
PostgreSQL
 ↓
Redis

একটি complete application stack manage করবে।

69. Dockerfile filename

Default filename:

Dockerfile

কোন extension লাগে না।

সাধারণভাবে:

Dockerfile.txt

ভুল।

70. Different Dockerfiles

তুমি চাইলে:

Dockerfile
Dockerfile.dev
Dockerfile.prod
Dockerfile.test

রাখতে পারো।

Build:

docker build -f Dockerfile.dev -t myapp:dev .

অথবা:

docker build -f Dockerfile.prod -t myapp:prod .

71. Build command পুরোপুরি বুঝে নাও

docker build -t myapp .

এখানে:

docker build

= image build

-t myapp

= image-এর name/tag

= build context

72. Tag ব্যবহার

docker build -t myapp:1.0 .

এখন:

repository = myapp
tag        = 1.0

আর:

docker build -t myapp:latest .

অথবা production-এ meaningful versioning:

docker build -t myapp:2026.09.08 .

73. Build তারপর inspect

Build:

docker build -t myapp .

Images:

docker images

Run:

docker run myapp

Container:

docker ps

Logs:

docker logs <container>

Shell:

docker exec -it <container> sh

এই basic commandগুলো Dockerfile শেখার সঙ্গে সঙ্গে practice করা জরুরি।

74. Dockerfile debug করার method

Build error হলে প্রথমে দেখো কোন instruction fail করেছে।

উদাহরণ:

Step 4/7 : RUN npm ci

তার মানে dependency installation step-এ problem।

Container start না হলে:

docker logs <container>

দেখো।

Container-এর ভেতর debug:

docker exec -it <container> sh

75. Shell না থাকলে?

Slim/minimal image-এ সবসময় bash নাও থাকতে পারে।

যেমন Alpine image-এ সাধারণত:

sh

ব্যবহার করতে পারো:

docker exec -it container sh

76. ENTRYPOINT-এর একটি গুরুত্বপূর্ণ বিষয়: signal handling

Production container-এ application যেন OS signals ঠিকভাবে receive করে, তার জন্য exec form গুরুত্বপূর্ণ।

ভালো:

ENTRYPOINT ["./server"]

অথবা:

CMD ["node", "server.js"]

Shell wrapper-এর মাধ্যমে unnecessarily:

CMD ./start.sh

ব্যবহার করলে signal behaviour ভিন্ন হতে পারে।

এজন্য process management ও PID 1 behaviour সম্পর্কে পরে শেখা গুরুত্বপূর্ণ।

77. Shell script দিয়ে startup

যদি script প্রয়োজন হয়:

COPY entrypoint.sh /entrypoint.sh

RUN chmod +x /entrypoint.sh

ENTRYPOINT ["/entrypoint.sh"]

entrypoint.sh:

#!/bin/sh
set -e

echo "Starting application..."

exec "$@"

এখানে exec ব্যবহার করলে child process proper PID/signal behaviour পেতে পারে।

78. Dockerfile lint ও checks

Modern Docker build tooling-এ Dockerfile checks পাওয়া যায়।

Dockerfile-এর syntax ও কিছু common issue detect করতে build/checking facilities ব্যবহার করা যায়। Docker-এর reference-এ parser directives এবং check সম্পর্কিত capability-ও documented।

তাই শুধু:

docker build

জানলেই হবে না।

Production-এ:

Build
+
Lint/check
+
Security scan

workflow রাখা ভালো।

79. Base image selection কীভাবে করবে?

প্রথমে প্রশ্ন:

আমার application কী চালাতে চায়?

Python হলে:

FROM python:3.12-slim

Node হলে:

FROM node:22-alpine

Go হলে:

FROM golang:1.26 AS builder

তারপর runtime image আলাদা হতে পারে।

80. "সবচেয়ে ছোট image" খুঁজলেই হবে?

না।

একটি image ছোট হতে পারে, কিন্তু:

Harder debugging
+
Missing libraries
+
Compatibility problems
+
More complexity

হতে পারে।

তাই লক্ষ্য হওয়া উচিত:

Small enough, secure enough, maintainable enough, reproducible enough.

81. Dockerfile-এ package cleanup কেন করা হয়?

Ubuntu/Debian:

RUN apt-get update && \
    apt-get install -y --no-install-recommends curl && \
    rm -rf /var/lib/apt/lists/*

এখানে package index cleanup করা হচ্ছে যাতে unnecessary package metadata image-এ পড়ে না থাকে।

82. Multiple RUN বনাম single RUN

এটি:

RUN apt-get update
RUN apt-get install -y curl
RUN rm -rf /var/lib/apt/lists/*

এর চেয়ে এই pattern সাধারণত ভালো:

RUN apt-get update && \
    apt-get install -y --no-install-recommends curl && \
    rm -rf /var/lib/apt/lists/*

কারণ related package setup একটি coherent build step-এ রাখা হয়।

তবে "সব RUN সবসময় এক লাইনে combine করতে হবে"—এমন কোনো rule নেই।

Readability ও caching-এর balance রাখতে হবে।

83. Dockerfile design করার formula

একটি নতুন application পেলে এই প্রশ্নগুলো করো:

প্রশ্ন ১

Application কোন runtime চায়?

Python?
Node?
Java?
Go?
Rust?
PHP?

প্রশ্ন ২

কোন base image?

official/runtime image

প্রশ্ন ৩

Working directory?

/app

প্রশ্ন ৪

কী dependencies দরকার?

requirements.txt
package.json
pom.xml
go.mod

প্রশ্ন ৫

কীভাবে install হবে?

RUN ...

প্রশ্ন ৬

কোন files copy করতে হবে?

COPY ...

প্রশ্ন ৭

কোন port?

EXPOSE ...

প্রশ্ন ৮

কী command দিয়ে application start হবে?

CMD ...

প্রশ্ন ৯

Production image আরও ছোট করা যায়?

Multi-stage build

প্রশ্ন ১০

Security hardening কী?

USER
.dockerignore
No secrets
Minimal packages

এই ১০টি প্রশ্নের উত্তর দিতে পারলে তুমি বেশিরভাগ application-এর Dockerfile লিখতে পারবে।

84. Beginner Dockerfile Template

সবচেয়ে basic template:

FROM <base-image>

WORKDIR /app

COPY <dependency-files> .

RUN <install-dependencies>

COPY . .

EXPOSE <port>

CMD ["<command>", "<arg>"]

উদাহরণ:

FROM node:22-alpine

WORKDIR /app

COPY package*.json ./

RUN npm ci

COPY . .

EXPOSE 3000

CMD ["npm", "start"]

85. Production Dockerfile Template

আরও production-oriented structure:

FROM <builder-image> AS builder

WORKDIR /app

COPY dependency-files ./

RUN <install/build>

COPY source .

RUN <build>


FROM <runtime-image>

WORKDIR /app

RUN <create-non-root-user>

COPY --from=builder <artifact> <destination>

USER <non-root-user>

EXPOSE <port>

HEALTHCHECK ...

ENTRYPOINT ["..."]

CMD ["..."]

সব application-এ এই exact template লাগবে না, কিন্তু design pattern হিসেবে অত্যন্ত useful।

86. Common mistakes

Mistake 1 — Dockerfile-এর শেষে extension

Dockerfile.txt

ভুল।

ব্যবহার:

Dockerfile

Mistake 2 — `RUN npm start`

ভুল:

RUN npm start

সাধারণভাবে দরকার:

CMD ["npm", "start"]

Mistake 3 — Secret COPY করা

COPY . .

এবং .env ignore না করা।

এটি dangerous হতে পারে।

Mistake 4 — `ARG` দিয়ে secret

--build-arg PASSWORD=...

secret storage হিসেবে ব্যবহার করা উচিত নয়।

Mistake 5 — Dependency cache নষ্ট করা

COPY . .
RUN npm ci

এর বদলে অনেক ক্ষেত্রে:

COPY package*.json ./
RUN npm ci
COPY . .

ভালো।

Mistake 6 — Container root হিসেবে চালানো

সম্ভব হলে non-root user ব্যবহার করো।

Mistake 7 — Production-এ development tools রেখে দেওয়া

Compiler:

gcc
go compiler
Node build tools
debug utilities

এসব final runtime image-এ সবসময় প্রয়োজন নেই।

Multi-stage build দিয়ে আলাদা করা যায়।

Mistake 8 — `COPY . .` দিয়ে সবকিছু ঢুকিয়ে দেওয়া

.dockerignore ব্যবহার না করলে:

.git
node_modules
.env
logs
build artifacts

অনিচ্ছাকৃতভাবে build context-এ ঢুকতে পারে।

87. একটি real-world workflow

ধরো তোমার Node API:

my-api/
├── src/
├── package.json
├── package-lock.json
├── .env
├── node_modules/
└── Dockerfile

প্রথমে:

Step 1

.dockerignore:

node_modules
.git
.env
npm-debug.log
coverage
dist

Step 2

Dockerfile:

FROM node:22-alpine

WORKDIR /app

COPY package*.json ./

RUN npm ci

COPY src ./src

EXPOSE 3000

CMD ["node", "src/index.js"]

Step 3

Build:

docker build -t my-api .

Step 4

Run:

docker run -p 3000:3000 my-api

Step 5

Test:

curl http://localhost:3000

এই workflow-টাই Dockerfile শেখার জন্য খুব effective।

88. Dockerfile-এর mental model

Dockerfile দেখার সময় এইভাবে চিন্তা করো:

FROM
আমি কোথা থেকে শুরু করছি?

WORKDIR
আমি কোথায় কাজ করছি?

COPY
কী কী দরকার?

RUN
Image build হওয়ার সময় কী করতে হবে?

ENV / ARG
Configuration কোথায়?

EXPOSE
Application কোন port-এ?

USER
কে application চালাবে?

HEALTHCHECK
Application healthy কিনা কীভাবে জানব?

ENTRYPOINT / CMD
Container start হলে কী হবে?

এই mental model তৈরি হয়ে গেলে Dockerfile আর মুখস্থ করতে হবে না।

89. Dockerfile শেখার জন্য ৫টি project

শুধু theory পড়লে Dockerfile পুরোপুরি শেখা যাবে না।

এই sequence-এ project করো।

Project 1 — Python CLI

Python script
 ↓
Dockerfile
 ↓
Image
 ↓
Container

শিখবে:

FROM
WORKDIR
COPY
CMD

Project 2 — Node API

শিখবে:

package.json
npm ci
EXPOSE
ENV
.dockerignore

Project 3 — FastAPI/Flask

শিখবে:

Port
Environment variable
USER
HEALTHCHECK

Project 4 — React/Vite

শিখবে:

Multi-stage build
Node builder
Nginx runtime

Project 5 — Full stack

Frontend
+
Backend
+
Database

এখানে Dockerfile-এর সঙ্গে Docker Compose শেখা শুরু করবে।

90. Dockerfile বনাম Image বনাম Container

এই তিনটি গুলিয়ে ফেলবে না।

Dockerfile
    │
    │ docker build
    ↓
Docker Image
    │
    │ docker run
    ↓
Container

Dockerfile

Recipe।

Image

Built package/template।

Container

Running instance।

উদাহরণ:

Dockerfile = রান্নার recipe
Image      = তৈরি খাবারের package
Container  = সেই package থেকে চালু হওয়া instance

91. Dockerfile-এর সবচেয়ে important ১২টি instruction

শুরুতে এইগুলো solid করো:

FROM
WORKDIR
COPY
RUN
ENV
ARG
EXPOSE
USER
CMD
ENTRYPOINT
HEALTHCHECK

এর সঙ্গে:

.dockerignore

অবশ্যই শিখবে।

92. Production-level Dockerfile checklist

Deploy করার আগে নিজের Dockerfile-কে জিজ্ঞাসা করো:

[ ] Base image কি যথাযথ?
[ ] Version কি predictable?
[ ] WORKDIR explicitly set?
[ ] .dockerignore আছে?
[ ] Dependency আগে copy করা হয়েছে?
[ ] Cache ভালোভাবে ব্যবহার হচ্ছে?
[ ] Unnecessary packages বাদ?
[ ] Secrets image-এ ঢুকছে না?
[ ] ARG দিয়ে secret দেওয়া হচ্ছে না?
[ ] Non-root user ব্যবহার করা যায়?
[ ] Multi-stage build দরকার কি?
[ ] Correct EXPOSE?
[ ] Correct CMD/ENTRYPOINT?
[ ] Healthcheck প্রয়োজন?
[ ] Final image unnecessarily বড় কি?
[ ] Dependency lock file ব্যবহার করা হয়েছে?

93. একটি complete example — সবকিছু একসঙ্গে

ধরো Node backend production-এর জন্য:

# syntax=docker/dockerfile:1

FROM node:22-alpine AS builder

WORKDIR /app

COPY package.json package-lock.json ./

RUN npm ci

COPY . .

RUN npm run build


FROM node:22-alpine AS production

WORKDIR /app

ENV NODE_ENV=production

RUN addgroup -S appgroup && \
    adduser -S appuser -G appgroup

COPY package.json package-lock.json ./

RUN npm ci --omit=dev

COPY --from=builder --chown=appuser:appgroup /app/dist ./dist

USER appuser

EXPOSE 3000

HEALTHCHECK --interval=30s --timeout=5s \
    CMD wget --spider -q http://localhost:3000/health || exit 1

CMD ["node", "dist/index.js"]

এখানে আমরা শিখলাম:

syntax directive
        ↓
multi-stage build
        ↓
WORKDIR
        ↓
dependency caching
        ↓
npm ci
        ↓
production dependencies
        ↓
non-root user
        ↓
EXPOSE
        ↓
HEALTHCHECK
        ↓
CMD

এ ধরনের structure production Dockerfile বোঝার জন্য একটি ভালো reference pattern।

94. Dockerfile লেখার golden rules

এগুলো মুখস্থ করার চেয়ে বুঝে রাখো:

Rule 1

Base image carefully choose করো।

FROM python:3.12-slim

Rule 2

WORKDIR explicitly set করো।

WORKDIR /app

Rule 3

Dependency files আগে copy করো।

COPY package*.json ./
RUN npm ci

Rule 4

Source code পরে copy করো।

COPY . .

Rule 5

Build command আর startup command আলাদা করো।

RUN → build time
CMD → runtime

Rule 6

Secret Dockerfile-এ bake কোরো না।

Rule 7

.dockerignore ব্যবহার করো।

Rule 8

Production-এ non-root user বিবেচনা করো।

Rule 9

Compiled/build-heavy applications-এ multi-stage build ব্যবহার করো।

Rule 10

Docker cache কীভাবে কাজ করে তা বুঝে instruction order করো।

Docker-এর current build guidance-ও cache efficiency, multi-stage builds এবং clean runtime images-এর ওপর বিশেষ গুরুত্ব দেয়।

95. শেষ পর্যন্ত Dockerfile কীভাবে নিজে লিখবে?

এখন ধরো তোমাকে একজন বলল:

"আমার একটি Java Spring Boot application আছে। এর Dockerfile লিখে দাও।"

তখন তোমার মাথায় automatically এই প্রশ্নগুলো আসা উচিত:

1. কোন Java version?
2. কোন build system?
   Maven না Gradle?
3. Dependency file কোনটি?
4. Build artifact কী?
5. Application কোন port-এ চলে?
6. Runtime-এর জন্য পুরো JDK লাগবে?
7. JRE/runtime image যথেষ্ট?
8. Multi-stage build করা যায়?
9. Non-root user ব্যবহার করা যায়?
10. Health endpoint আছে?

তারপর structure:

Builder stage
    ↓
Copy dependency descriptors
    ↓
Download dependencies
    ↓
Copy source
    ↓
Build
    ↓
Runtime stage
    ↓
Copy artifact
    ↓
USER
    ↓
EXPOSE
    ↓
ENTRYPOINT/CMD

এটাই Dockerfile লেখার আসল skill।

96. সবচেয়ে গুরুত্বপূর্ণ বিষয়

Dockerfile শেখার সময় instruction মুখস্থ করার চেষ্টা কোরো না।

বরং বুঝো:

FROM
    ↓
Environment কোথা থেকে?

WORKDIR
    ↓
কোথায় কাজ?

COPY
    ↓
কী দরকার?

RUN
    ↓
Build-এর সময় কী করতে হবে?

ENV / ARG
    ↓
Configuration কী?

USER
    ↓
কে process চালাবে?

EXPOSE
    ↓
কোন port?

HEALTHCHECK
    ↓
Healthy কিনা কীভাবে বুঝব?

ENTRYPOINT / CMD
    ↓
Container start হলে কী করবে?

এই logic বুঝে গেলে language বদলালেও Dockerfile লিখতে পারবে।

Python:

FROM python:3.12-slim

Node:

FROM node:22-alpine

Java:

FROM eclipse-temurin:21

Go:

FROM golang:1.26 AS builder

Language আলাদা হলেও Dockerfile-এর চিন্তার পদ্ধতি একই থাকে।

97. এক লাইনে পুরো Dockerfile philosophy

শেষে এই pattern-টি মনে রাখো:

Choose base
     ↓
Set working directory
     ↓
Copy dependency files
     ↓
Install dependencies
     ↓
Copy source code
     ↓
Build application
     ↓
Remove unnecessary build/runtime baggage
     ↓
Create non-root runtime
     ↓
Expose application port
     ↓
Define health
     ↓
Define startup command

আর production application হলে:

           Dockerfile
               │
               ↓
       Multi-stage build
          ┌────┴────┐
          ↓         ↓
       Builder    Runtime
          │         │
    Build tools    Minimal
    Dependencies   Dependencies
    Source         Artifact
          │         │
          └────┬────┘
               ↓
        Small production
             image

এই mental model আয়ত্ত করতে পারলে Dockerfile আর "মুখস্থ করার syntax" থাকবে না—এটি হয়ে যাবে application packaging ও deployment design-এর একটি tool।

TCP (Transmission Control Protocol) বাংলায়: Port, Segment, 3-Way Handshake, Sequence, ACK, Window, Retransmission ও Connection Closing

Ragib Hasan — Wed, 02 Sep 2026 07:57:06 +0000

ভূমিকা: TCP আসলে কী?

ইন্টারনেটে আমরা সাধারণত খুব সহজভাবে বলি:

“Client সার্ভারকে একটা request পাঠালো, server response দিল।”

কিন্তু operating system এবং networking stack-এর নিচে ঘটনাটা অনেক বেশি সংগঠিত।

তুমি browser-এ একটি URL লিখলে application layer থেকে শুরু করে TCP, IP, Data Link এবং physical medium পর্যন্ত একাধিক ধাপে data encapsulate হয়। TCP এই পুরো যাত্রায় connection-oriented, ordered এবং reliable byte-stream communication দেওয়ার জন্য গুরুত্বপূর্ণ ভূমিকা পালন করে।

দেওয়া ক্লাস-নোটে এই ধারণাটা খুব practicalভাবে বোঝানো হয়েছে: application layer শুধু বলে “আমি data পাঠাতে চাই”; transport layer সেই data-কে TCP segment-এ সাজিয়ে নিচের layer-এ পাঠায়।

বাস্তব TCP বোঝার জন্য আমাদের কয়েকটি জিনিস গভীরভাবে বুঝতে হবে:

Port
TCP segment ও header
Sequence Number
Acknowledgment Number
SYN / ACK / FIN / RST
Three-Way Handshake
Flow Control ও Window
Checksum
Retransmission
MSS ও TCP Options
Four-Step Connection Termination
Full duplex communication

1. প্রথমে একটি mental model তৈরি করি

ধরো দুইটি computer:

+------------------+ +------------------+
| CLIENT | | SERVER |
| | | |
| Browser / App | | Web Server |
| TCP | <---------------------> | TCP |
| IP | | IP |
+------------------+ +------------------+

Client বলছে:

“আমি তোমার কাছে data পাঠাতে চাই।”

Server বলছে:

“ঠিক আছে, আমি শুনছি।”

তারপর data exchange হবে।

কিন্তু TCP সরাসরি “Hello World” পাঠিয়ে দেয় না। Data-এর সঙ্গে metadata যোগ করে একটি TCP segment তৈরি করা হয়।

2. Application Data থেকে TCP Segment

Application layer-এর কাছে:

Hello World

TCP layer-এর কাছে এটা শুধু application data। TCP এই data-এর সঙ্গে TCP header যোগ করে:

+--------------------------------------+
| TCP HEADER |
+--------------------------------------+
| APPLICATION DATA |
+--------------------------------------+

অর্থাৎ:

TCP Segment = TCP Header + Data

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

HTTP request ≠ TCP request

HTTP হলো application-layer protocol। TCP হলো transport-layer protocol।

উদাহরণ:

HTTP
 ↓
TCP
 ↓
IP
 ↓
Ethernet / Wi-Fi
 ↓
Physical medium

বাস্তবে HTTP data TCP byte stream-এর অংশ হিসেবে যায়; HTTP request-এর boundary এবং TCP segment boundary এক জিনিস নয়।

3. OSI Layer-এর সঙ্গে TCP-এর সম্পর্ক

Networking নিয়ে আলোচনা করতে OSI model ব্যবহার করলে TCP থাকে Transport Layer / Layer 4-এ।

একটি simplified view:

Layer 7 Application
 HTTP / HTTPS / SMTP / DNS application usage
 │
 ▼
Layer 4 Transport
 TCP / UDP
 │
 ▼
Layer 3 Network
 IP
 │
 ▼
Layer 2 Data Link
 Ethernet / Wi-Fi
 │
 ▼
Layer 1 Physical
 Bits / electrical / radio / optical signals

এখানে mental model হিসেবে বলা যায়:

Application data পাঠাতে চায় → TCP তার delivery semantics যোগ করে → IP addressing/routing-এর ব্যবস্থা করে → lower layers actual transmission করে।

4. Encapsulation: Data কীভাবে বড় packet structure-এর মধ্যে ঢোকে?

TCP/IP encapsulation-এর visual overview — Wikimedia Commons.

ধরো application data:

Hello World

TCP layer যোগ করলো:

+-------------------+
| TCP Header |
+-------------------+
| Hello World |
+-------------------+

তারপর IP layer TCP segment-কে payload হিসেবে নেয়:

+-------------------+
| IP Header |
+-------------------+
| TCP Header |
| Hello World |
+-------------------+

তারপর Data Link layer নিজের header/trailer যোগ করতে পারে:

+-------------------+
| Ethernet/Wi-Fi |
| Header |
+-------------------+
| IP Header |
| TCP Header |
| Hello World |
+-------------------+
| Link Trailer |
+-------------------+

এটাই encapsulation।

Receiver side-এ উল্টো প্রক্রিয়া:

Physical
 ↓
Data Link header/trailer remove
 ↓
IP header remove
 ↓
TCP header process
 ↓
Application data

এটাকে decapsulation বলা যায়।

5. TCP কেন দরকার?

IP packet delivery-এর দায়িত্ব নেয়, কিন্তু application-এর প্রয়োজনীয় সব reliability guarantee IP দেয় না।

TCP মূলত কয়েকটি গুরুত্বপূর্ণ কাজ করে:

5.1 Ordered delivery

Data যে order-এ পাঠানো হয়েছে, application যেন সেই order-এ byte stream পায়।

5.2 Reliable delivery

Data হারিয়ে গেলে TCP loss detect করে এবং প্রয়োজন হলে retransmission করে।

5.3 Flow control

Receiver যতটুকু data নিতে পারে, sender যেন তার capacity-এর বাইরে চাপিয়ে না দেয়।

5.4 Connection management

Connection establish ও close করার জন্য TCP state machine ব্যবহার করে।

5.5 Full-duplex communication

একই established connection-এর দুই দিকেই একই সময়ে data চলতে পারে।

TCP-এর connection-oriented nature, sequencing এবং acknowledgment সম্পর্কে RFC 9293-এ বিস্তারিত specification দেওয়া হয়েছে।

6. Port কী?

একটি IP address তোমাকে সাধারণত কোন host-এর কাছে যেতে হবে তা বুঝতে সাহায্য করে।

কিন্তু একটি host-এর মধ্যে অনেক process/application একসঙ্গে network communication করতে পারে।

তাই দরকার:

Port Number

IP Address = কোন computer?
Port = সেই computer-এর কোন network service/process?

ধরো:

203.0.113.10:443

এখানে:

203.0.113.10 = IP address
443 = destination port

TCP header-এ:

Source Port = 16 bits
Destination Port = 16 bits

দুটো field-ই RFC 9293-এ 16-bit হিসেবে সংজ্ঞায়িত।

7. 16-bit Port মানে সর্বোচ্চ কত?

16 bits দিয়ে মোট:

2^16 = 65,536

টি numeric value represent করা যায়।

Range:

0 → 65,535

তবে “সব 65,536 port-ই বাস্তবে application-এর জন্য সমানভাবে usable” — এভাবে বলা ঠিক নয়। Port 0 বিশেষ-purpose/reserved context-এ থাকে, এবং কোন process কোন port bind করবে তা operating system ও protocol ব্যবহারের উপর নির্ভর করে।

8. Port-এর তিনটি IANA range

IANA port registry অনুযায়ী port range তিনভাবে ভাগ করা হয়:

Range	IANA নাম
0–1023	System Ports
1024–49151	User Ports
49152–65535	Dynamic and/or Private Ports

IANA বর্তমানে এই range-গুলোকেই ব্যবহার করে।

System / Well-Known Ports

সাধারণ উদাহরণ:

HTTP → 80
HTTPS → 443
SSH → 22
DNS → 53
SMTP → 25
Telnet → 23

এগুলো service identification-এর জন্য widely recognized port assignments।

Registered / User Ports

1024 → 49151

কিছু application/service নির্দিষ্ট port register করতে পারে।

Dynamic / Private / Ephemeral Ports

49152 → 65535

এই range client-side outgoing connections-এর temporary source port হিসেবে খুব commonly ব্যবহৃত হয়।

গুরুত্বপূর্ণ: “Ephemeral port range মানেই সব operating system-এ সবসময় 49152–65535” — এটা বলা যাবে না। IANA range একটি registry classification; operating system নিজস্ব ephemeral allocation range ব্যবহার করতে পারে।

9. Browser-এর source port কোথা থেকে আসে?

ধরো browser যাচ্ছে:

https://example.com

Server:

198.51.100.20:443

Browser-এর জন্য client-side TCP endpoint হতে পারে:

192.0.2.50:52000

তখন connection-এর একটি ধারণাগত 4-tuple:

Source IP = 192.0.2.50
Source Port = 52000

Destination IP = 198.51.100.20
Destination Port = 443

TCP connection matching-এর জন্য এই endpoint information গুরুত্বপূর্ণ।

দেওয়া লেকচারে browser-এর জন্য operating system-এর মাধ্যমে dynamic/ephemeral source port নেওয়ার উদাহরণটি বিশেষভাবে বোঝানো হয়েছে।

10. “এক computer সর্বোচ্চ 16,384 connection পাঠাতে পারবে”—এটা কেন ঠিক নয়?

লেকচারের উদাহরণে:

65535 - 49152 + 1 = 16384

করা হয়েছে। এটি IANA Dynamic/Private range-এর সংখ্যক port value।

কিন্তু এখান থেকে সরাসরি বলা যাবে না:

“একটি computer সর্বোচ্চ 16,384 TCP connection করতে পারবে।”

কারণ TCP connection শুধু source port দিয়ে identify হয় না। সাধারণভাবে connection-এর endpoint pair:

source IP + source port
+
destination IP + destination port

দিয়ে flow distinguish করা হয়।

একই client-side source port ভিন্ন destination endpoint-এর সঙ্গে ভিন্ন TCP connection-এর অংশ হতে পারে। উপরন্তু:

OS ephemeral port range পরিবর্তন করতে পারে
IPv4 ও IPv6 আলাদা address space তৈরি করতে পারে
একই host-এ বহু local IP থাকতে পারে
NAT/PAT middlebox আলাদা mappings তৈরি করতে পারে

তাই 16,384-কে “maximum total simultaneous TCP connections” হিসেবে মুখস্থ করা উচিত নয়।

11. TCP Segment-এর Anatomy

TCP header-এর প্রধান field-গুলোর visual diagram — Wikimedia Commons.

এখন TCP-এর আসল “ব্লকের” ভিতরে ঢুকি।

+-------------------------------+-------------------------------+
| Source Port (16) | Destination Port (16) |
+-------------------------------+-------------------------------+
| Sequence Number (32) |
+---------------------------------------------------------------+
| Acknowledgment Number (32) |
+------+----------+--------------------------------------------+
| Data | Reserved | Flags | Window |
|Offset| | | |
+------+----------+--------------------------------------------+
| Checksum | Urgent Pointer |
+---------------------------------------------------------------+
| Options (optional) |
+---------------------------------------------------------------+
| Padding (as needed) |
+---------------------------------------------------------------+
| Data / Payload |
+---------------------------------------------------------------+

এটি RFC 9293-এর TCP header format-এর সঙ্গে মিলিয়ে দেখা উচিত।

12. TCP Header-এর গুরুত্বপূর্ণ Field

Field	Size	কাজ
Source Port	16 bits	sender-side port
Destination Port	16 bits	receiver-side port
Sequence Number	32 bits	byte stream-এর sequence tracking
Acknowledgment Number	32 bits	next expected sequence number
Data Offset	4 bits	TCP header কত বড়
Reserved	4 bits	future use
Control Flags	8 bits বর্তমানে assigned core header flags; RFC diagram-এ control bits field	connection/control state
Window	16 bits	receiver কত data accept করতে পারে
Checksum	16 bits	error detection
Urgent Pointer	16 bits	URG ব্যবহারের ক্ষেত্রে urgent data সম্পর্কিত তথ্য
Options	variable	MSS, Window Scale, SACK ইত্যাদি
Data	variable	application payload

বিশেষ technical correction: অনেক পুরনো TCP diagram-এ Reserved 3 bits এবং flags 9 bits দেখা যায়। আধুনিক RFC 9293-এর header layout-এ Reserved অংশ 4 bits এবং assigned control bits 8 bits: CWR, ECE, URG, ACK, PSH, RST, SYN, FIN।

13. Data Offset কী?

Data Offset হলো 4-bit field।

এর অর্থ:

TCP header কতগুলো 32-bit word দীর্ঘ।

অর্থাৎ:

Header Size = Data Offset × 4 bytes

কারণ:

1 word = 32 bits = 4 bytes

Minimum:

Data Offset = 5
5 × 4 = 20 bytes

Maximum:

Data Offset = 15
15 × 4 = 60 bytes

অতএব:

Minimum TCP Header = 20 bytes
Maximum TCP Header = 60 bytes

RFC 9293-ও Data Offset-কে 32-bit words-এর সংখ্যা হিসেবে সংজ্ঞায়িত করেছে।

14. Data Offset-এর practical example

ধরো:

Data Offset = 5

তাহলে:

Header = 5 × 4
 = 20 bytes

আর ধরো:

Data Offset = 10

তাহলে:

Header = 10 × 4
 = 40 bytes

এতে receiver বুঝতে পারে TCP data কোথা থেকে শুরু হয়েছে।

15. Sequence Number — TCP বোঝার সবচেয়ে গুরুত্বপূর্ণ ধারণা

ধরো client server-এ data পাঠাচ্ছে:

HELLOWORLD

TCP byte stream-কে sequence number-এর মাধ্যমে track করে।

ধরা যাক client-এর Initial Sequence Number:

ISN = 1000

SYN-এর ক্ষেত্রে sequence number 1000 হলে, SYN নিজে sequence space-এ 1 unit consume করে।

তাই established data-এর প্রথম byte-এর sequence number হবে:

RFC 9293 স্পষ্টভাবে বলে: SYN set থাকলে segment-এর sequence number হলো ISN, এবং প্রথম data octet-এর sequence number হবে ISN+1।

16. “Sequence number মানে packet number”—এটা ঠিক নয়

এটি খুব common ভুল।

TCP sequence number মূলত byte sequence space-এর সঙ্গে যুক্ত।

ধরো:

Sequence = 1001
Payload Length = 5 bytes

তাহলে পরের expected sequence:

1001 + 5 = 1006

অর্থাৎ ACK সাধারণত:

ACK = 1006

এর মানে:

“1005 পর্যন্ত bytes পেয়েছি; এখন 1006 থেকে চাই।”

RFC 9293 acknowledgment number-কে “next sequence number expected to be received” হিসেবে সংজ্ঞায়িত করে।

17. Acknowledgment Number কী?

ধরো sender পাঠালো:

SEQ = 1001
LEN = 5

Receiver data পেল:

তাহলে receiver বলবে:

ACK = 1006

এখানে একটি অসাধারণ mental rule:

ACK number = “next byte I want”

এটা মনে রাখতে পারলে TCP-এর অনেক অংশ সহজ হয়ে যায়।

18. Three-Way Handshake

TCP three-way handshake-এর visual sequence — Wikimedia Commons.

TCP connection শুরু হওয়ার সময় সাধারণভাবে তিনটি control segment exchange হয়:

Client Server
 | |
 | -------- SYN, Seq = X ----------> |
 | |
 | <---- SYN + ACK, Seq = Y, |
 | ACK = X + 1 -------------- |
 | |
 | -------- ACK = Y + 1 ------------>|
 | |
 | CONNECTION READY |

Cloudflare-এর explanation-ও তিনটি ধাপকে SYN → SYN/ACK → ACK হিসেবে দেখায়।

19. Step 1 — Client sends SYN

Client বলছে:

আমি connection establish করতে চাই।

এখানে:

SYN = 1
SEQ = Client ISN

ধরি:

Client ISN = 1000

তাহলে:

Client → Server

SYN = 1
SEQ = 1000

20. Step 2 — Server sends SYN + ACK

Server client-এর SYN পেয়ে:

Client-এর SYN acknowledge করে
নিজের initial sequence number জানায়

ধরি:

Server ISN = 2000

তাহলে:

Server → Client

SYN = 1
ACK = 1001
SEQ = 2000

কেন:

ACK = 1001?

কারণ:

Client-এর SYN sequence = 1000
SYN consumes one sequence number
Next expected = 1001

21. Step 3 — Client sends final ACK

Client এখন server-এর SYN acknowledge করে:

Client → Server

ACK = 2001
SEQ = 1001

এখন handshake complete।

Client Server
 | |
 | SYN, SEQ=1000 ------------------> |
 | |
 | <----------- SYN, SEQ=2000 ------ |
 | <----------- ACK=1001 ------------|
 | |
 | ACK=2001 ------------------------>|
 | |
 | ESTABLISHED |

22. কেন Three-Way Handshake দরকার?

কারণ দুই side-ই নিজেদের sequence number establish করতে চায়।

Client-এর জন্য:

My ISN = 1000
Server must know it

Server-এর জন্য:

My ISN = 2000
Client must know it

শেষ ACK-এর মাধ্যমে client server-এর sequence space সম্পর্কে confirmation দেয়।

এই handshake থেকেই TCP-এর connection-oriented nature স্পষ্ট হয়।

24. TCP-তে Data Transfer শুরু হয় Handshake-এর পর

Handshake:

SYN
SYN/ACK
ACK

এরপর:

ESTABLISHED

এখন application data flow শুরু হতে পারে।

ধরো client পাঠাচ্ছে:

HELLO

এবং:

Client SEQ = 1001
Payload = 5 bytes

তাহলে receiver-এর ACK:

ACK = 1006

25. Client ও Server—দুই দিকেই data পাঠাতে পারে

TCP full-duplex।

অর্থাৎ শুধু:

Client → Server

নয়।

একই সময়ে:

Client → Server
Server → Client

দুই দিকেই independent byte stream চলতে পারে।

তাই দুই side-এর নিজস্ব:

Sequence number
Acknowledgment number
Sending state
Receiving state

থাকে।

26. Full-Duplex Example

Client Server
 | |
 | -------- SEQ=1001, "HELLO" -------->|
 | |
 | <--------- ACK=1006 ---------------- |
 | |
 | <------ SEQ=2001, "WELCOME" --------|
 | |
 | ---------- ACK=2008 --------------->|

Client-এর data sequence এবং server-এর data sequence আলাদা।

এটি TCP বোঝার আরেকটি গুরুত্বপূর্ণ mental model।

27. TCP Flags

TCP header-এর control bits-এর মাধ্যমে connection state/control behavior signal করা হয়।

RFC 9293-এর assigned control bits:

CWR
ECE
URG
ACK
PSH
RST
SYN
FIN

28. SYN Flag

SYN = Synchronize

Connection establishment-এ sequence space synchronize করতে ব্যবহৃত হয়।

Three-way handshake:

SYN
SYN + ACK
ACK

29. ACK Flag

ACK = Acknowledgment field is significant

ACK flag set থাকলে TCP acknowledgment field meaningful।

Established connection-এ ACK সাধারণত ongoing traffic-এর অংশ হিসেবেই আসে; “প্রতিটি ACK অবশ্যই আলাদা আলাদা packet হবে”—এটা ঠিক নয়।

একটি data-bearing TCP segment-ই simultaneously data পাঠাতে এবং আগের data acknowledge করতে পারে।

30. FIN Flag

FIN = No more data from sender

এক side বলছে:

“আমার sending direction-এর আর data নেই।”

FIN graceful close-এর অংশ।

গুরুত্বপূর্ণ:

FIN মানে পুরো connection মুহূর্তেই দুই দিক থেকে বন্ধ হয়ে গেল — এমন নয়।

TCP full-duplex হওয়ায় এক direction close হওয়ার পর অন্য direction কিছুক্ষণের জন্য চলতে পারে।

RFC 9293 FIN-কে “No more data from sender” হিসেবে সংজ্ঞায়িত করে।

31. RST Flag

RST = Reset

এটি connection-কে abruptly reset করতে ব্যবহৃত হয়।

FIN হলো graceful close-এর ধারণার সঙ্গে সম্পর্কিত।

RST হলো hard reset।

Cloudflare-ও FIN-based graceful close এবং RST-এর abrupt reset-এর পার্থক্য উল্লেখ করে।

32. PSH, URG, ECE, CWR

PSH

Push function-এর সঙ্গে সম্পর্কিত।

URG

Urgent Pointer field significant হলে URG set হয়।

ECE

ECN-এর signalling-এর সঙ্গে সম্পর্কিত।

CWR

Congestion Window Reduced-এর signalling-এর সঙ্গে সম্পর্কিত।

Beginner হিসেবে প্রথমে:

SYN
ACK
FIN
RST

এই চারটি ভালোভাবে বুঝলেই সবচেয়ে বেশি লাভ হবে।

RFC 9293 সব assigned control bits-এর precise definition দেয়।

33. Window Size — TCP কীভাবে একসঙ্গে অনেক data manage করে?

Sliding window ও acknowledgment-এর relationship — Wikimedia Commons.

ধরো sender প্রতিটি segment পাঠিয়ে আবার reply পাওয়ার জন্য থেমে থাকলে throughput ভয়াবহ কমে যেতে পারে।

তাই TCP একাধিক unacknowledged byte/segment “in flight” রাখতে পারে।

এখানে window গুরুত্বপূর্ণ।

RFC 9293 অনুযায়ী Window field receiver কত data গ্রহণ করতে প্রস্তুত তা advertise করে।

34. Simple Window Example

ধরো receiver বললো:

Window = 10,000 bytes

Mental model:

“আমি এখন পর্যন্ত প্রায় 10,000 bytes পর্যন্ত নতুন data accept করতে প্রস্তুত।”

তখন sender প্রতিটি segment-এর পর stop না করে multiple segment পাঠাতে পারে, যতক্ষণ advertised receive window এবং অন্যান্য TCP constraints তা allow করে।

উদাহরণ:

Sender
 |
 | Segment 1
 | Segment 2
 | Segment 3
 | Segment 4
 | Segment 5
 |
 +---- ACKs arrive later ---->

এটাই reliable high-throughput communication-এর ভিত্তিগুলোর একটি।

35. Flow Control বনাম Congestion Control

এ দুটোকে এক করে ফেললে TCP বোঝায় সমস্যা হবে।

Flow Control

Receiver-এর capacity কেন্দ্রিক।

প্রশ্ন:

Receiver আর কত data নিতে পারবে?

এখানে receive window গুরুত্বপূর্ণ।

Congestion Control

Network-এর congestion কেন্দ্রিক।

প্রশ্ন:

পুরো network path এখন কত traffic handle করতে পারছে?

Congestion control-এর জন্য sender-side congestion window (cwnd) গুরুত্বপূর্ণ।

বাস্তব TCP throughput সাধারণভাবে একাধিক constraint-এর উপর নির্ভর করে:

usable sending window ≈ min(rwnd, cwnd)

এখানে:

rwnd = receiver advertised window
cwnd = congestion control limit

এটি একটি practical mental model; exact implementation আরও complex।

36. Checksum — Data বদলে গেছে কিনা কীভাবে বোঝে?

TCP header-এ:

Checksum = 16 bits

এটি transmission corruption/error detect করতে ব্যবহৃত হয়।

RFC 9293 অনুযায়ী TCP checksum one's-complement ভিত্তিক calculation ব্যবহার করে এবং header ও data-এর ওপর checksum computation হয়।

37. Checksum কি “ভুল data ঠিক করে”?

না।

Checksum নিজে corrupted data repair করে না।

এটি mainly detect করে:

“আমি যা পেয়েছি, সেটা expected integrity check pass করছে কি?”

Error detect হলে segment গ্রহণ না-ও করা হতে পারে, এরপর TCP recovery mechanisms—যেমন retransmission—দিয়ে sender আবার data পাঠাতে পারে।

অর্থাৎ:

Checksum
 ↓
Error detected
 ↓
Bad segment discarded / recovery needed
 ↓
Retransmission mechanisms
 ↓
Correct data arrives

38. Retransmission — Packet হারিয়ে গেলে কী হয়?

ধরো:

Segment 1 → পৌঁছালো
Segment 2 → হারিয়ে গেল
Segment 3 → পৌঁছালো

Receiver cumulative ACK দিয়ে missing point signal করতে পারে।

ধরো receiver-এর next expected byte:

কিন্তু পরের data sequence শুরু হলো:

তাহলে sender বুঝতে পারে stream-এর মাঝখানে কিছু missing থাকতে পারে।

TCP loss recovery-এর অংশ হিসেবে timeout, duplicate acknowledgment এবং আধুনিক ব্যবহারে SACK-এর মতো mechanisms ব্যবহার করতে পারে।

39. Duplicate ACK — সহজ mental model

ধরো receiver আশা করছিল:

SEQ = 1006

কিন্তু পেল:

SEQ = 1106

অর্থাৎ মাঝখানে data missing।

Receiver repeated ACK করতে পারে:

ACK = 1006

কারণ:

“আমার 1006 থেকেই missing; এর পরেরটা আগে এসেছে।”

Repeated duplicate ACK sender-কে loss-এর সম্ভাবনা signal করতে পারে।

40. Retransmission মানে সবসময় “ACK না আসা পর্যন্ত resend”

এটা অতিরিক্ত simplistic model।

বাস্তবে TCP loss detection বিভিন্ন mechanism ব্যবহার করে, যেমন:

Retransmission Timeout (RTO)
Duplicate ACK-based fast retransmit
SACK-based recovery
modern congestion-control/recovery behavior

তাই:

No ACK → blindly resend

এই model-কে exact TCP behavior হিসেবে মনে রাখা উচিত নয়।

41. SACK

SACK = Selective Acknowledgment

এটি TCP-কে আরও efficiently জানাতে পারে কোন কোন block পাওয়া গেছে এবং কোন block missing।

উদাহরণ:

Received:
1001–2000
3001–4000

Missing:
2001–3000

SACK থাকলে receiver sender-কে more precise information দিতে পারে।

এটি retransmission efficiency বাড়াতে সাহায্য করে।

42. TCP Options

TCP header সবসময় শুধু fixed 20 bytes নয়।

Options থাকলে header বড় হতে পারে:

20 bytes → minimum
up to 60 bytes → maximum

Common options:

MSS
Window Scale
SACK Permitted
SACK
Timestamp

TCP Options-এর কারণে Data Offset field দরকার।

43. MSS — Maximum Segment Size

একটি TCP connection-এ endpoint-গুলো প্রায়ই জানায় তারা একটি TCP segment-এ কত application data গ্রহণ করতে চায়।

এটিকে:

MSS = Maximum Segment Size

বলা হয়।

এখানে “segment size” বললে অনেক সময় মানুষ পুরো IP packet size-এর সঙ্গে গুলিয়ে ফেলে।

প্র্যাকটিক্যালি:

TCP payload ≈ MSS

এবং:

IP packet size
≈ IP header + TCP header + TCP payload

Ethernet path-এ 1500-byte MTU হলে এবং TCP/IP header normal হলে 1460-byte MSS-এর উদাহরণ খুব common:

1500 - 20 IP header - 20 TCP header = 1460

তবে options, IPv6 এবং path-এর actual MTU অনুযায়ী effective numbers পরিবর্তিত হতে পারে।

44. “Hello World” কি একাধিক TCP segment হবেই?

না।

এটি data size এবং TCP stack-এর segmentation-এর উপর নির্ভর করে।

ছোট data:

Hello World

একটি TCP segment-এর payload-এ সহজেই থাকতে পারে।

বড় data:

Large JSON
Large file
Large response

অনেক TCP segment-এ ভাগ হয়ে যেতে পারে।

তাই:

1 HTTP request = 1 TCP segment

এটি guaranteed নয়।

আবার:

1 TCP segment = 1 complete HTTP message

এটিও guaranteed নয়।

TCP হলো byte stream, message protocol নয়।

45. TCP byte stream-এর সবচেয়ে গুরুত্বপূর্ণ শিক্ষা

ধরো application দুইবার write করলো:

write("HELLO")
write("WORLD")

TCP receiver-side application-এর কাছে network packet boundary preserve করার promise দেয় না।

Receiver দেখতে পারে:

HELLOWORLD

অথবা implementation/application buffering অনুযায়ী read boundaries অন্যরকম হতে পারে।

তাই application protocol-কে নিজের message framing দরকার হতে পারে।

HTTP, WebSocket, custom binary protocol—প্রতিটির framing semantics আলাদা।

46. Four-Step TCP Connection Termination

FIN/ACK দিয়ে TCP connection termination-এর visual diagram — Wikimedia Commons.

Connection close সাধারণভাবে চার ধাপের exchange হিসেবে শেখানো হয়।

Client Server
 | |
 | -------- FIN -------------------> |
 | |
 | <-------- ACK ------------------- |
 | |
 | <-------- FIN ------------------- |
 | |
 | -------- ACK -------------------> |
 | |
 | CLOSED |

একে beginner-friendlyভাবে:

FIN
ACK
FIN
ACK

মনে রাখা যায়।

Cloudflare-ও graceful close-এ FIN ব্যবহারের কথা বলে।

47. কেন চার ধাপ?

কারণ TCP full duplex।

প্রতিটি side-এর sending direction independently close হতে পারে।

ধরো Client বলে:

FIN

এর অর্থ:

“আমার আর data পাঠানোর নেই।”

Server:

ACK

দিয়ে Client-এর FIN acknowledge করে।

কিন্তু Server-এর নিজের sending direction তখনও data পাঠাতে পারে।

শেষে Server:

FIN

পাঠায়।

Client:

ACK

পাঠায়।

এরপর connection পুরোপুরি শেষ হয়।

48. গুরুত্বপূর্ণ: সব connection-এ exact “FIN, ACK, FIN, ACK” packet pattern দেখা যাবে না

Network captures-এ ACK সঙ্গে অন্য data/FIN-এর সঙ্গে combine হতে পারে।

উদাহরণ:

FIN + ACK

একটি segment-এই থাকতে পারে।

তাই “চারটি segment না হলে TCP close হয়নি”—এটা ঠিক নয়।

“Four-way termination” হলো conceptual state transition model।

49. Simultaneous Close

দুই side কাছাকাছি সময়ে FIN পাঠাতেও পারে।

TCP state machine-এর কারণে real packet trace textbook diagram-এর মতো perfectly symmetric নাও হতে পারে।

Networking শেখার সময় diagram-কে:

“Conceptual sequence”

হিসেবে দেখো; real packet capture-এর প্রতিটি flow exact একই হবে—এটা ধরে নিও না।

50. RST দিয়ে Connection বন্ধ হওয়া বনাম FIN

FIN

Graceful close

RST

Abrupt reset

যদি application abruptly socket destroy করে বা remote endpoint-এর state invalid হয়, RST দেখা যেতে পারে।

Packet capture debugging-এ FIN বনাম RST দেখে connection lifecycle সম্পর্কে গুরুত্বপূর্ণ clues পাওয়া যায়।

51. TCP Header-এর field-by-field deep explanation

Source Port

Sender-এর local transport endpoint-এর port।

Destination Port

Receiver-side transport endpoint-এর port।

Sequence Number

এই segment-এর data-এর sequence space position।

SYN segment-এ এটি ISN।

Acknowledgment Number

পরবর্তী expected sequence number।

Data Offset

TCP header-এর actual length, 32-bit word-এ।

Reserved

Future protocol evolution-এর জন্য reserved bits।

RFC 9293 অনুযায়ী generated segments-এ এগুলো zero হওয়া উচিত।

Flags

Control/state signaling।

Window

Receiver কত data accept করতে পারবে তার advertised receive capacity।

Checksum

Integrity/error detection।

Urgent Pointer

URG flag ব্যবহৃত হলে relevant urgent pointer field।

Options

Additional TCP capabilities/parameters।

Data

Application payload।

52. TCP Header-এর একটা visual memory trick

এভাবে মনে রাখতে পারো:

PORT
 ↓
আমি কার সঙ্গে কথা বলছি?

SEQUENCE
 ↓
আমার data কোথায়?

ACK
 ↓
আমি পরের কোন byte চাই?

WINDOW
 ↓
আমি কতটা receive করতে পারি?

CHECKSUM
 ↓
Data corrupt হয়েছে?

FLAGS
 ↓
Connection-এর control instruction কী?

OPTIONS
 ↓
আর কী capability/parameter negotiated?

53. Complete Example: Client → Server

ধরো:

Client IP = 192.0.2.10
Client Port = 52000

Server IP = 198.51.100.20
Server Port = 443

Step 1

Client → Server

Src Port = 52000
Dst Port = 443
SEQ = 1000
SYN = 1

Step 2

Server → Client

Src Port = 443
Dst Port = 52000
SEQ = 2000
ACK = 1001
SYN = 1
ACK = 1

Step 3

Client → Server

Src Port = 52000
Dst Port = 443
SEQ = 1001
ACK = 2001
ACK = 1

এখন established।

54. এবার data পাঠাই

ধরো client পাঠালো:

HELLO

5 bytes।

SEQ = 1001
LEN = 5

Server-এর acknowledgement:

ACK = 1006

কারণ:

1001 + 5 = 1006

এটাই “next byte expected” rule।

55. Server reply দিলে

ধরো server পাঠালো:

OK

2 bytes।

Server-এর প্রথম data sequence:

তাহলে:

Server → Client

SEQ = 2001
LEN = 2

Client ACK:

ACK = 2003

কারণ:

2001 + 2 = 2003

56. Data হারিয়ে গেলে

ধরো client পাঠালো:

SEQ=1001, LEN=100
SEQ=1101, LEN=100
SEQ=1201, LEN=100

কিন্তু দ্বিতীয় segment হারিয়ে গেল।

Server পেতে পারে:

1001–1200

তারপর 1201-এর segment out-of-order হিসেবে আসতে পারে।

Receiver cumulative ACK দিয়ে missing sequence point signal করতে পারে:

ACK = 1101

এখানে:

1001–1100 পেয়েছি, এখন 1101 চাই।

এটি loss recovery-এর একটি core mental model।

57. TCP কি packets reorder করে?

IP network-এ packets বিভিন্ন path দিয়ে যেতে পারে।

ফলে arrival order বদলে যেতে পারে।

TCP sequence number ব্যবহার করে:

Out-of-order data
 ↓
Sequence tracking
 ↓
Reassembly / buffering
 ↓
Application sees ordered byte stream

Cloudflare-এর TCP/IP explanation-এও IP packet ordering guarantee না দেওয়ার এবং TCP sequence-based reassembly/reliability handling-এর practical explanation দেওয়া হয়েছে।

58. TCP reliability-এর formula মনে রাখো

একটি সহজ mental model:

Sequence
 +
Acknowledgment
 +
Checksum
 +
Retransmission
 +
Window
 +
Congestion Control
 ↓
Reliable transport behavior

এগুলো আলাদা feature হলেও একসঙ্গে TCP-এর transport behavior তৈরি করে।

59. TCP বনাম UDP

TCP:

Connection-oriented
Reliable
Ordered byte stream
ACK
Retransmission
Flow control
Congestion control

UDP:

Connectionless datagram transport
No TCP-style connection establishment
No TCP-style ordered reliable byte-stream semantics

Cloudflare-এর UDP overview-তেও TCP-এর handshake/reliability/ordering-এর সঙ্গে UDP-এর lightweight datagram behavior তুলনা করা হয়েছে।

60. Application layer থেকে TCP পর্যন্ত full picture

ধরো browser:

POST /login

Application layer:

HTTP request

Transport layer:

TCP segment

Network layer:

IP packet

Data Link:

Ethernet/Wi-Fi frame

Physical:

bits / signals

Receiver side:

signals
 ↓
frame
 ↓
IP packet
 ↓
TCP segment
 ↓
HTTP bytes
 ↓
Application

এই layered abstraction-ই software engineer হিসেবে networking বোঝার জন্য শক্তিশালী mental model।

61. “TCP সরাসরি server-এ data পাঠায়” — কতটা ঠিক?

Conceptual context-এ:

Client TCP → Server TCP

বলা হয়।

এটা শেখার জন্য ভালো abstraction।

কিন্তু physical reality:

Client TCP
 ↓
Client IP
 ↓
Data Link
 ↓
Physical
 ↓
Router(s)
 ↓
Physical/Data Link
 ↓
Server IP
 ↓
Server TCP

TCP নিজে router-by-router forwarding করে না।

TCP endpoint-to-endpoint transport behavior manage করে।

62. Socket কোথায় আসে?

একটি TCP communication endpoint-কে practical programming context-এ socket হিসেবে দেখা যায়।

Conceptually:

Socket ≈ local address + local port + transport protocol

Established connection-কে identify করতে remote endpoint-ও গুরুত্বপূর্ণ।

Programming-এ সাধারণত developer socket API ব্যবহার করে:

connect()
send()
recv()
close()

এবং kernel TCP implementation নিচের protocol mechanics manage করে।

দেওয়া লেকচারে application developer-এর perspective-এ operating system TCP handling-এর এই abstraction জোর দিয়ে বোঝানো হয়েছে।

63. Operating System আসলে কী করে?

Application যখন socket API দিয়ে communication চায়, তখন kernel:

TCP state maintain করে
Sequence tracking করে
ACK process করে
Retransmission manage করে
Receive window maintain করে
Congestion control চালায়
TCP headers তৈরি/parse করে
IP stack-এর সঙ্গে কাজ করে
NIC-এর মাধ্যমে network I/O-তে অংশ নেয়

তাই software engineer হিসেবে:

You write:
send(data)

Kernel does:
TCP + IP + driver + NIC machinery

64. Wireshark-এ TCP দেখতে গেলে কী দেখবে?

একটি TCP packet capture-এ সাধারণত এগুলো দেখতে পারো:

Transmission Control Protocol
 Source Port
 Destination Port
 Sequence Number
 Acknowledgment Number
 Header Length
 Flags
 Window Size
 Checksum
 Options

সবচেয়ে beginner-friendly filter:

tcp

আর নির্দিষ্ট handshake খুঁজতে:

tcp.flags.syn == 1

ACK-related analysis-এর জন্য:

tcp.flags.ack == 1

FIN:

tcp.flags.fin == 1

RST:

tcp.flags.reset == 1

65. Wireshark-এ 3-Way Handshake চিনবে কীভাবে?

Pattern:

1. SYN
2. SYN, ACK
3. ACK

যদি capture-এ sequence এমন হয়:

Client → Server [SYN]
Server → Client [SYN, ACK]
Client → Server [ACK]

তাহলে connection establishment successfully দেখতে পাচ্ছ।

66. SYN Flood কেন TCP-এর সঙ্গে সম্পর্কিত?

TCP server SYN পাওয়ার পর connection establishment-এর state maintain করে এবং SYN/ACK response পাঠায়।

একজন attacker অনেক SYN পাঠিয়ে দিলে server-এর pending connection state resource consume হতে পারে।

এটাকে SYN flood attack-এর সঙ্গে দেখা যায়।

Cloudflare-এর SYN flood explanation-এ SYN → SYN/ACK → final ACK sequence এবং incomplete handshakes-এর resource impact ব্যাখ্যা করা হয়েছে।

67. TCP State Machine-এর খুব সংক্ষিপ্ত map

সব implementation detail না ধরে একটি simplified model:

CLOSED
 |
 | connect / active open
 v
SYN-SENT
 |
 | SYN+ACK
 v
ESTABLISHED
 |
 | FIN
 v
FIN-related states
 |
 v
CLOSED

Server-side connection establishment-এ LISTEN, SYN-RECEIVED ইত্যাদি states-ও থাকে।

TCP debugging-এর জন্য state machine পরে আরও গভীরভাবে শেখা খুব উপকারী।

68. Common ভুলগুলো

ভুল ১: TCP packet বলে শেষ

Technicalভাবে TCP transport-এর data unit-কে সাধারণত segment বলা হয়।

IP layer-এ সেটা packet context পায়।

Data Link layer-এ frame হতে পারে।

ভুল ২: Sequence number = packet number

না।

TCP sequence number byte-oriented sequence space track করে।

ভুল ৩: ACK = “এই packet পেলাম”

আরও নির্ভুলভাবে:

ACK = next sequence number expected

ভুল ৪: SYN-এর data sequence X হলে next data X

না।

SYN sequence space-এর 1 unit consume করে।

তাই:

SYN SEQ = X
first data SEQ = X + 1

ভুল ৫: প্রতি data segment-এর জন্য আলাদা ACK packet লাগেই

না।

ACK অন্য data-bearing segment-এর সঙ্গেও piggyback হতে পারে।

ভুল ৬: HTTP request = one TCP segment

না।

TCP byte stream।

ভুল ৭: TCP checksum ভুল data fix করে

না।

Checksum error detect করতে সাহায্য করে; recovery retransmission mechanisms দিয়ে হয়।

ভুল ৮: Ephemeral ports সব OS-এ 49152–65535

IANA registry range এবং OS-এর actual ephemeral allocation policy এক জিনিস নয়।

ভুল ৯: 16384 source ports = 16384 total TCP connections

এটি সরাসরি বলা ঠিক নয়।

Connection uniqueness-এর জন্য endpoint tuple, address selection এবং OS/network behavior গুরুত্বপূর্ণ।

ভুল ১০: FIN মানে সঙ্গে সঙ্গে পুরো connection shutdown

না।

TCP full-duplex বলে direction-wise shutdown হয়।

69. সবচেয়ে গুরুত্বপূর্ণ সংখ্যাগুলো

Port field = 16 bits
Port numeric space = 0–65535

Sequence Number = 32 bits
Acknowledgment Number = 32 bits

Data Offset = 4 bits

TCP header = 20–60 bytes

Window = 16 bits
Checksum = 16 bits
Urgent Pointer = 16 bits

RFC 9293-এর TCP header specification-এর সঙ্গে এই field sizes মিলিয়ে দেখা উচিত।

70. এক পাতায় পুরো TCP

 APPLICATION
 |
 | data
 v
 TCP
 |
 +----------+----------+
 | |
 Ports Sequence
 | |
 | ACK number
 | |
 | Window
 | |
 | Checksum
 | |
 | Flags
 +----------+----------+
 |
 Segment
 |
 v
 IP
 |
 Packet
 |
 v
 Ethernet / Wi-Fi
 |
 Frame
 |
 v
 Physical
 |
 Bits

আর connection lifecycle:

 START
 |
 v
 SYN
 |
 v
 SYN + ACK
 |
 v
 ACK
 |
 v
 ESTABLISHED
 |
 v
 DATA TRANSFER
 |
 v
 FIN/ACK
 |
 v
 FIN/ACK
 |
 v
 CLOSED

71. TCP বোঝার জন্য একটি “five question” framework

যেকোনো TCP packet দেখলে নিজেকে পাঁচটি প্রশ্ন করো:

1. কে পাঠাচ্ছে?

Source IP + Source Port

2. কার কাছে যাচ্ছে?

Destination IP + Destination Port

3. কোন byte থেকে শুরু?

Sequence Number

4. Receiver পরের কোন byte চায়?

Acknowledgment Number

5. Control situation কী?

SYN / ACK / FIN / RST / ...

এগুলো ধরতে পারলে Wireshark-এর একটি TCP packet অনেক কম scary লাগবে।

72. Software Engineer-এর জন্য TCP-এর practical mental model

Browser-এ তুমি লিখলে:

https://example.com

তোমার application logic সাধারণত এভাবে ভাববে:

request পাঠাও
response নাও

কিন্তু নিচে TCP ভাবছে:

আমার local port কী?
remote port কী?
connection established?
আমার sequence space কী?
receiver কত data নিতে পারবে?
কোন bytes acknowledged?
কোন bytes missing?
retransmission দরকার?
connection close হবে?

এই difference-টাই abstraction।

73. শেষ কথা: TCP-কে কীভাবে মনে রাখবে?

TCP মনে রাখার সবচেয়ে ভালো উপায় শুধু সংজ্ঞা মুখস্থ করা নয়।

এই flow-টা মাথায় রাখো:

Application Data
 ↓
TCP Segment
 ↓
Ports
 ↓
Sequence Number
 ↓
ACK Number
 ↓
Flags
 ↓
Window
 ↓
Checksum
 ↓
Options
 ↓
IP
 ↓
Network

Connection-এর lifecycle:

SYN
 ↓
SYN + ACK
 ↓
ACK
 ↓
DATA
 ↓
ACK / WINDOW / RETRANSMISSION
 ↓
FIN
 ↓
ACK
 ↓
FIN
 ↓
ACK

আর সবচেয়ে গুরুত্বপূর্ণ তিনটি mental rule:

Sequence number বলে data stream-এর কোন জায়গায় আছি।

ACK number বলে receiver পরের কোন sequence number আশা করছে।

Window বলে receiver বর্তমানে কত data গ্রহণ করতে প্রস্তুত।

এই তিনটি ভালোভাবে আয়ত্ত করতে পারলে TCP-এর বাকি অংশ অনেক বেশি logical হয়ে যাবে।

74. Quick Revision Sheet

TCP
├── Layer 4
├── Connection-oriented
├── Reliable
├── Ordered byte stream
├── Full duplex
│
├── Header
│ ├── Source Port
│ ├── Destination Port
│ ├── Sequence Number
│ ├── ACK Number
│ ├── Data Offset
│ ├── Reserved
│ ├── Flags
│ ├── Window
│ ├── Checksum
│ ├── Urgent Pointer
│ ├── Options
│ └── Data
│
├── Connection Start
│ ├── SYN
│ ├── SYN+ACK
│ └── ACK
│
├── Data Transfer
│ ├── SEQ
│ ├── ACK
│ ├── Window
│ ├── Checksum
│ └── Retransmission
│
└── Connection Close
 ├── FIN
 ├── ACK
 ├── FIN
 └── ACK

75. References ও Further Reading

Primary technical specification

RFC 9293 — Transmission Control Protocol (TCP)
https://www.rfc-editor.org/rfc/rfc9293.html
RFC Editor — RFC 9293 information page
https://www.rfc-editor.org/info/rfc9293/

Port registry

IANA — Service Name and Transport Protocol Port Number Registry https://www.iana.org/assignments/service-names-port-numbers

Online diagrams

Wikimedia Commons — TCP Header.png
https://commons.wikimedia.org/wiki/File:TCP_Header.png
Wikimedia Commons — TCP Protocol Diagram.png
https://commons.wikimedia.org/wiki/File:TCP_Protocol_Diagram.png
Wikimedia Commons — Tcp-handshake.png
https://commons.wikimedia.org/wiki/File:Tcp-handshake.png

Practical explanations

Cloudflare — What is TCP/IP?
https://www.cloudflare.com/learning/ddos/glossary/tcp-ip/
Cloudflare — SYN Flood DDoS Attack
https://www.cloudflare.com/learning/ddos/syn-flood-ddos-attack/

TCP/IP Model: সফটওয়্যার ইঞ্জিনিয়ারদের জন্য Practical Guide

Ragib Hasan — Tue, 01 Sep 2026 10:03:33 +0000

নেটওয়ার্কিং শিখতে গেলে আমরা সাধারণত প্রথমে OSI 7-Layer Model-এর কথা শুনি। কিন্তু বাস্তব জীবনে কম্পিউটার নেটওয়ার্ক কীভাবে কাজ করে, সেটা বুঝতে গেলে TCP/IP Model সম্পর্কে পরিষ্কার ধারণা থাকা আরও গুরুত্বপূর্ণ।

এই লেখায় আমরা TCP/IP Model-এর ৫টি layer, OSI Model-এর সঙ্গে এর পার্থক্য, TCP বনাম UDP, data encapsulation এবং TCP/IP-এর ঐতিহাসিক পটভূমি—সবকিছু সহজভাবে বুঝব।

OSI বনাম TCP/IP: Layerগুলো কোথায় গেল?

OSI Model-এ মোট ৭টি layer:

Application
Presentation
Session
Transport
Network
Data Link
Physical

অন্যদিকে, TCP/IP Model-কে সাধারণভাবে ৪ বা ৫টি layer-এ উপস্থাপন করা হয়। এই লেখায় আমরা ৫-layer representation ব্যবহার করছি:

Application
Transport
Network
Data Link
Physical

TCP/IP-এর ক্ষেত্রে Presentation এবং Session-এর কাজ আলাদা standalone layer হিসেবে থাকে না; সেগুলোর দায়িত্ব Application layer-এর বিভিন্ন protocol/application-এর মধ্যে বাস্তবায়িত হয়।

একটি গুরুত্বপূর্ণ বিষয়: L7, L4, L3, L2, L1

Software engineering এবং networking-এর কথাবার্তায় এখনও OSI-এর layer numbering ব্যাপকভাবে ব্যবহার করা হয়।

তাই TCP/IP Model-এর ৫টি layer হলেও আমরা সাধারণত বলি:

Application → L7
Transport → L4
Network → L3
Data Link → L2
Physical → L1

অর্থাৎ TCP/IP Model-এর Application layer-কে সাধারণত L7 বলেই আলোচনা করা হয়। একইভাবে Transport হলো L4, Network হলো L3 ইত্যাদি।

TCP/IP Model-এর ৫টি Layer

ধরুন, আপনি একটি কম্পিউটার থেকে আরেকটি কম্পিউটারে "Hello" পাঠাতে চান। এই data এক layer থেকে আরেক layer-এ যাওয়ার সময় বিভিন্ন ধরনের information যোগ করে আরও বড় network unit-এ পরিণত হয়।

চলুন layer by layer দেখি।

1. Application Layer — L7

এটাই software engineer-এর জন্য সবচেয়ে কাছের layer।

আপনি browser, Messenger, WhatsApp বা অন্য কোনো application-এ যখন "Hello" লিখে Send চাপেন, তখন application সেই data নিয়ে কাজ শুরু করে।

Application layer-এর কাজের মধ্যে থাকতে পারে:

Data format করা
JSON/XML-এর মতো format ব্যবহার করা
Compression
Encryption-এর মতো application-level processing
Application-level session/state management
HTTP, HTTPS, DNS ইত্যাদি protocol ব্যবহার করা

সহজভাবে:

User Data → Application Processing → Network-এর জন্য প্রস্তুত Data

উদাহরণ হিসেবে, আপনার application "Hello"-কে একটি structured format-এ রূপান্তর করতে পারে, প্রয়োজন অনুযায়ী compress বা encrypt করতে পারে, এবং এরপর Transport layer-এ পাঠাতে পারে।

Software Engineer হিসেবে কেন L7 গুরুত্বপূর্ণ?

কারণ আমরা যে web application, API, mobile application বা distributed system তৈরি করি, সেগুলোর communication-এর বড় অংশ Application layer-এর protocol-এর ওপর নির্ভর করে।

2. Transport Layer — L4

Application layer-এর data এবার Transport layer-এ আসে।

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

TCP — Transmission Control Protocol
UDP — User Datagram Protocol

এখানেই একটি গুরুত্বপূর্ণ decision আসে:

Data কি reliable delivery চাইছে, নাকি speed এবং low overhead বেশি গুরুত্বপূর্ণ?

TCP: Reliable এবং Controlled Communication

TCP connection-oriented এবং reliable transport প্রদান করে।

ধরুন আপনি একটি গুরুত্বপূর্ণ text message বা API request পাঠাচ্ছেন। Data-এর কোনো অংশ হারিয়ে গেলে বা ভুলভাবে পৌঁছালে সমস্যা হতে পারে।

TCP এই ধরনের communication-এর জন্য sequence, acknowledgement, retransmission, flow control এবং congestion control-এর মতো mechanism ব্যবহার করে reliable byte-stream delivery দেয়।

TCP ব্যবহার করার সাধারণ উদাহরণ:

Web traffic (HTTP/HTTPS, যখন TCP ব্যবহৃত হয়)
API communication
File transfer
Database connection
অন্যান্য reliable application communication

TCP-তে Transport-layer data unit-কে সাধারণত Segment বলা হয়।

UDP: Fast এবং Low-Overhead Communication

UDP-এর design TCP-এর তুলনায় অনেক lightweight।

UDP connection establish করে TCP-এর মতো reliable byte stream তৈরি করে না এবং retransmission-এর মতো reliability mechanism নিজে থেকে প্রদান করে না।

ফলে application-এর জন্য speed, low latency এবং control বেশি গুরুত্বপূর্ণ হলে UDP উপযোগী হতে পারে।

উদাহরণ:

Live streaming-এর কিছু use case
Online gaming
Real-time communication
DNS query
এমন application যেখানে কিছু packet হারানো acceptable এবং application নিজেই প্রয়োজনীয় logic handle করতে পারে

UDP-এর Transport-layer data unit-কে সাধারণত Datagram বলা হয়।

TCP বনাম UDP — দ্রুত মনে রাখার উপায়

বিষয়	TCP	UDP
Reliability	Reliable delivery	Delivery guarantee নেই
Connection	Connection-oriented	Connectionless
Ordering	Ordered byte stream	Ordering guarantee নেই
Retransmission	আছে	নেই
Overhead	বেশি	কম
Data Unit	Segment	Datagram
ব্যবহার	Reliable communication	Low-latency/low-overhead communication

Interview Tip: শুধু “TCP 100% guarantee দেয়” বললে বিষয়টি oversimplified হয়। ভালো উত্তর হবে—TCP reliable, ordered byte-stream delivery এবং retransmission/acknowledgement-এর মতো mechanism প্রদান করে।

3. Network Layer — L3

Transport layer-এর Segment বা Datagram এবার Network layer-এ আসে।

এখানে মূল বিষয় হলো IP addressing এবং routing।

Network layer source এবং destination-এর IP address ব্যবহার করে data-কে network-এর মধ্যে কোথায় যেতে হবে সেটা নির্ধারণে সাহায্য করে।

এ পর্যায়ে:

Transport Data + IP Header → IP Packet

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

IPv4
IPv6

সহজভাবে:

IP address বলে data কোন host/network-এর দিকে যাবে।

4. Data Link Layer — L2

এখন আমাদের Packet local network-এর মধ্যে কীভাবে পৌঁছাবে, সেটা গুরুত্বপূর্ণ।

Data Link layer-এ Ethernet বা Wi-Fi-এর মতো technologies কাজ করে এবং local network delivery-এর জন্য MAC address গুরুত্বপূর্ণ ভূমিকা পালন করে।

এখানে Packet-এর সঙ্গে Data Link header/trailer যুক্ত হয়ে সাধারণত একটি Frame তৈরি হয়।

সহজভাবে:

Packet → Data Link Frame

এখানে source এবং destination MAC address-এর মতো information থাকতে পারে।

IP বনাম MAC

সহজভাবে মনে রাখুন:

IP Address → Logical addressing / routing
MAC Address → Local link-level addressing

একটি router সাধারণত IP routing-এর ভিত্তিতে packet forward করে, আর একটি Ethernet switch local network-এ MAC address table ব্যবহার করে frame forward করতে পারে।

5. Physical Layer — L1

সবশেষে data বাস্তব transmission medium-এর মধ্য দিয়ে যেতে হবে।

Physical layer bits-কে physical signals হিসেবে transmit করার বিষয়টি handle করে।

Medium হতে পারে:

Copper cable
Fiber optic cable
Radio waves / Wi-Fi

Software engineer হিসেবে Physical layer-এর electrical বা signaling details সবসময় গভীরভাবে জানা জরুরি নয়। তবে layerটির basic purpose বোঝা গুরুত্বপূর্ণ।

পুরো Data Flow এক নজরে

ধরুন Application থেকে "Hello" পাঠানো হলো।

Conceptually data নিচের মতো layer থেকে layer-এ যায়:

Application Data
      ↓
TCP → Segment
      ↓
IP → Packet
      ↓
Ethernet/Wi-Fi → Frame
      ↓
Physical → Bits / Signals

অন্যদিকে receiving computer-এ processটি বিপরীত দিকে চলে:

Bits / Signals
      ↓
Frame
      ↓
Packet
      ↓
Segment / Datagram
      ↓
Application Data

এই process-কে networking-এর ভাষায় encapsulation এবং receiving side-এ decapsulation বলা হয়।

TCP/IP-এর ঐতিহাসিক পটভূমি

TCP/IP Model হঠাৎ করে কোনো একদিন একটি complete master plan হিসেবে তৈরি হয়নি। Internet networking-এর বিভিন্ন protocol ধাপে ধাপে বিকশিত হয়েছে।

1969 — ARPANET

1969 সালে ARPANET (Advanced Research Projects Agency Network) চালু হয়। এটি পরবর্তীতে আধুনিক Internet-এর বিকাশে গুরুত্বপূর্ণ ভূমিকা রাখে।

1970s — TCP/IP-এর বিকাশ

এই সময় বিভিন্ন network-কে interconnect করার জন্য নতুন networking protocol নিয়ে গবেষণা চলতে থাকে।

TCP এবং IP একই সময়ে একইভাবে তৈরি হয়নি। এগুলোর development এবং standardization ধাপে ধাপে হয়েছে।

1983 — TCP/IP এবং ARPANET

1983 সালে ARPANET-এর host communication-এ TCP/IP ব্যবহারের transition একটি গুরুত্বপূর্ণ milestone হয়ে ওঠে।

1984 — OSI Model

OSI Model পরে একটি standardized reference framework হিসেবে আসে।

তাই networking শেখার সময় আমরা অনেক ক্ষেত্রে OSI Model দিয়ে fundamental concepts বুঝি, কিন্তু real-world networking-এ TCP/IP protocol suite-ই কেন্দ্রীয়।

Software Engineer হিসেবে কোন Layerগুলো সবচেয়ে গুরুত্বপূর্ণ?

Software engineer হিসেবে আপনার জন্য সবচেয়ে গুরুত্বপূর্ণ:

L7 — Application

HTTP, HTTPS, DNS, APIs, application protocols

L4 — Transport

TCP, UDP, ports, reliability, connection, latency

L3 — Network

IP, routing, subnetting, IPv4/IPv6

L2 — Data Link

MAC address, Ethernet, Wi-Fi, switching

L1 — Physical

Basic ধারণা থাকা ভালো, তবে hardware/electrical details আপনার role অনুযায়ী প্রয়োজন হতে পারে।

একটি বাস্তব উদাহরণ: Browser থেকে Website Open করা

আপনি browser-এ একটি website-এর address লিখলেন এবং Enter চাপলেন।

Conceptually:

Application (L7)

Browser HTTP/HTTPS request তৈরি করে।

↓

Transport (L4)

Communication-এর জন্য TCP বা appropriate transport protocol ব্যবহৃত হয়।

↓

Network (L3)

IP addressing এবং routing-এর মাধ্যমে destination-এর দিকে packet এগোয়।

↓

Data Link (L2)

Local network-এর মধ্যে frame delivery-এর জন্য MAC address এবং link-layer technology কাজ করে।

↓

Physical (L1)

শেষ পর্যন্ত bits/signals network medium-এর মধ্য দিয়ে travel করে।

Destination machine-এ আবার একই process reverse order-এ চলে এবং application শেষ পর্যন্ত response পায়।

Interview-এ কীভাবে TCP বনাম UDP বলবেন?

যদি interviewer জিজ্ঞেস করে:

“TCP এবং UDP-এর মধ্যে পার্থক্য কী?”

তাহলে সংক্ষেপে বলতে পারেন:

TCP হলো connection-oriented এবং reliable transport protocol, যা ordered delivery, acknowledgement এবং retransmission-এর মতো mechanism ব্যবহার করে। UDP হলো connectionless এবং lightweight protocol, যেখানে delivery, ordering বা retransmission-এর built-in guarantee নেই। তাই reliability গুরুত্বপূর্ণ হলে TCP এবং low latency/low overhead গুরুত্বপূর্ণ হলে UDP উপযোগী হতে পারে।

এই উত্তরটি শুধু “TCP fast/UDP slow” ধরনের ভুল ধারণার চেয়ে অনেক বেশি accurate।

শেষ কথা

TCP/IP Model মুখস্থ করার বিষয় নয়—data কীভাবে এক application থেকে অন্য machine-এর application-এ যায়, সেটা বুঝে নেওয়াই আসল বিষয়।

একটি সহজ mental model রাখুন:

Application → Transport → Network → Data Link → Physical

আর data unit মনে রাখুন:

Data → Segment/Datagram → Packet → Frame → Bits

Software engineer হিসেবে অন্তত L7, L4, L3 এবং L2 সম্পর্কে শক্ত ধারণা থাকা অত্যন্ত গুরুত্বপূর্ণ। কারণ backend, distributed systems, cloud, DevOps, SRE, cybersecurity—প্রায় সব ক্ষেত্রেই networking fundamentals বারবার ফিরে আসে।

সবচেয়ে ভালো শেখার পদ্ধতি হলো শুধু পড়া নয়—নিজে লিখুন, diagram আঁকুন, বন্ধুদের সঙ্গে আলোচনা করুন, এবং real-world networking problem দিয়ে conceptগুলো প্রয়োগ করুন।

Networking যত গভীরভাবে বুঝবেন, software systems কীভাবে বাস্তবে communicate করে সেটাও তত পরিষ্কার হবে।

Quick Revision

L7 → Application → HTTP/HTTPS, DNS, APIs
L4 → Transport   → TCP / UDP → Segment / Datagram
L3 → Network     → IP         → Packet
L2 → Data Link   → MAC        → Frame
L1 → Physical    → Signals    → Bits

TCP/IP Model বুঝুন → TCP/UDP বুঝুন → IP ও routing বুঝুন → MAC ও switching বুঝুন → তারপর networking-এর আরও গভীরে যান।

OSI Model-এর Philosophy: Software Engineer ও Docker-এর জন্য Networking-এর সহজ গাইড

Ragib Hasan — Tue, 01 Sep 2026 10:01:47 +0000

Software Engineering, Docker কিংবা Kubernetes---যে ক্ষেত্রেই কাজ করি না
কেন, networking-এর fundamental ধারণাগুলো পরিষ্কার না থাকলে পরবর্তীতে system
design, debugging, load balancing, proxy এবং container networking কঠিন
মনে হতে পারে।

কিন্তু networking শেখার সময় সবচেয়ে বড় সমস্যা হলো আমরা অনেক সময় Layer 1,
Layer 2, Layer 3 মুখস্থ করি, কিন্তু বুঝি না---

এই layerগুলো আসলে কেন আছে?

আরও গুরুত্বপূর্ণ প্রশ্ন হলো:

একটি computer থেকে অন্য computer-এ data কীভাবে যায়?
IP কোথায় যুক্ত হয়?
Port কেন দরকার?
MAC Address-এর কাজ কী?
Segment, Packet, Frame এবং Bit---এগুলোর মধ্যে সম্পর্ক কী?
Docker-এর সঙ্গে OSI Model-এর সম্পর্ক কোথায়?

এই লেখায় OSI Model-কে শুধু পরীক্ষার বিষয় হিসেবে নয়, বরং একজন Software
Engineer-এর networking mental model হিসেবে বোঝার চেষ্টা করব।

১. OSI Model আসলে কী?

OSI এর পূর্ণরূপ:

Open System Interconnection

OSI Model হলো networking-এর একটি conceptual model বা framework।

অর্থাৎ এটি কোনো physical device নয়, কোনো software নয় এবং computer যখন
data পাঠায় তখন সরাসরি "OSI Model" ব্যবহার করে না।

বরং OSI Model আমাদের একটি মানসিক কাঠামো (mental framework)
দেয়---network communication-এর বিভিন্ন দায়িত্বকে কীভাবে আলাদা করে চিন্তা
করা যায়।

ভিডিওর আলোচনায়ও OSI-কে একটি model, framework এবং conceptual philosophy
হিসেবে ব্যাখ্যা করা হয়েছে।

২. OSI Model কেন তৈরি হয়েছিল?

Networking-এর শুরুর দিকে বিভিন্ন vendor এবং organization নিজেদের মতো করে
networking rules ও protocols তৈরি করত।

ধরা যাক---

Company A-এর নিজস্ব communication rules আছে।
Company B-এর অন্য rules আছে।
Company C আবার আলাদা protocol ব্যবহার করছে।

তাহলে সমস্যা কোথায়?

একটি system-এর data অন্য system বুঝতে নাও পারে।

সহজভাবে:

Company A
   |
   | Rules A
   v
Computer A
   X
Computer B
   ^
   | Rules B
Company B

দুই পক্ষের communication-এর rules যদি compatible না হয়, তাহলে
communication কঠিন হয়ে যায়।

এই ধরনের interoperability সমস্যা কমানোর জন্য একটি common
standard/framework প্রয়োজন ছিল।

এখানেই OSI Model-এর ধারণা গুরুত্বপূর্ণ হয়ে ওঠে।

১৯৮৪ সালে ISO-এর মাধ্যমে OSI Model standard হিসেবে উপস্থাপিত হয়।

৩. ISO কী?

ISO হলো:

International Organization for Standardization

এর উদ্দেশ্য বিভিন্ন ক্ষেত্রে international standards তৈরি করা।

Networking-এর ক্ষেত্রেও একটি common conceptual framework প্রয়োজন ছিল---যাতে
বিভিন্ন system-এর communication-কে একই ধরনের layered architecture দিয়ে
বোঝা ও design করা যায়।

তাই OSI Model-এর philosophy-কে এভাবে ভাবতে পারি:

Communication-এর কাজগুলোকে বিভিন্ন logical layer-এ ভাগ করে প্রত্যেক
layer-এর responsibility আলাদা করে দেওয়া।

এটি networking শেখার জন্য অত্যন্ত powerful একটি ধারণা।

৪. System, Open System এবং Interconnection

OSI নামটি বুঝতে হলে তিনটি শব্দ বুঝতে হবে:

Open + System + Interconnection

৪.১ System কী?

সহজভাবে, কিছু component যখন নির্দিষ্ট resource share করে এবং একটি নির্দিষ্ট
উদ্দেশ্যে একসঙ্গে কাজ করে, তখন তাকে একটি system হিসেবে ভাবা যায়।

উদাহরণ:

একটি School System।

এখানে থাকতে পারে:

Students
Teachers
Administration
Infrastructure

এরা বিভিন্ন resource ও responsibility-এর মাধ্যমে একটি system তৈরি করে।

৪.২ Open System কী?

একটি system যদি তার external environment থেকে input গ্রহণ করে এবং
environment-এ output প্রদান করতে পারে, তাহলে সেটিকে open system হিসেবে
বোঝানো যায়।

উদাহরণ:

একটি school-এর students বাইরে থেকে আসে এবং school-এর environment-এ
interaction করে।

অর্থাৎ system এবং external environment-এর মধ্যে interaction রয়েছে।

৪.৩ Interconnection কী?

Interconnection অর্থ একাধিক independent system-এর মধ্যে communication
বা interaction।

এখানে inter এবং intra-র পার্থক্য মনে রাখা যায়।

Intra → একই system-এর ভেতরের interaction
Inter → একাধিক system-এর মধ্যকার interaction

অর্থাৎ:

Open System Interconnection = একাধিক independent open system-এর মধ্যে
communication বোঝার একটি conceptual framework।

৫. OSI Model-এর ৭টি Layer

OSI Model-এ মোট ৭টি layer আছে।

উপরে থেকে নিচে:

L7 --- Application Layer\
সহজভাবে: Application-এর network interaction

L6 --- Presentation Layer\
সহজভাবে: Data representation, encoding, encryption ও compression

L5 --- Session Layer\
সহজভাবে: Communication session management

L4 --- Transport Layer\
সহজভাবে: Ports, segmentation ও data transport

L3 --- Network Layer\
সহজভাবে: IP addressing ও routing

L2 --- Data Link Layer\
সহজভাবে: MAC addressing ও frames

L1 --- Physical Layer\
সহজভাবে: Bits এবং physical transmission

Layer মনে রাখার mnemonic

Please Do Not Tell Secret Password Anyone

নিচ থেকে:

P → Physical
D → Data Link
N → Network
T → Transport
S → Session
P → Presentation
A → Application

অর্থাৎ:

L7 → Application
L6 → Presentation
L5 → Session
L4 → Transport
L3 → Network
L2 → Data Link
L1 → Physical

৬. Layer Number মনে রাখা কেন গুরুত্বপূর্ণ?

Software Engineering এবং networking-এর practical discussion-এ অনেক সময়
layer-এর পুরো নাম না বলে সরাসরি বলা হয়:

তাই:

L2 = Data Link

L3 = Network

L4 = Transport

L7 = Application

বিশেষ করে L2, L4 এবং L7 terminology system design, proxy, load balancing
এবং infrastructure-এর আলোচনায় নিয়মিত আসতে পারে।

৭. সাতটি Layer-কে একটি Data Journey হিসেবে ভাবুন

OSI Model শেখার সবচেয়ে সহজ উপায় হলো এটিকে একটি data journey হিসেবে
দেখা।

ধরা যাক:

Computer A থেকে Computer B-তে "Hello" পাঠাতে হবে।

Sender side-এ data নিচের দিকে নামবে।

Application
     ↓
Presentation
     ↓
Session
     ↓
Transport
     ↓
Network
     ↓
Data Link
     ↓
Physical
     ↓
Network Medium
     ↓
Receiver

Sender side-এ data নিচের দিকে যেতে যেতে বিভিন্ন layer-এর information পায়।

Receiver side-এ আবার উল্টোভাবে উপরের দিকে উঠে যায়।

[DIAGRAM 1 --- এখানে যোগ করুন]

Diagram prompt:

Create a professional 16:9 educational infographic showing the OSI
Model as a seven-layer conceptual framework. Show L7 Application at
the top and L1 Physical at the bottom, with a clear distinction that
OSI is a conceptual model rather than a physical device or software.
Use two computers connected through a network medium and show data
moving through the seven logical layers. Modern software engineering
textbook aesthetic, clean typography, minimal clutter, high
readability.

৮. L7 --- Application Layer

সবচেয়ে উপরের layer হলো:

Layer 7 --- Application Layer

এখানেই আমরা application-এর মাধ্যমে network-এর সঙ্গে interaction করি।

উদাহরণ:

Web browser
Messenger
Web application
Email application
API client

ধরা যাক Messenger-এ আমরা লিখলাম:

Hello

তারপর Send button-এ click করলাম।

এখান থেকে network communication-এর journey শুরু হলো।

Software Engineer কোথায় সবচেয়ে বেশি কাজ করে?

Practical software development-এর ক্ষেত্রে Application Layer অত্যন্ত
গুরুত্বপূর্ণ।

কারণ আমরা তৈরি করি:

Web application
REST API
GraphQL API
Backend service
Microservice
Messaging system

ইত্যাদি।

৯. L6 --- Presentation Layer

এরপর data Presentation Layer-এর ধারণার সঙ্গে সম্পর্কিত হয়।

এই layer-এর মূল ধারণা হলো:

Data কীভাবে represented হবে?

এখানে data representation, encoding, encryption এবং compression-এর মতো
বিষয়গুলোকে conceptualভাবে ধরা হয়।

উদাহরণ:

{
  "message": "Hello"
}

অথবা XML-এর মতো representation।

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

বাস্তব modern networking stack-এ OSI-এর প্রতিটি layer সবসময় আলাদা
software component হিসেবে উপস্থিত থাকে না।

OSI Model মূলত communication-এর responsibility বোঝানোর framework।

১০. L5 --- Session Layer

এরপর:

Layer 5 --- Session Layer

এর মূল ধারণা হলো communication session পরিচালনা করা।

সহজভাবে ভাবুন:

দুই পক্ষের মধ্যে একটি communication চলছে।

তাহলে:

Session শুরু করা
Session বজায় রাখা
Session শেষ করা
প্রয়োজনে session পুনরায় establish করা

এসব ধারণা Session Layer-এর সঙ্গে সম্পর্কিত।

Sender
   |
   | Session
   |
   v
Receiver

১১. L7 + L6 + L5-কে একসঙ্গে কীভাবে ভাবব?

এই তিনটি layer-কে সহজে এভাবে মনে রাখা যায়:

L7 → Application
L6 → Data Representation
L5 → Session

একটি application data তৈরি করছে।

Data একটি নির্দিষ্ট representation-এ যাচ্ছে।

তারপর communication session-এর context বজায় থাকছে।

পরবর্তী layerগুলো data transport-এর networking mechanics-এর দিকে এগিয়ে
যায়।

১২. L4 --- Transport Layer

এখন আসছে networking-এর সবচেয়ে গুরুত্বপূর্ণ layerগুলোর একটি:

Layer 4 --- Transport Layer

এখানে দুটি গুরুত্বপূর্ণ ধারণা:

Port

এবং

Segment

ধরা যাক একটি computer-এ একই সময়ে অনেক application চলছে:

Computer
|
├── Browser
├── Messenger
├── API Server
└── Database Client

এখন অন্য computer থেকে data এলে প্রশ্ন হলো:

এই data কোন application-এর কাছে যাবে?

এখানে Port Number গুরুত্বপূর্ণ।

১৩. IP বনাম Port --- একটি সহজ analogy

একটি পাঁচতলা building কল্পনা করুন।

Building-এর একটি address আছে।

এটি হলো:

IP Address

কিন্তু building-এর ভিতরে অনেক apartment বা service আছে।

কোন service-এ যেতে হবে সেটা আলাদা করে বলতে হবে।

এটি হলো:

Port

অর্থাৎ সহজ mental model:

IP   → কোন host/network?
Port → সেই host-এর কোন application/service?

উদাহরণ:

192.168.1.10:3000

এখানে:

192.168.1.10 → IP
3000         → Port

১৪. Transport Layer-এর Segment

Transport Layer data-কে প্রয়োজন অনুযায়ী ছোট অংশে ভাগ করে transport করতে
পারে।

সহজভাবে:

Large Data
    |
    v
+---------+
| Segment |
+---------+
| Segment |
+---------+
| Segment |
+---------+
| Segment |
+---------+

এগুলোকে বলা হয়:

Segments

Simplified conceptual model হিসেবে segment-এর সঙ্গে source এবং
destination port-এর ধারণা যুক্ত হয়।

Source Port
     |
     v
+----------------------+
|        DATA          |
+----------------------+
     ^
     |
Destination Port

১৫. L3 --- Network Layer

এরপর data যায়:

Layer 3 --- Network Layer

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

IP Address

যদি Port দিয়ে বোঝানো হয়---

কোন application/service?

তাহলে IP দিয়ে বোঝানো হয়---

কোন host/network-এর দিকে data যাবে?

উদাহরণ:

Sender IP
    |
192.168.1.10

       DATA

Receiver IP
    |
192.168.1.20

১৬. Segment থেকে Packet

Network Layer-এর conceptual data unit হলো:

Packet

সহজভাবে:

Transport Layer

+---------------------+
| Source Port         |
| Data                |
| Destination Port    |
+---------------------+
          |
          v
Network Layer
          |
          v
+---------------------+
| Source IP           |
|       Packet        |
| Destination IP      |
+---------------------+

তাই মনে রাখুন:

L4 → Segment

L3 → Packet

১৭. IP Address বনাম Port

এই দুইটি গুলিয়ে ফেললে networking-এর পরবর্তী অংশ কঠিন হয়ে যাবে।

একটি সহজ analogy:

              BUILDING
          192.168.1.10
               IP
                |
       +--------+--------+
       |        |        |
     :3000    :5000    :8000
       |        |        |
     App A    App B    App C

এখানে:

IP = Building-এর address

Port = নির্দিষ্ট application/service-এর endpoint

এটি একটি learning analogy; বাস্তব networking implementation এর চেয়ে
বিষয়টি আরও বিস্তারিত।

১৮. L2 --- Data Link Layer

এরপর:

Layer 2 --- Data Link Layer

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

MAC Address

MAC Address local network/link-এর ক্ষেত্রে network interface-এর link-layer
address হিসেবে ব্যবহৃত হয়।

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

MAC Address-কে সবসময় "সারা জীবনের জন্য অপরিবর্তনীয় physical address"
হিসেবে ভাবা ঠিক নয়।

বাস্তবে MAC address spoof বা change করা সম্ভব এবং কিছু operating system
privacy/randomization-এর জন্য randomized MAC ব্যবহার করতে পারে।

তবে learning-এর জন্য:

IP = logical/network-level address

MAC = link-layer address

এই mental model অত্যন্ত কার্যকর।

১৯. Packet থেকে Frame

Data Link Layer-এর conceptual PDU:

Frame

সহজভাবে:

Network Layer
      |
      | Packet
      v
Data Link Layer
      |
      v
+----------------------------+
| Destination MAC            |
|                            |
|          Packet            |
|                            |
| Source MAC                 |
+----------------------------+

            ↓

           Frame

তাই:

L3 → Packet

L2 → Frame

২০. L1 --- Physical Layer

সবশেষে:

Layer 1 --- Physical Layer

এখানে আমরা পৌঁছে যাই Bits-এ।

Frame
  ↓
Bits
  ↓
0101010101010101

এই bits physical medium-এর মাধ্যমে signal হিসেবে transmit হয়।

Medium হতে পারে:

Copper cable
Fiber optic
Wireless transmission

Physical Layer-এর মূল concern হলো physical medium-এর মাধ্যমে signal
transmission।

২১. পুরো OSI Journey একসঙ্গে

[DIAGRAM 2 --- এখানে যোগ করুন]

Diagram prompt:

Create a professional 16:9 OSI encapsulation and de-encapsulation
infographic. Show Sender Computer on the left and Receiver Computer on
the right. On the sender side, show L7 Application data moving
downward through L6 Presentation, L5 Session, L4 Transport, L3
Network, L2 Data Link, and L1 Physical. Clearly visualize the
conceptual transformation Data → Segment → Packet → Frame → Bits. Show
source/destination ports at L4, source/destination IP at L3, and
source/destination MAC at L2. Show bits traveling across a network
medium to the receiver, then reverse the process on the receiver: Bits
→ Frame → Packet → Segment → Data. Use clean arrows, technically
accurate labels, professional networking textbook style, 16:9 aspect
ratio.

২২. Sender Side-এ কী ঘটে?

একটি simplified conceptual flow:

Application
    |
    | "Hello"
    v
Presentation
    |
    | Data representation
    v
Session
    |
    v
Transport
    |
    | Port + Data
    | Segment
    v
Network
    |
    | IP + Segment
    | Packet
    v
Data Link
    |
    | MAC + Packet
    | Frame
    v
Physical
    |
    | Bits
    v
Network Medium

২৩. Receiver Side-এ কী ঘটে?

Receiver side-এ process-এর direction উল্টো।

Physical
    |
    | Bits
    v
Data Link
    |
    | Frame
    v
Network
    |
    | Packet
    v
Transport
    |
    | Segment
    v
Session
    |
    v
Presentation
    |
    v
Application
    |
    v
"Hello"

এখানে layerগুলো নিজেদের relevant information process/remove করে data-কে
পরবর্তী layer-এর কাছে দেয়।

এই process-কে সাধারণভাবে বলা হয়:

Encapsulation → Sender side

De-encapsulation → Receiver side

২৪. Encapsulation কী?

Sender side-এ data যখন নিচের layer-গুলো দিয়ে যায়, তখন প্রতিটি layer নিজের
প্রয়োজনীয় information যোগ করে।

Application
   |
   | Data
   v
Transport
   |
   | Port + Data
   v
Network
   |
   | IP + Segment
   v
Data Link
   |
   | MAC + Packet
   v
Physical
   |
   | Bits
   v
Network

এই wrapping process-ই encapsulation নামে পরিচিত।

২৫. De-encapsulation কী?

Receiver side-এ বিপরীত ঘটনা ঘটে।

Bits
 ↓
Frame
 ↓
Packet
 ↓
Segment
 ↓
Data

প্রতিটি relevant layer তার information process করে পরবর্তী layer-এর কাছে
payload পাঠায়।

শেষে Application সেই original data পায়।

২৬. চারটি শব্দ মনে রাখুন

Networking শেখার সময় এই চারটি term খুব গুরুত্বপূর্ণ।

L4 → Segment
L3 → Packet
L2 → Frame
L1 → Bits

আর addressing-এর simplified mental model:

L4 → Port
L3 → IP
L2 → MAC

২৭. IP, Port, MAC --- তিনটি একসঙ্গে

[DIAGRAM 3 --- এখানে যোগ করুন]

Diagram prompt:

Create a clean professional 16:9 educational infographic explaining
the relationship between IP Address, Port, and MAC Address. Use a
simplified building analogy: IP Address represents the host/building
address, Port represents a specific application/service endpoint, and
MAC Address represents the link-layer address of a network interface.
Beside the analogy, show a simplified networking data structure with
Source MAC, Destination MAC, Source IP, Destination IP, Source Port,
Destination Port, and Payload. Add a small note: "Simplified learning
analogy --- real networking is more detailed." Modern computer
networking textbook style, highly readable, minimal visual clutter.

২৮. Software Engineer-এর জন্য OSI Model কেন গুরুত্বপূর্ণ?

ধরা যাক application কাজ করছে না।

Browser থেকে request যাচ্ছে না।

তখন একজন engineer যদি শুধু application code দেখে, debugging-এর scope খুব
সীমিত থাকে।

কিন্তু networking-এর layered mental model থাকলে প্রশ্নগুলো হয়:

L7 → Application ঠিক আছে?
       ↓
L4 → Port open/listening?
       ↓
L3 → IP/reachability ঠিক আছে?
       ↓
L2 → Local link/interface ঠিক আছে?
       ↓
L1 → Physical connectivity আছে?

এটাই OSI Model-এর practical power।

এটি debugging-কে structured করে।

২৯. Docker-এর সঙ্গে OSI Model-এর সম্পর্ক কোথায়?

এখানেই একজন Software Engineer-এর জন্য OSI Model সবচেয়ে useful হয়ে ওঠে।

Docker-এ যখন আমরা দেখি:

docker run -p 8080:3000 app

তখন আমরা Port এবং port mapping-এর ধারণার সঙ্গে কাজ করছি।

যখন দেখি:

Container IP
Host IP

তখন Layer 3-এর networking concepts সামনে আসে।

Docker network তৈরি করলে:

docker network create my-network

container-to-container communication, network interfaces, bridges,
routing ইত্যাদি নিয়ে কাজ করতে গিয়ে বিভিন্ন networking concept সামনে আসে।

আর যখন দেখি:

HTTP
HTTPS
TCP
IP
Ethernet

তখন আমরা বিভিন্ন networking abstraction এবং protocol-এর সঙ্গে কাজ করছি।

অর্থাৎ OSI Model মুখস্থ করার উদ্দেশ্য Docker-এ "OSI command" চালানো নয়।

বরং উদ্দেশ্য হলো:

Docker-এর networking behaviour দেখলে তার পেছনের networking concepts
চিনতে পারা।

৩০. Load Balancer-এর সঙ্গে Layer ধারণা

পরবর্তীতে system design বা infrastructure নিয়ে কাজ করলে এমন terminology
শুনবেন:

Layer 4 Load Balancer
Layer 7 Load Balancer
L4 Proxy
L7 Proxy

এখানে L4 এবং L7 কী বোঝায় তা জানা থাকলে পুরো conversation অনেক সহজ হয়।

L4

Transport-level information-এর উপর কাজ করতে পারে।

যেমন:

TCP
UDP
Port

L7

Application-level information বুঝতে পারে।

যেমন:

HTTP
HTTPS
Host
Path
Headers

তাই:

L4 এবং L7 terminology একজন Software/Infrastructure Engineer-এর জন্য
অত্যন্ত গুরুত্বপূর্ণ।

৩১. Common Protocols & Examples by Layer

LinkedIn Article-এ table ব্যবহার না করে এই format ব্যবহার করা ভালো।

L7 --- Application Layer

Examples: HTTP, HTTPS, SMTP, FTP

Used for application-level network communication such as web requests,
email, and file transfer.

L6 --- Presentation Layer

Examples: TLS, Encoding, Compression

Concerned with how data is represented, encoded, encrypted, or
compressed.

L5 --- Session Layer

Examples: Session management concepts

Concerned with establishing, maintaining, and terminating communication
sessions.

L4 --- Transport Layer

Examples: TCP, UDP

Responsible for transport-level communication, including ports and
segmentation.

L3 --- Network Layer

Example: IP

Responsible for logical addressing and routing data between networks.

L2 --- Data Link Layer

Examples: Ethernet, Wi-Fi, ARP-related link/network interaction

Responsible for link-level communication, including MAC addressing and
frames.

L1 --- Physical Layer

Examples: Copper, Fiber, Wireless physical transmission

Responsible for transmitting bits as physical signals through a medium.

৩২. OSI Model বনাম বাস্তব Internet

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

বাস্তব Internet সাধারণত OSI Model-এর সাতটি layer-কে textbook-এর মতো আলাদা
সাতটি independent component হিসেবে implement করে না।

বাস্তবে আমরা বেশি ব্যবহার করি:

TCP/IP Model / Internet Protocol Suite

OSI Model মূলত একটি reference model।

অর্থাৎ এটি আমাদের বলে:

"Networking-এর responsibilities-গুলোকে এভাবে চিন্তা করো।"

আর TCP/IP architecture বাস্তব Internet protocols-এর সঙ্গে বেশি সরাসরি
সম্পর্কিত।

এই distinction বুঝে রাখা ভবিষ্যতে খুব কাজে দেবে।

৩৩. OSI Model-এর Layer এবং Protocol নিয়ে একটি সতর্কতা

অনেক educational resource-এ নির্দিষ্ট protocol-কে নির্দিষ্ট OSI layer-এর
সঙ্গে rigidভাবে map করা হয়।

বাস্তবে protocol stack এতটা rigid নয়।

বিশেষ করে modern networking-এ কিছু protocol একাধিক layer-এর concern-এর
সঙ্গে সম্পর্কিত হতে পারে।

তাই protocol mapping-কে learning model হিসেবে ব্যবহার করা ভালো,
absolute rule হিসেবে নয়।

৩৪. সবচেয়ে গুরুত্বপূর্ণ Mental Model

এখন পুরো বিষয়টিকে কয়েকটি প্রশ্নে নামিয়ে আনুন।

Application কী?

আমি কী data পাঠাচ্ছি?

Presentation কী?

Data কীভাবে represent/encode/secure করা হবে?

Session কী?

Communication session কীভাবে manage হবে?

Transport কী?

কোন application/service এবং কীভাবে data transport হবে?

Network কী?

কোন host/network-এর দিকে data যাবে?

Data Link কী?

Local link-এ কোন interface-এর দিকে frame যাবে?

Physical কী?

Data কীভাবে actual signal হিসেবে transmit হবে?

৩৫. এক নজরে পুরো OSI Model

[DIAGRAM 4 --- এখানে যোগ করুন]

Diagram prompt:

Create a polished one-page OSI Model cheat-sheet infographic in 16:9
format. Show seven horizontal stacked layers from L7 to L1. L7
Application: HTTP, HTTPS, SMTP; L6 Presentation: representation,
encoding, encryption, compression; L5 Session: session management; L4
Transport: TCP, UDP, ports, Segment; L3 Network: IP, routing, Packet;
L2 Data Link: MAC, Ethernet, Wi-Fi, Frame; L1 Physical: signals,
cables, wireless, Bits. Highlight the PDU for L4/L3/L2/L1. Add the
mnemonic "Please Do Not Tell Secret Password Anyone". Use a
professional software-engineering/networking textbook aesthetic, clean
typography, strong hierarchy, minimal clutter, high readability.

৩৬. OSI Model মনে রাখার Final Shortcut

প্রথমে mnemonic:

Please Do Not Tell Secret Password Anyone

তারপর layer mapping:

L7 → Application
L6 → Presentation
L5 → Session
L4 → Transport
L3 → Network
L2 → Data Link
L1 → Physical

তারপর সবচেয়ে গুরুত্বপূর্ণ চারটি:

L4 → Segment → Port
L3 → Packet  → IP
L2 → Frame   → MAC
L1 → Bits

এবং একটি simplified journey:

DATA
 ↓
SEGMENT
 ↓
PACKET
 ↓
FRAME
 ↓
BITS

Receiver side-এ:

BITS
 ↓
FRAME
 ↓
PACKET
 ↓
SEGMENT
 ↓
DATA

৩৭. শেষ কথা: OSI Model মুখস্থ করার বিষয় নয়

OSI Model শেখার সবচেয়ে বড় উদ্দেশ্য সাতটি layer-এর নাম মুখস্থ করা নয়।

আসল উদ্দেশ্য হলো networking-এর একটি layered mental model তৈরি করা।

যখন ভবিষ্যতে শুনবেন:

"L4 Load Balancer"

আপনার মাথায় Transport Layer আসবে।

যখন শুনবেন:

"L7 Proxy"

আপনি Application Layer-এর কথা ভাববেন।

যখন দেখবেন:

192.168.1.10:3000

তখন বুঝবেন:

IP   → 192.168.1.10
Port → 3000

যখন শুনবেন:

Segment

তখন:

যখন শুনবেন:

Packet

তখন:

যখন শুনবেন:

Frame

তখন:

যখন শুনবেন:

Bits

তখন:

এটাই OSI Model শেখার আসল লাভ।

কারণ একজন Software Engineer-এর জন্য networking-এর প্রতিটি বিষয় আলাদা আলাদা
chapter নয়। বরং একটির সঙ্গে আরেকটির connection বুঝতে পারাটাই গুরুত্বপূর্ণ।

OSI Model সেই connection দেখার একটি framework।

আর এই foundation পরিষ্কার হলে পরবর্তী সময়ে TCP/IP, TCP, UDP, IP Address,
Port, Ethernet, ARP, DNS, HTTP/HTTPS, Proxy, Load Balancer, Docker
Networking এবং Kubernetes Networking---এসব বিষয় অনেক বেশি logically
connect করা যায়।

Quick Revision

OSI = Open System Interconnection

L7 → Application
L6 → Presentation
L5 → Session
L4 → Transport
L3 → Network
L2 → Data Link
L1 → Physical

Mnemonic:
Please Do Not Tell Secret Password Anyone

Core PDU:
L4 → Segment
L3 → Packet
L2 → Frame
L1 → Bits

Core Addressing Concepts:
L4 → Port
L3 → IP
L2 → MAC

Sender:
Data → Segment → Packet → Frame → Bits

Receiver:
Bits → Frame → Packet → Segment → Data

ডকারফাইল বিল্ডের ভেতরের জাদু: ইন্টারমিডিয়েট লেয়ার ও ক্যাশিং মেকানিজম (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. 🐳

DEV Community: Ragib Hasan

Mental Health Score Prediction Project — সম্পূর্ণ Bangla Explanation

সূচিপত্র

1. Project Overview

2. কেন এই project শুধু “ML notebook project” না

3. Problem Statement — Regression কেন?

Classification হলে কেমন হতো?

Regression-এর সাধারণ algorithm

4. Dataset

Input vs Target

5. Libraries Import

NumPy

Pandas

Matplotlib

Seaborn

6. Dataset Load

7. Shape Check

8. First 5 Rows

9. Missing Values

Real-world data-তে কী হতে পারে?

Numeric missing value example

Categorical missing value example

10. Duplicate Rows

11. df.info() — Data Type বোঝা

object মানে কী?

12. df.describe() — Descriptive Statistics

Physical Activity-এর invalid value

13. EDA কী?

14. Plot 1 — Target Distribution

Histogram কী দেখায়?

KDE কী?

কেন target distribution দেখা দরকার?

15. Correlation Heatmap

Correlation কী?

Positive Correlation

Negative Correlation

Near Zero

numeric_only=True কেন?

annot=True কেন?

গুরুত্বপূর্ণ সতর্কতা

16. Stress Level vs Mental Health Score

কেন Boxplot?

17. Daily Social Media Usage vs Mental Health

18. Sleep vs Mental Health

19. Most Used Platform

value_counts().index কেন?

20. Outlier কী?

21. IQR Method

Formula

Example

গুরুত্বপূর্ণ

22. Data Cleaning

clip(lower=0) কেন?

23. Skewness

Right Skew example

Left Skew example

কেন Linear Regression-এর জন্য relevant?

24. Feature Engineering — Country Grouping

Solution

কেন original Country পুরো drop করা হলো না?

25. Encoding Strategy

26. Ordinal Encoding — Stress Level

কেন One-Hot না?

27. One-Hot Encoding

handle_unknown='ignore'

28. Train-Test Split

Note

29. Train/Test কেন?

30. Data Leakage

31. Pipeline এবং ColumnTransformer

Problem

ColumnTransformer কী করে?

32. Skewed Feature Pipeline

np.log1p(x) কী?

33. Numeric Pipeline

StandardScaler কী করে?

34. Ordinal Pipeline

35. Nominal Pipeline

36. ColumnTransformer

37. Final Model Pipeline কেন?

11. `df.info()` — Data Type বোঝা

`object` মানে কী?

12. `df.describe()` — Descriptive Statistics

`numeric_only=True` কেন?

`annot=True` কেন?

`value_counts().index` কেন?

`clip(lower=0)` কেন?

`handle_unknown='ignore'`

`np.log1p(x)` কী?

`n_estimators`

`max_depth`

`min_samples_split`

`min_samples_leaf`

44. Pipeline parameter name-এ `__` কেন?

`n_iter=15`

`cv=5`

`scoring='r2'`

`n_jobs=-1`

64. `/predict` Route

71. `collectPayload()`

74. API Call with `fetch`