Containers
- Pradeep P
- 3 days ago
- 3 min read
Layer 5 · Post 1 of 12
← Previous: Change Data Capture → Next: Kubernetes
Layer 5 — Modern infrastructure · Post 51 of 88
A container packages an app with its runtime so it runs the same way on a laptop, a CI runner, and a production node.
What you'll learn
What a container image actually contains, and how it differs from a VM
Why shipping an image kills most "works on my machine" bugs
What isolation you get — and what you still do not get
The idea in one minute
A container is a process with a packed-in filesystem. You build an image: your app, its language runtime, shared libraries, and a start command. You run that image on any host with a container runtime. The host kernel stays shared; the app thinks it has its own machine.
[ App + libc + Node 20 ] <-- image layers | v [ Linux kernel on the host ]
A VM ships a whole guest OS. A container ships a process plus files. That is why containers start in seconds and pack tighter.
Why it matters
Interviews (and production) assume you can ship the same artifact from laptop to CI to prod.
Without containers you fight drift: Python 3.11 here, 3.9 there, a missing .so on Friday night. With containers:
The unit of deploy is the image, not "ssh and git pull."
Density goes up. One node runs many isolated processes instead of many VMs.
Rollbacks are an old image tag, not a prayer that the box still has last week's packages.
How it works
A Dockerfile (or equivalent) lists a base image, copy steps, and CMD/ENTRYPOINT.
The build produces layers. Unchanged layers are cached. That is why "put rarely changing installs first" is a real speed trick.
You push the image to a registry (GHCR, ECR, GCR, Docker Hub).
A host pulls the image and starts a container: namespaces (PID, network, mount) plus cgroups (CPU, memory limits).
The kernel is shared. That is the efficiency. It is also why a kernel exploit is a bigger story than on fully separate VMs.
Image vs container
The image is the immutable recipe (usually tagged payments:1.4.2). The container is a running instance: writable layer on top, its own process tree, often its own IP inside a bridge network.
What containers do not give you
They do not schedule across machines, restart you after a node dies, or give you a stable DNS name. That is Kubernetes (next post). They also do not magically secure a root process with a fat base image.
A simple example
Your payments API needs OpenSSL, a specific glibc, and Node 20. On a laptop it works. On the CI runner, Node 18 is installed and tests pass for the wrong reasons. In prod, an ops image is missing a CA cert.
You pin FROM node:20-bookworm-slim, copy package-lock.json, npm ci, copy source, set CMD ["node", "server.js"]. CI builds the same image. Prod runs payments:git-sha. Three environments, one filesystem. When 1.4.2 is bad, you point traffic at payments:1.4.1.
Common mistakes
Treating the container as a tiny VM. SSHing in, apt-installing, and never rebuilding. The next deploy wipes it. Bake into the image.
Running as root with a 1.2 GB image. Attack surface and pull time both hurt. Slim bases, non-root users, and multi-stage builds are the default interview answer.
Latest tags in production. app:latest means you cannot say what is running. Pin digests or immutable version tags.
One container, twelve responsibilities. Cron, the app, Redis, and a sidecar logger in one image. Split processes. Compose locally if you must; do not ship a zoo.
How this shows up in real systems
Docker / containerd / CRI-O: runtimes. Kubernetes talks to them; you rarely pick for a design interview unless asked.
Registries + CI: build on merge, scan, push, deploy by tag.
ECS, Cloud Run, Nomad, k8s: different schedulers, same image contract.
Layer 5 starts here because everything after this — orchestration, meshes, autoscaling — assumes you can start a replica from an image in seconds.
Recap
A container is a process plus a filesystem image, sharing the host kernel.
You ship immutable, tagged images so laptop, CI, and prod match.
Isolation is namespaces and cgroups, not a full VM — plan security and scheduling on purpose.
Images get you a runnable unit. Next: the system that places those units on machines and keeps them running.
Layer 5 · Post 1 of 12
← Previous: Change Data Capture → Next: Kubernetes
Comments