Lesson 01 — Code to Container

From python app.py to docker run app — what actually happens under the hood.

Cloud & DevOps Module 1

The “works on my machine” problem

It's just Linux.

• A container is a process — not a VM, not a mini operating system
• Uses namespaces for isolation: pid, mount, net, uts, user, ipc
• Uses cgroups for resource limits: CPU, memory, IO
• No magic. No hypervisor. The process runs directly on the host kernel.

Namespaces in one slide

cgroups in one slide

• cgroups (control groups) cap resource consumption for a process tree
• --cpus 0.5 → 50% of one core; maps to /sys/fs/cgroup/cpu/
• --memory 256m → OOM-kill the container if it exceeds 256 MB
• --blkio-weight → relative IO bandwidth per container
• --pids-limit → cap process count (fork-bomb defence)

Container vs VM

What Docker adds — Tooling, not magic.

• Image format — OCI layered tarballs + a JSON manifest. Portable across runtimes.
• Registry protocol — push/pull to Docker Hub, GHCR, ECR, GCR, …
• Build language — the Dockerfile: a deterministic recipe for assembling a layered image
• Runtime CLI — docker run, docker exec, docker logs, docker ps

Linux namespaces + cgroups have existed for over a decade. Docker made them ergonomic.

Images vs containers

The minimal Dockerfile

FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY app.py .
CMD ["uvicorn", "app:app", "--host", "0.0.0.0", "--port", "8000"]

• FROM — base image (every container starts from one)
• WORKDIR — sets default directory; auto-creates if missing
• COPY requirements.txt first — keeps the pip-install layer cached on code edits
• RUN — runs at build time; result becomes a layer
• CMD — exec form; uvicorn is PID 1, gets SIGTERM cleanly

docker build step by step

docker build -t url-shortener:0.1 .

• Reads Dockerfile top to bottom
• Runs each instruction in a throwaway intermediate container
• Commits the result as a layer — content-addressed in the local layer store
• Caches each layer keyed by: instruction text + all parent layers
• Final image = stack of all layers + JSON metadata
• First build: ~60 s. Subsequent builds (no changes): < 1 s.

docker run step by step

docker run --rm -p 8000:8000 url-shortener:0.1

• Creates namespaces (pid, mount, net, uts, user, ipc)
• Sets up cgroups (if --memory / --cpus specified)
• Mounts the image's read-only layers + a writable top layer via overlay-fs
• Starts the CMD process as PID 1 inside the new pid namespace
• -p 8000:8000 — forwards host port into the container's net namespace via iptables NAT

What the running container looks like

docker ps                            # container listed with ID, name, ports
docker logs <id>                     # uvicorn's startup line
curl localhost:8000/health           # -> {"status":"ok"}
docker exec -it <id> /bin/sh        # drop into the container

# Inside the container:
ps -ef                               # only your app + maybe a shell
ls /app                              # app.py + requirements.txt

What lands in sample-app/ after this lesson

Recap & what’s next

• Containers = namespaces + cgroups — no hypervisor, just Linux primitives
• Image = read-only layered snapshot; container = running instance with a writable top layer
• The same Dockerfile builds the same image anywhere — that’s the portability guarantee