DockerBeginner20 min

Docker Fundamentals

Master containers from the ground up: images, layers, volumes, networking, and multi-stage builds.

Dockerfilemulti-stage buildsvolumesnetworkingimages vs containers

THE STORY

The 2AM call that changed how I think about deployments

It's 2:17AM on a Tuesday. Your phone rings — it's the on-call alert. The payment service is down in production. You open your laptop, SSH into the server. Your first thought: this worked fine in staging an hour ago.

You start digging. Python version on the server: 3.8.2. Python version in staging: 3.10.4. A cryptography library your code uses behaves differently between the two. Someone installed Python 3.8 on the production server manually, six months ago, for a completely different service. Nobody documented it.

You spend the next four hours not fixing a bug. You're fixing an environment. The code was never the problem.

This scenario isn't rare. It's how most teams lose their weekends. And it's exactly the problem Docker was invented to eliminate.

THE CONCEPT

What Docker actually does — and the difference that matters most

Docker packages your application into a container — a runnable unit that includes your app code, its runtime, its dependencies, and a minimal OS layer. The container runs the same way everywhere because it carries its environment with it.

IMAGE vs CONTAINER — the distinction most engineers get wrong:

An IMAGE is a read-only template. Think of it as a blueprint. It's built once and never changes. Stored in a registry like Docker Hub or ECR. An image is never 'running' — it's a frozen snapshot.

A CONTAINER is a running instance of an image. It has its own process, its own writable filesystem layer on top of the image, its own network interface. You can run 50 containers from one image simultaneously.

The critical production fact: when a container stops, its writable layer is discarded. Any data written inside the container is gone. This is intentional. Containers are stateless by design. State belongs in volumes or external storage — never in the container itself.

THE PRODUCTION MISTAKE 80% OF ENGINEERS MAKE:

They build images that are 1.5GB, 2GB, sometimes more. During a production incident when you need to scale fast, pulling a 2GB image takes 8-10 minutes. Your users are waiting. Your incident gets worse.

The fix is multi-stage builds:

Dockerfile

# WRONG - ships 1.4GB build tools into production
FROM node:18
COPY . .
RUN npm install && npm run build
CMD ["node", "dist/server.js"]

# RIGHT - only compiled output ships
FROM node:18 AS builder
COPY package*.json .
RUN npm ci
COPY . .
RUN npm run build

FROM node:18-alpine AS runtime
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
CMD ["node", "dist/server.js"]
# Result: 180MB instead of 1.4GB

PRESSURE TEST

The interview questions that separate 6/10 answers from 9/10 answers

QUESTION 1

What is the difference between a Docker image and a Docker container?

⚠ WEAK (6/10)

'An image is like a template and a container is a running instance of that image.'

✓ STRONG (9/10)

'An image is an immutable, layered filesystem snapshot — built once and never changed. A container is a running process that uses that image as its root filesystem, with a thin writable layer added on top. You can run 50 containers from one image simultaneously, each with their own isolated writable layer. When the container stops, that writable layer is discarded — which is why containers are stateless by design. Persistent data belongs in volumes or external storage, not in the container itself.'

⚡ SENIOR INSIGHT

The 9/10 answer signals production experience because it explains WHY the writable layer is ephemeral and what that means for data. Most candidates say containers are stateless without understanding the mechanism.

QUESTION 2

Why is your Docker image 1.8GB? How would you reduce it?

⚠ WEAK (6/10)

'I would use a smaller base image like Alpine Linux.'

✓ STRONG (9/10)

'A 1.8GB image usually means build tools are being shipped into production. I would use a multi-stage build — compile in a full image, copy only the output into a minimal runtime image like Alpine or distroless. I would also add a .dockerignore to exclude node_modules, tests, and docs. In my last role this brought a 1.4GB Node image down to 180MB, which made a real difference during incident scale-up.'

⚡ SENIOR INSIGHT

The line that changes the interview — mentioning the production consequence (slow image pull during incidents means users wait longer) shows systems thinking. Interviewers at Razorpay, PhonePe, and Swiggy specifically look for this.

Follow-Up Probes

·What is the difference between CMD and ENTRYPOINT?
·What happens to data written inside a container when it restarts?
·How do you pass environment variables securely to a container?
·What is a Docker volume and when would you use one over a bind mount?
·Why would you use docker-compose in development but not in production?