পাঠ ৬ · ৩৩-এর মধ্যে · মডিউল ১

Home / AI Courses / MLOps / Docker for ML

Docker — ML-এর জন্য container

Docker for ML — reproducible containers

৮ মিনিট পড়া মধ্য · Intermediate Dockerfile

এই পাঠে যা শিখবেন

ML-এর জন্য Dockerfile-এর সাধারণ structure
Multi-stage build — image size optimization
GPU container — CUDA, cuDNN base image
Security baseline — non-root user, image scan

১ · কেন Docker, কেন container

একজন data scientist-এর laptop-এ মডেল চলে; production server-এ চলে না। কারণ — Python version, OS lib, CUDA version — কিছু না কিছু ভিন্ন। Docker এই সমস্যা solve করে — পুরো environment-কে একটি container imageContainer Imageএকটি portable, immutable bundle — OS subset + runtime + libraries + code। Docker এর জনপ্রিয় engine।-এ bundle।

Reproducibility: "my-image:v1.2.3" — যেকোনো machine-এ same behavior।
Portability: laptop, CI server, K8s cluster — সব জায়গায় চালু।
Isolation: dependency conflict অন্য container-কে effect করে না।

২ · ML-এর জন্য একটি minimal Dockerfile

Dockerfile · Minimal CPU image

# slim base — ছোট, কিন্তু python-ready
FROM python:3.11.7-slim AS runtime

