Check: Docker

A container is just a regular process on the host's kernel. The kernel limits what that process can see (namespaces) and how many resources it can take (cgroups). A VM has a full guest OS with its own kernel, running on top of a hypervisor.

Compare the kernel version of the Docker host with what the process inside the container sees:

docker info --format '{{.KernelVersion}}'

5.15.49-linuxkit

docker run --rm --label izi.lab=docker-08-quiz alpine:3.20.3 uname -r

5.15.49-linuxkit

The versions match, the container has no kernel of its own. On macOS and Windows, Docker Desktop runs a small Linux VM, which is why the kernel here is linuxkit rather than your OS's own kernel. Containers live inside this VM and share its kernel.

Namespaces control what a process sees: its own processes, its own network stack, its own filesystem, its own hostname, its own IPC. There's no such thing as a "memory" namespace. How much memory and CPU a process can take is decided by cgroups.

List of namespaces for a process in a container:

docker run --rm --label izi.lab=docker-08-quiz alpine:3.20.3 ls /proc/self/ns

cgroup
ipc
mnt
net
pid
pid_for_children
time
time_for_children
user
uts

And the memory limit set by --memory 64m lives in the cgroup (this is cgroup v2):

docker run --rm --label izi.lab=docker-08-quiz --memory 64m alpine:3.20.3 cat /sys/fs/cgroup/memory.max

67108864

That's 64 × 1024 × 1024 bytes. On a host with the older cgroup v1, there's no memory.max file, the limit lives in /sys/fs/cgroup/memory/memory.limit_in_bytes.

Image layers are read-only and shared. Each container gets its own thin writable layer on top of them, where its changes go. This is copy-on-write: a file is copied into the writable layer only when the container changes it. That's how overlay2, Docker's default storage driver, works. The debugging driver vfs is an exception: it can't do copy-on-write and makes full copies, so it's not used in production systems.

Start three containers and look at the sizes:

for i in 1 2 3; do docker run -d --name quiz-web-$i --label izi.lab=docker-08-quiz --memory 64m --cpus 0.25 nginx:1.27.3-alpine; done

docker ps -s --filter label=izi.lab=docker-08-quiz --format 'table {{.Names}}\t{{.Size}}'

NAMES        SIZE
quiz-web-3   1.07kB (virtual 50.9MB)
quiz-web-2   1.09kB (virtual 50.9MB)
quiz-web-1   1.09kB (virtual 50.9MB)

The first number is the container's own writable layer, around a kilobyte. virtual is the size including the shared image layers, which are the same for all of them. Clean up:

docker rm -f quiz-web-1 quiz-web-2 quiz-web-3

The layer cache breaks at the first changed instruction, and every instruction below it runs again. Dependency manifests change rarely, so they're copied earlier. Code changes often, so it goes lower. That way RUN npm ci stays cached as long as package.json hasn't changed. With COPY . . at the start, any code change reinstalls all dependencies. ADD doesn't improve the cache. More detail in the Dockerfile lesson, section "The layer cache and why order matters".

The first stage (builder) builds the app: it has the compiler, dev dependencies and source code. The final stage starts from a clean base image and pulls only the build result through COPY --from=builder. The compiler and source code never reach the final image, so it ends up noticeably smaller, with less software in it that could have vulnerabilities. Building for several architectures is a different feature (docker buildx build --platform).

The writable layer lives as long as the container does. docker rm removes it along with all its changes. The image itself doesn't change, there was never any data in it. tmpfs is lost as soon as the container stops. A named volume lives separately from the container and survives rm. A bind mount would also keep the data, but then the path, permissions and ownership of the host directory become your problem. That's why Docker's documentation recommends volumes for database data.

Data in the writable layer disappears after rm:

docker run --name quiz-db --label izi.lab=docker-08-quiz alpine:3.20.3 sh -c 'echo order-42 > /tmp/data.txt'

docker rm quiz-db

docker run --rm --label izi.lab=docker-08-quiz alpine:3.20.3 cat /tmp/data.txt

cat: can't open '/tmp/data.txt': No such file or directory

Same experiment with a named volume. The containers are one-shot (--rm), but the file remains:

docker run --rm --label izi.lab=docker-08-quiz -v izi-quiz-data:/data alpine:3.20.3 sh -c 'echo order-42 > /data/data.txt'

docker run --rm --label izi.lab=docker-08-quiz -v izi-quiz-data:/data alpine:3.20.3 cat /data/data.txt

order-42

Remove the volume:

docker volume rm izi-quiz-data

In the default bridge network, containers can only see each other by IP. Docker's built-in DNS server (127.0.0.11) shows up in a user-defined bridge: a network created by docker network create, or the network compose creates for a project. The old --link flag also gave names in the default network, but it's deprecated, and the documentation recommends a network of your own instead.

Check which DNS server a container has in the default network:

docker run --rm --label izi.lab=docker-08-quiz alpine:3.20.3 grep nameserver /etc/resolv.conf

nameserver 192.168.65.7

That's the host's DNS (here, Docker Desktop), it knows nothing about container names. Now a network of our own and two containers in it:

docker network create --label izi.lab=docker-08-quiz quiz-net

docker run -d --name quiz-b --network quiz-net --label izi.lab=docker-08-quiz --memory 32m alpine:3.20.3 sleep 300

docker run --rm --network quiz-net --label izi.lab=docker-08-quiz alpine:3.20.3 ping -c1 -W2 quiz-b

PING quiz-b (192.168.112.3): 56 data bytes
64 bytes from 192.168.112.3: seq=0 ttl=64 time=0.916 ms
...

Inside this network, /etc/resolv.conf points to nameserver 127.0.0.11. Clean up:

docker rm -f quiz-b

docker network rm quiz-net

This is a classic trap. Every container has its own network stack, and localhost inside a container is the container itself. Inside compose, you reach the database by its service name: DB_HOST=db. Publishing a port via ports: isn't needed for this: ports: opens a port on the host, and services in the same project already see each other over a shared network. EXPOSE is image metadata, it has no effect on reachability. If the database had simply not started yet, the client would be knocking on db:5432, not on 127.0.0.1.

Let's check this with two containers in one network. db listens on port 5432 via nc:

docker network create --label izi.lab=docker-08-quiz quiz-net

docker run -d --name db --network quiz-net --label izi.lab=docker-08-quiz --memory 32m alpine:3.20.3 nc -lk -p 5432

docker run --rm --network quiz-net --label izi.lab=docker-08-quiz alpine:3.20.3 sh -c 'nc -z -w2 127.0.0.1 5432 && echo "127.0.0.1:5432 open" || echo "127.0.0.1:5432 refused"; nc -z -w2 db 5432 && echo "db:5432 open" || echo "db:5432 refused"'

127.0.0.1:5432 refused
db:5432 open

Clean up:

docker rm -f db

docker network rm quiz-net