Skip to content
imabhinav.dev

Introduction to Containers

Containers basically lightweight, portable, aur isolated runtime environments hote hain jisme aap apni application aur uske dependencies ko bundle karke run karte ho. Socho ek mini sandbox jo OS kernel share karta hai par process-level isolation deta hai.

Technical building blocks (simple terms)

  • Namespaces — process, mount, network, PID, UTS, user namespaces: ye alag-alag resources ko isolate karte hain.

    • Example: PID namespace se container ka pid 1 alag hota hai host ke processes se.

  • cgroups (control groups) — resource limits apply karte hain (CPU, memory, I/O).

    • Example: container ko 500MB memory ya 0.5 CPU core de sakte ho.

  • Union/Overlay Filesystems (AUFS, overlayfs) — image layers ko stack karte hain; read-only base layers + writable top layer.

  • Container Image — read-only layered filesystem + metadata (entrypoint, env vars). Image se container spawn hota hai.

  • Container Runtime — low-level tool jo namespaces + cgroups ko use karke process ko run karta hai (e.g., runc, containerd).

Real-world analogy

Container = ek apartment room in a big building (host OS kernel = building infrastructure). Har room mein apna furniture (app dependencies) hota hai, lekin building ke plumbing/electricity share hote hain.

Key properties

  • Lightweight — pura OS boot nahi hota, bas process chalti hai.
  • Portable — same image dev machine, CI, prod sab pe same behave karega.
  • Immutable images — image read-only; runtime changes container layer mein hote hain.
  • Fast startup — seconds/milliseconds me start.

Kyun Containers chahiye? (Why we need them — deep reasons)

  1. Consistency across environments “Works on my machine” problem solve hota hai. Image jo dev mein build hoti, wahi prod mein chalti.

  2. Isolation without VM overhead Process-level isolation provide karta, par full VM jaise heavy resources consume nahi karta.

  3. Efficient resource utilization Multiple containers same host pe chal sakte hain bina full OS copies ke.

  4. Microservices architecture ko enable karna Har microservice ko apna container deke independent deploy/scale kar sakte ho.

  5. CI/CD friendly Build → Test → Push image → Deploy — reproducible pipeline.

  6. Portability & Dev Onboarding New dev: docker run / docker-compose up se environment ready.

  7. Security boundary (partial) Containers isolation dete hain, lekin VM-level strong isolation nahi; phir bhi attack surface controlled rehta.

  8. Scaling & orchestration Kubernetes, Docker Swarm jaise tools se containers ko scale/ heal/ manage karna aasaan hota hai.

Bare Metal vs Virtual Machines (VMs) vs Containers — Comparison (in-depth)

Feature / AspectBare MetalVM (Virtual Machine)Container
What runsApp on host OS directlyGuest OS + App (hypervisor manages)App as process(s) isolated by kernel
Isolation strengthNone (only OS-level users)Very strong (separate kernel)Moderate (namespaces + cgroups)
OverheadLowestHigh (full OS per VM)Low (shared kernel)
Boot timeInstant (process)Minutes (OS boot)Seconds / milliseconds
Resource efficiencyHighLower (OS copies)High
Use-casesHigh-performance workloads, hardware accessMulti-OS testing, strict isolationMicroservices, CI/CD, scalable apps
Security boundaryWeak (single OS)Strong (hypervisor)Medium (depends on kernel & runtime)
PortabilityLow (OS-specific)Moderate (image + hypervisor)High (image portable across hosts with same kernel ABI)
Management complexitySimplerRequires hypervisor managementRequires container runtime & orchestration

When to pick which?

  • Bare Metal: Jab hardware access zaroori ho (GPU passthrough with low latency, specialized I/O), ya highest perf chahiye.
  • VMs: Jab full OS isolation chahiye (different kernels), ya regulatory/security requirement demand karta ho.
  • Containers: Jab speed, density, portability, and microservices chahiye. Most cloud-native apps containers pe best fit hote hain.

Example scenarios

  • Database demanding direct disk/IO tuning + extreme isolation → VM ya even Bare Metal.
  • Stateless web service, API, worker → Container.
  • Multi-tenant service with high security requirements → VMs or combination (VMs hosting container clusters).

Docker aur OCI — Deep Explanation (Hinglish)

Docker ka high-level overview

  • Docker originally ek complete ecosystem tha: CLI (docker), Engine (daemon), image format, registry (Docker Hub).
  • Developer-friendly tools + UX — easy docker build, docker run, docker compose.

Docker components (simplified)

  • Docker CLI (docker) — user-facing commands.
  • Docker Engine — daemon that talks to container runtime.
  • containerd — higher-level runtime for managing images, containers, storage, network.
  • runc — low-level OCI-compatible runtime that actually creates namespaces + cgroups and spawns the process.
  • Docker Hub / Registry — store for images.

