CPU, Memory, PIDs, Devices, ulimits, cgroups v2, Reservations, and Container Resource Governance: Guided Hands-On Workflow and Core Operations

1. Preflight: record the execution boundary before creating load

The same command has different consequences on native Linux and Docker Desktop. On Desktop, the Linux daemon, cgroups, and Linux devices live inside the Docker VM. Begin with read-only evidence and stop if the active context points to a shared or production host.

docker context show
docker version
docker info --format 'os={{.OSType}} cgroup={{.CgroupVersion}} driver={{.CgroupDriver}} cpus={{.NCPU}} memory={{.MemTotal}}'
docker compose version || true
docker buildx version || true

docker pull alpine:3.22
docker image inspect alpine:3.22 --format 'image={{.Id}} repoDigests={{json .RepoDigests}}'

2. CPU lab: ceiling first, then evidence

Create one named CPU worker with a half-CPU quota. The shell loop is intentionally simple and disposable; --cpus 0.50 changes the container CPU quota rather than pinning it to a particular core. The label makes cleanup auditable.

docker rm -f dkr22-cpu 2>/dev/null || true
docker run -d --name dkr22-cpu --label academy=docker-ch22   --cpus 0.50 alpine:3.22 sh -c 'while :; do :; done'

docker inspect dkr22-cpu --format 'NanoCpus={{.HostConfig.NanoCpus}} CpuQuota={{.HostConfig.CpuQuota}} CpuPeriod={{.HostConfig.CpuPeriod}}'
docker stats --no-stream dkr22-cpu

docker exec dkr22-cpu sh -c '
  if [ -f /sys/fs/cgroup/cpu.max ]; then
    printf "cpu.max="; cat /sys/fs/cgroup/cpu.max
    printf "cpu.weight="; cat /sys/fs/cgroup/cpu.weight
  fi
'

3. Memory lab: trigger a bounded failure and preserve the cause

The goal is not to “crash Docker”; it is to prove how a process behaves when its memory cgroup has a 64 MiB ceiling and no extra swap allowance. A small Python image makes allocation behavior explicit. Depending on allocator and kernel behavior, the process may be killed by the memory cgroup or may terminate after allocation failure; preserve both OOMKilled and the exit code.

docker rm -f dkr22-mem 2>/dev/null || true
docker pull python:3.13-alpine

docker run --name dkr22-mem --label academy=docker-ch22   --memory 64m --memory-swap 64m   python:3.13-alpine   python -c 'blocks=[]
while True: blocks.append(bytearray(8*1024*1024))'

# The command above is expected to fail; inspect before removing it.
docker inspect dkr22-mem \
  --format 'status={{.State.Status}} exit={{.State.ExitCode}} OOMKilled={{.State.OOMKilled}} memory={{.HostConfig.Memory}} memorySwap={{.HostConfig.MemorySwap}}'
docker logs dkr22-mem 2>&1 | tail -40

docker start dkr22-mem >/dev/null 2>&1 || true
sleep 1
docker exec dkr22-mem sh -c 'test -f /sys/fs/cgroup/memory.events && cat /sys/fs/cgroup/memory.events || true' 2>/dev/null || true

4. PIDs lab: bounded process creation, never a fork bomb

--pids-limit protects the host from a container that creates too many processes or threads. The following loop attempts only a small fixed number of child processes and uses short sleeps, so it demonstrates denial without uncontrolled growth.

docker rm -f dkr22-pids 2>/dev/null || true
docker run --name dkr22-pids --label academy=docker-ch22   --pids-limit 16 alpine:3.22 sh -c '
    i=1
    while [ "$i" -le 24 ]; do
      sleep 8 &
      echo "attempt=$i status=$?"
      i=$((i+1))
    done
    wait
  ' || true

docker inspect dkr22-pids --format 'exit={{.State.ExitCode}} pidsLimit={{.HostConfig.PidsLimit}}'
docker logs dkr22-pids 2>&1 | tail -40

5. ulimit lab: prove the process-level ceiling

Rlimits are distinct from cgroups. This example sets both soft and hard RLIMIT_NOFILE to 64 and reads it from the process. Engine 29's runtime/packaging changes make this especially important: do not assume the old high Docker default.

docker run --rm --name dkr22-ulimit --label academy=docker-ch22   --ulimit nofile=64:64 alpine:3.22 sh -c '
    printf "nofile="; ulimit -n
  '

6. Optional device lab: narrow mapping only

Device nodes belong to the daemon host. Only on an authorized local Linux daemon, and only if the source device is known harmless and present, you can demonstrate a narrow mapping such as read access to /dev/null. This is optional because remote daemons and Docker Desktop VM boundaries change what “host device” means.

# OPTIONAL: authorized local Linux daemon only.
docker run \
  --rm \
  --name dkr22-device \
  --label academy=docker-ch22 \
  --device /dev/null:/dev/labnull:r   alpine:3.22 sh -c 'ls -l /dev/labnull; test -c /dev/labnull'

7. Compare declared policy with observed state

8. Challenge: choose the right layer

A service is slow. docker stats shows low CPU but memory usage is at the configured limit; the container restarts with exit code 137 and OOMKilled=true. Which layer should you investigate first?

Answer strategy: preserve the failed container evidence, inspect the memory limit and memory.events, then profile application memory. Increasing CPU quota or changing DNS cannot explain the observed OOM evidence.

9. Exact cleanup

Remove only named lab containers. Do not run broad prune commands; keep pulled images if later lessons need them, or remove exact tags only after verifying no other lab depends on them.

docker rm -f dkr22-cpu dkr22-mem dkr22-pids dkr22-ulimit dkr22-device 2>/dev/null || true
docker ps -a --filter label=academy=docker-ch22

Knowledge check

Official references and version notes

• Docker Docs — Resource constraints — CPU and memory hard/soft controls, swap semantics, and OOM guidance.
• Docker Docs — Runtime metrics — docker stats, cgroup discovery, and cgroups v2 behavior.
• Docker CLI — docker container run — CPU, memory, PID, ulimit, device, and cgroup options.
• Docker CLI — docker container stats — CPU, memory, PIDs, I/O, and one-shot JSON/template output.
• Compose Deploy Specification — resources — limits, reservations, PIDs, and device reservations.
• Docker Desktop — Resources — CPU/memory/swap capacity of the Docker Desktop Linux VM.
• Docker Engine 29 release notes — current Engine baseline and recent runtime/ulimit changes.
• Linux kernel — Control Group v2 — controller semantics for cpu.*, memory.*, and pids.*.