# system dep (যদি দরকার, যেমন libgomp ML libraries-এর জন্য)
RUN apt-get update && apt-get install -y --no-install-recommends \
    libgomp1 \
    && rm -rf /var/lib/apt/lists/*

# non-root user (security)
RUN useradd --create-home --shell /bin/bash mluser
WORKDIR /app

# dependency layer আগে — caching benefit
COPY requirements.lock /app/requirements.lock
RUN pip install --no-cache-dir -r requirements.lock

# app code
COPY --chown=mluser:mluser . /app
USER mluser

# health & entrypoint
EXPOSE 8000
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

চারটি গুরুত্বপূর্ণ pattern: (১) pinned base image, (২) requirements layer আগে — code change হলেও pip install cache, (৩) non-root user, (৪) --no-cache-dir — image size ছোট।

৩ · Multi-stage build — slim production image

Training-এর জন্য heavy dependencies (jupyter, debugpy, build tools) দরকার। Production-এ লাগে না। Multi-stage build দু'টো ভিন্ন context গড়ে।

Dockerfile · Multi-stage

# Stage 1 — builder (heavy, with compilers)
FROM python:3.11.7-slim AS builder

RUN apt-get update && apt-get install -y --no-install-recommends \
    build-essential gcc \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /build
COPY requirements.lock .
# wheel ফাইল pre-build করি
RUN pip wheel --no-cache-dir -r requirements.lock -w /wheels

# Stage 2 — runtime (slim, no compilers)
FROM python:3.11.7-slim AS runtime

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

RUN useradd --create-home --shell /bin/bash mluser
WORKDIR /app

# wheel-গুলো installed
COPY --from=builder /wheels /wheels
RUN pip install --no-cache-dir --no-index --find-links=/wheels /wheels/*.whl \
    && rm -rf /wheels

COPY --chown=mluser:mluser app/ /app/
USER mluser
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

Builder stage compiler/headers carries। Runtime image-এ শুধু wheels copy হয় — compiler থাকে না। ফলে production image ৩০০ MB থেকে ৮০ MB-তে নামতে পারে।

৪ · GPU container — CUDA base image

Deep learning model GPU-তে train ও infer। Python packages CUDA-aware হলেও — host-এ proper driver + container-এ CUDA runtime দরকার।

Base image: nvidia/cuda:12.1.0-cudnn8-runtime-ubuntu22.04 (inference) or ...-devel-... (training)।
Host: NVIDIA driver compatible version + nvidia-container-toolkit।
Run: docker run --gpus all my-image।
K8s: GPU resource request nvidia.com/gpu: 1।

Dockerfile · GPU PyTorch

FROM nvidia/cuda:12.1.0-cudnn8-runtime-ubuntu22.04

ENV DEBIAN_FRONTEND=noninteractive \
    PYTHONUNBUFFERED=1

RUN apt-get update && apt-get install -y --no-install-recommends \
    python3.11 python3-pip libgomp1 \
    && ln -sf /usr/bin/python3.11 /usr/bin/python \
    && rm -rf /var/lib/apt/lists/*

RUN useradd --create-home mluser
WORKDIR /app

COPY requirements.lock .
RUN pip install --no-cache-dir torch==2.2.0 --index-url https://download.pytorch.org/whl/cu121 \
    && pip install --no-cache-dir -r requirements.lock

COPY --chown=mluser:mluser . /app/
USER mluser
CMD ["python", "serve.py"]

Note: PyTorch CUDA wheel আলাদা index URL থেকে — cu121 = CUDA 12.1। Image বিশাল হয় (২-৪ GB) — multi-stage এখানে কম effective, কারণ wheels-ই বিশাল। Better — separate base image team-wide।

৫ · Image size optimization

slim/alpine base: python:3.11-slim ~১২০ MB; alpine ~৪০ MB কিন্তু ML-এ glibc compatibility issues।
--no-cache-dir: pip cache না রাখা।
Multi-stage: compilers throw away।
.dockerignore: .git, tests, notebooks, data — image-এ যাবে না।
Layer ordering: rare-change first (system deps), frequent-change last (code)।
Buildkit: parallel layer + cache mount — faster + smaller।

৬ · Security baseline

Non-root user: default root → mluser। Container escape-এর mitigation।
Read-only filesystem: K8s deployment-এ readOnlyRootFilesystem: true।
Image scanning: Trivy, Grype — known CVE check।
Pin base image SHA: tag mutable হতে পারে; @sha256:... immutable।
No secrets in image: API key, DB password — env var বা secret manager।
Distroless base: Google distroless — minimum, no shell, super-secure।

Multi-stage build — ১ম stage-এ heavy build tools, ২য় stage-এ শুধু runtime artifacts। Image size ৮০-৯০% reduce, security surface কমে।

ML-এর জন্য Docker একটি essential skill। MLOps maturity Level 1+ পর্যায়ে আপনার প্রতিটি training run, প্রতিটি serving — Docker-এ চলবে। যত আগে কঠিন বুঝবেন — পরের পাঠগুলো তত সহজ।

ভাবনার প্রশ্ন

প্র ০১ "আমার Docker image ৫ GB। এটা সমস্যা?" — কখন size matters, কখন matter করে না?

Image size সবসময় optimize করার দরকার নেই — context-dependent।

সমস্যা যখন:

Cold start: Lambda/Fargate/serverless — ৫ GB image pull-এ ১-২ মিনিট। User-facing এ unacceptable।
Auto-scaling: traffic spike → নতুন pod start → image pull → response delay।
Edge deployment: mobile/IoT — bandwidth limited। ৫ GB unusable।
Cost: registry storage cost (ECR ~$০.১/GB/month)। ১০০টি model × ৫ GB = ৫০ GB = $৫/month — small but accumulates।

সমস্যা না যখন:

Dedicated long-running pod: K8s deployment image once-pull, container days run।
Internal batch job: nightly training, latency irrelevant।
GPU image inherent size: CUDA + cuDNN + PyTorch GPU = ৩ GB minimum। আরও কমানো effortless না।

Optimization approach:

First — dive into layers: docker history my-image। কোন layer কত MB।
Common waste: apt cache, pip cache, build artifacts, .git, test files, sample notebooks।
Diminishing returns: ৫ GB → ৩ GB easy। ৩ GB → ২ GB possible। ২ GB → ১ GB অনেক effort।

"Layer caching" benefit:

৫ GB image-এ shared layers (CUDA, PyTorch) cached at registry এবং pull caching।
"My ৫ GB image-এ ৪ GB CUDA — shared with ৫০ অন্য image" → effective per-image cost ~১ GB।
ECR/GCR-এ caching — second pull অনেক fast।

Bangladesh context:

Local data center / cloud — bandwidth ক্ষেত্রে cost matter। On-prem, image registry close → less concerned।
BD-host server-এ AWS Mumbai pull → not super fast — image cache critical।

Concrete decision tree:

Cold start matters → minimize aggressively।
Long-running pod, on-prem cache → 5 GB acceptable।
CI/CD bottleneck → optimize layer caching first।

মূল উপলব্ধি: Image size একটি engineering trade-off — premature optimization waste। First measure (cold start time, deployment frequency, user impact)। Then optimize where it actually hurts। GPU image-এ "৫ GB normal" — অহেতুক shame না।

প্র ০২ "CUDA version mismatch" — host driver, container CUDA, PyTorch CUDA — কে কোনটা control করে?

GPU container-এর সবচেয়ে confusing দিক — ৩-layered version dependency।

৩-tier version structure:

Host NVIDIA driver: kernel-level, host machine-এ install। CUDA version-এর support window decide করে।
Container CUDA toolkit: image-এ। User-space CUDA libraries, math kernels।
Framework CUDA build: PyTorch / TensorFlow CUDA-targeted wheel।

Compatibility rules:

Driver-CUDA forward compatible: driver 525 → CUDA 11.8, 12.0, 12.1 all OK।
Driver minimum: CUDA 12.1 → minimum driver 525।
Framework-CUDA exact: PyTorch built for CUDA 11.8 — works with CUDA 11.8 ও 12.x runtime usually। But "minor version drift" সাধারণত fine, "major" drift sometimes break।

Common scenarios:

Newer driver, older container CUDA: usually works (forward compat)।
Older driver, newer container CUDA: fails — driver too old।
Driver mismatch on K8s nodes: node taint দিয়ে handle।

Diagnosis tools:

nvidia-smi on host → driver + max CUDA supported।
docker run --gpus all nvidia/cuda:12.1.0-base nvidia-smi → container সদর-দর্শন।
python -c "import torch; print(torch.version.cuda)" → PyTorch's bundled CUDA।
torch.cuda.is_available() → end-to-end check।

Common pitfalls:

Mixed driver across nodes: node-A driver 525, node-B driver 470। Workload schedule random, sometimes fail।
Spot/preemptible-এ random GPU: A100 vs T4 — different compute capability।
Reboot reset: driver upgrade-এর পর reboot না হলে — old driver runtime, new claim।

Best practice:

Image-এ explicit CUDA version pin (e.g., nvidia/cuda:12.1.0-cudnn8-runtime-ubuntu22.04)।
PyTorch wheel matching CUDA index URL।
Cluster-wide driver standardize।
Health check: container start-এ torch.cuda.is_available() assert।

মূল উপলব্ধি: CUDA stack একটি onion — host driver outer-most, container CUDA middle, framework innermost। ভিতরের ভিতরের লেয়ার বদলালে সহজে দেখা যায় না; outer change সব ভিতরের impact। Driver-CUDA-PyTorch combo lock down — ব্যর্থ deployment-এর সবচেয়ে common cause এড়ানো।

প্র ০৩ "Docker Compose ML dev-এ ব্যবহার করা উচিত?" — কখন good, কখন overkill?

Docker Compose একটি multi-container orchestration tool — single host-এ। ML dev-এ ব্যবহার common, কিন্তু সঠিক context চাই।

ML dev-এ Compose কোথায় valuable:

Multi-service local stack: MLflow server + PostgreSQL backend + MinIO artifact store + your training code — চারটি service এক docker compose up-এ।
Reproducible team environment: নতুন engineer "git clone + docker compose up" — ১৫ মিনিটে full local environment।
Database/cache dependency: Redis, Postgres, RabbitMQ — Compose-এ pre-configured।
Integration testing: CI-তে full stack run, end-to-end test।

Compose overkill যখন:

Single training script: docker run my-image train.py — simpler।
Notebook-only workflow: Jupyter container alone যথেষ্ট।
K8s production target: Compose ↔ K8s manifest ভিন্ন। প্রায়ই duplicate maintenance।

Production-এ Compose না:

Compose single-host orchestrator। Scale, fault tolerance, rolling update — K8s-এর কাজ।
"docker-compose.prod.yml" anti-pattern — production-এ K8s বা ECS।

Bangladesh dev team common setup:

compose.yml-এ: model service + MLflow + Postgres + MinIO + Adminer।
GPU support: deploy.resources.reservations.devices।
Volume mount: code change → live reload।

Common Compose anti-patterns in ML:

Service-এ health check absent — depends_on race condition।
Volume permissions wrong — host write, container read fail।
Hardcoded ports — multiple project-এ port collision।

Alternative — devcontainer (VS Code):

Compose + IDE integration। Single click "open in container"।
.devcontainer/devcontainer.json + compose.yml combo।

মূল উপলব্ধি: Compose ML local dev-এ চমৎকার tool — multi-service stack-এ। Production-এ ব্যবহার-এর জন্য না। Compose vs K8s — single-host vs cluster-orchestration। দুটো-ই ML lifecycle-এ আছে, ভিন্ন stage-এ।

প্র ০৪ ML container-এ security কী কী আলাদা চিন্তা — DevOps-এর তুলনায়?

ML container security অনেকটা DevOps-এর সাথে overlap, কিন্তু ML-specific দিক আছে।

Common with DevOps (অবশ্যই করুন):

Non-root user।
Minimal base image (slim/distroless)।
Pinned base image SHA।
Image vulnerability scan (Trivy, Grype)।
No secrets in image।
Read-only filesystem in K8s।

ML-specific concerns:

(১) Model file as attack surface:

Pickle deserialization → arbitrary code execution। Untrusted .pkl load করবেন না।
সমাধান: SafeTensors, ONNX — safer formats।
Model registry-তে provenance + signature।

(২) Training data privacy:

Training image-এ data leak — hard-coded path, accidentally COPY।
Data fetch runtime-এ — image-এ না।
PII handling: NID, mobile, address — encrypt at rest, no log of raw।

(৩) GPU resource control:

Multi-tenant cluster-এ — GPU resource limit।
Memory limit miss → noisy neighbor crash।
K8s GPU operator + resource limit।

(৪) Adversarial input:

Prediction API public হলে — adversarial inputs (perturbed images, prompt injection)।
Input validation, rate limit, monitoring।
"Tricky inputs"-এর telemetry — pattern detect।

(৫) Model extraction attack:

Public API queried-এ model recreate করা possible (model stealing)।
Mitigation: rate limit, query logging, prediction differential privacy।

(৬) Supply chain — pre-trained model:

Hugging Face থেকে download — untrusted source।
Pickle-based model এ embedded malicious code possible।
SafeTensors prefer, signature check।

(৭) PyPI typosquatting:

"tensorflo" বা "scikit-learner" — fake package।
Lock file + hash verify।

Bangladesh-context-এ practical note:

Bangladesh Bank ২০২৩ guideline — financial AI-এর encryption + audit log mandate।
Personal Data Protection Act (২০২৩ draft) — data lineage track।
Global model use (OpenAI, Anthropic API) — data export concern।

মূল উপলব্ধি: ML container security DevOps-এর foundation + extra layers। Pickle attack, model provenance, adversarial input — ML-specific। Bangladesh-এ regulation evolving — early adoption ভাল। "Ship and worry later" — ML security-এ বিপজ্জনক।

অনুশীলন

লিখুন: একটি minimal Python ML script-এর জন্য Dockerfile লিখুন। Multi-stage না, কিন্তু non-root + pinned base + .dockerignore include করুন।
```
FROM python:3.11.7-slim
RUN useradd --create-home mluser
WORKDIR /app
COPY requirements.lock .
RUN pip install --no-cache-dir -r requirements.lock
COPY --chown=mluser:mluser . .
USER mluser
CMD ["python", "main.py"]
```
.dockerignore: .git, .venv, __pycache__, notebooks/, data/, tests/
Convert: উপরের Dockerfile-কে multi-stage-এ রূপান্তর করুন।

উপরের section ৩-এর pattern follow করুন। Builder stage = wheels build, runtime = wheels install।
চিন্তা: আপনার GPU model image ৬ GB। ৩ ধাপে কীভাবে ৪ GB-এ নামাবেন?
- (১) runtime base নিন devel-এর বদলে — ১.৫ GB save।
- (২) Multi-stage — pip wheel build stage 1-এ, install stage 2-এ — কিছু MB।
- (৩) --no-cache-dir + rm -rf /var/lib/apt/lists/* + .dockerignore — ৩০০-৫০০ MB।