OCI — Open Container Initiative (kya hai?)

  • OCI ek standards body (Linux Foundation ke under) jo container specs standardize karta hai:

    • OCI Runtime Spec — container runtime behaviour (how to configure namespaces, cgroups, stdio, etc.). runc is an implementation.
    • OCI Image Spec — standard image manifest + layer format so different tools can share images.

Why OCI important?

  • Interoperability: different runtimes/tools (Docker, containerd, cri-o, Podman) same images and runtime behaviour use kar sakte hain.
  • Vendor-agnostic ecosystem: lock-in kam hota hai.

Docker vs OCI — Difference summary

  • Docker = ecosystem + tooling + UX (CLI, compose, hub, engine).
  • OCI = specs/standards that define how images & runtimes should work.
  • Aaj kal Docker implementation OCI-compliant hai — Docker uses containerd + runc which follow OCI specs.

Key layers in modern stack (flow)

  1. You write a Dockerfile → docker build produces an OCI-compatible image (layers, manifest).
  2. Image pushed to registry (Docker Hub / GHCR / ECR).
  3. On host/k8s node, containerd pulls image, prepares rootfs (overlayfs), and calls runc (OCI runtime) to start container (namespaces + cgroups).
  4. Orchestration (Kubernetes) interacts with container runtime via CRI (Container Runtime Interface) which many runtimes implement.

Runtimes & Alternatives

  • runc — original OCI runtime (from OpenContainers).
  • containerd — daemon that manages images & containers; uses runc.
  • CRI-O — lightweight runtime for Kubernetes, implements CRI and uses runc.
  • Podman — daemonless alternative to Docker CLI, OCI-compliant, rootless mode friendly.

Security & OCI

  • OCI standardize karta hai how to configure user namespaces, seccomp, capabilities — jo security policies enforce karne me help karta hai.
  • Runtime-level hardening (e.g., seccomp profiles, read-only rootfs, dropping capabilities) zaroori hai for production.

Deep-dive examples & practical tips (commands, config)

Image build + run (example)

Terminal window
# build
docker build -t my-app:1.0 .


# run
docker run --rm -d \
  --name my-app \
  -p 8080:8080 \
  --memory=512m \
  my-app:1.0

Limit resources with cgroups (docker flags)

Terminal window
docker run --memory="256m" --cpus="0.5" my-app

Inspect container namespaces / details

Terminal window
docker inspect my-app
# or use nsenter on host for deeper debugging (advanced)

Example: multi-stage build (optimize image size)

# builder
FROM node:18 AS builder
WORKDIR /app
COPY package*.json .
RUN npm ci
COPY . .
RUN npm run build


# runtime
FROM node:18-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY package*.json .
RUN npm ci --production
CMD ["node", "dist/index.js"]

Best security flags

  • --read-only — make rootfs read-only
  • --user — run as non-root user
  • Drop capabilities: --cap-drop=ALL --cap-add=NET_BIND_SERVICE
  • Use seccomp/profile, AppArmor, SELinux where available

Common misunderstandings (clear kar dete hain)

  1. “Containers are VMs” — Nah. Containers share kernel; VMs have separate kernels.
  2. ”Containers are insecure by default” — Partial truth. Isolation exists but kernel exploits, misconfigurations can break isolation. Harden with namespaces, seccomp, user namespaces.
  3. ”Container = Docker only” — Nahi. Docker ek popular tool hai; OCI defines standard. Podman, containerd, cri-o bhi valid.

Interview-ready quick questions (aur concise answers)

  1. Process of container start? Image pulled → layers unpacked → rootfs prepared (overlay) → runtime (runc) creates namespaces & cgroups → process starts.

  2. What is overlayfs? Filesystem driver jo multiple read-only layers + writable layer stack karta hai for images.

  3. Difference: CMD vs ENTRYPOINT?

    • ENTRYPOINT sets the executable (fixed)
    • CMD provides default args (overridable). Together, ENTRYPOINT + CMD common pattern.

  4. What is multi-stage build? Multiple FROM stages; final image copies only artifacts needed → smaller images.

  5. Why use user namespaces? Host root vs container root mapping to reduce risk if container process escapes.

Final Summary — Short & Powerful

  • Containers = lightweight, process-level isolation using namespaces + cgroups.
  • Need = consistency, portability, fast startup, resource efficiency, microservices enablement.
  • Bare Metal vs VM vs Container = trade-offs in isolation, performance, resource use. Choose based on use-case.
  • Docker = friendly tooling/ecosystem. OCI = the open standard that ensures interoperability (runc, containerd, image spec).