Welcome to Docker & Containers for Production Sysadmins · Docker & Containers

This lesson sets expectations and introduces the design system. Skim it once; then start the curriculum.

What this course is

A practical, production-oriented Docker course for Linux sysadmins. By the end, a sysadmin completing the course should be capable of independently managing business-critical Docker infrastructure while maintaining security, stability, performance, observability, recoverability, and operational resilience.

It is written for somebody who is already on call for Linux hosts. That shapes every chapter: the question is never “how do I run this container”, it is “what did installing Docker change about a machine I am responsible for, and what will wake me up”.

What it assumes you already know

Not Docker. Linux.

systemd — units, systemctl status, journalctl -u, and the difference between restart and reload.
Processes and signals — PID 1, SIGTERM versus SIGKILL, what an exit code of 137 means.
Filesystems — mounts, bind mounts, df and du disagreeing, and why a full filesystem breaks unrelated things.
Networking — interfaces, routes, ss -ltnp, and at least a reading knowledge of iptables or nftables.
Users and permissions — UIDs versus usernames, supplementary groups, and why group membership is an access-control decision.

Where a Docker concept rests on a kernel primitive, the course names the primitive rather than gesturing at it: the cgroup file, the namespace, the veth pair, the OCI config.json. If a term in that list is unfamiliar, the Linux course on this site covers it, and Part II of this one (Linux Internals) revisits the container-specific parts.

Four things Docker changes about a host

These are the ones that surprise experienced administrators, because each of them quietly overrides a habit that has been correct for years.

1. Published ports do not go through ufw

You harden a host with ufw, default deny incoming, allow 22 and 443. You verify with ufw status. Then you publish a container port with -p 8080:80, and it is reachable from the internet.

Docker’s own documentation states why: “When you publish a container’s ports using Docker, traffic to and from that container gets diverted before it goes through the ufw firewall settings” — because “Docker routes container traffic in the nat table, which means that packets are diverted before it reaches the INPUT and OUTPUT chains that ufw uses.”

Nothing is misconfigured. ufw is working exactly as documented, and so is Docker, and the packet never meets the rule you wrote.

The first diagnosis is almost always a mistake in the ufw rule, which is why people spend an hour rewriting a rule that was right all along. Test from another machine rather than trusting ufw status:

ss -ltnp | grep 8080

The safe fix is to publish to an address rather than to everything. A published port takes an optional host IP, and the documentation is explicit: “If you include the localhost IP address (127.0.0.1, or ::1) with the publish flag, only the Docker host can access the published container port.”

Configuration changepublish narrowly— Binds the published port to the loopback address only. A reverse proxy on the host can reach it; the network cannot.

docker run -d --name web -p 127.0.0.1:8080:80 nginx:1.27

Never reach for the daemon’s iptables: false option to “make ufw work”. Docker warns that it “is likely to break container networking”, and it removes the rules that make your containers reachable at all — including from each other. The firewall lesson later in the course covers the supported way to add administrator rules that Docker’s own rules do not override.

3. Restarting the daemon stops every container

systemctl restart docker is the reflex — to pick up a config change, or as the first move in an incident. On a default installation it is a full outage of every container on the host.

“By default, when the Docker daemon terminates, it shuts down running containers.” Live restore is disabled by default.

Check before you type it, and prefer a reload where one will do:

Read-only / Safeis a restart safe— false means restarting the daemon is an outage of every container on this host.

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

The unit is docker.service, not dockerd. Many daemon.json options — including live-restore itself — apply with systemctl reload docker, which disturbs nothing.

4. /var/lib/docker grows until the host stops

Images, container writable layers, volumes, build cache and logs all live under /var/lib/docker, and none of them is bounded by default. When that filesystem fills, the failure is not “Docker is full”: containers that stop cannot start, image pulls fail so you cannot deploy the fix, and the daemon itself begins erroring on writes.

If /var/lib/docker is not on its own filesystem, a runaway container log takes the root filesystem with it, and then the problem is the whole machine.

Read-only / Safespace triage— Where the space went, broken down by reclaimable and in-use. Run this before anything destructive.

df -h /var/lib/docker
docker system df
docker system df --verbose | head -40

What Docker is not

Being honest about the boundary saves arguments later. Docker Engine is a single-host container runtime with a good developer experience. On one host it gives you images, isolation, resource limits, networking and volumes.

It does not give you a scheduler, cross-host networking, rolling deploys with automatic rollback, or a secrets store outside of Swarm. Compose is a way to describe a set of containers on one host, not a cluster manager. If you need workloads to move between hosts automatically, that is Swarm, Nomad or Kubernetes, and choosing one is a separate decision this course will not pretend Docker already solved.

Most estates that run Docker in production run it on a handful of carefully managed hosts, and that is a legitimate architecture rather than a stepping stone.

Triaging a host you have inherited

The first ten minutes on an unfamiliar Docker host, in order. Everything here is read-only.

Read-only / Safefirst ten minutes— Versions, daemon configuration, disk, what is running, and what has been failing. Nothing is modified.

docker version
docker info --format 'live-restore={{.LiveRestoreEnabled}} logdriver={{.LoggingDriver}} cgroup={{.CgroupVersion}} storage={{.Driver}}'
cat /etc/docker/daemon.json 2>/dev/null || echo 'no daemon.json - all defaults'
df -h /var/lib/docker
docker system df
docker ps -a --format 'table {{.Names}}\t{{.Status}}\t{{.Image}}'
journalctl -u docker.service --since '24 hours ago' --no-pager | tail -40

Read-only / Safedocker info— Four fields that determine how the rest of the day goes.

$ docker info --format 'live-restore={{.LiveRestoreEnabled}} logdriver={{.LoggingDriver}} cgroup={{.CgroupVersion}} storage={{.Driver}}'

live-restore=false logdriver=json-file cgroup=2 storage=overlay2

Illustrative output

live-restore=false means you cannot restart the daemon in hours. logdriver=json-file with no options in daemon.json means logs are unbounded. Those two facts, gathered in ten seconds, change what you are allowed to do for the rest of the shift.

Verified against

Read-only / SafeInspect— Read-only state check; safe everywhere.

$ docker version

Client: Docker Engine - Community
Version:           28.1.1
API version:       1.49
Go version:        go1.23.6
Git commit:        4af6f4d
Built:             Wed Jul  9 19:46:14 2025
OS/Arch:           linux/amd64
Context:           default

Server: Docker Engine - Community
Engine:
Version:          28.1.1
API version:      1.49 (minimum version 1.24)
Go version:       go1.23.6
Git commit:       4af6f4d
Built:            Wed Jul  9 19:46:14 2025
OS/Arch:          linux/amd64
Experimental:     false

Illustrative output

Severity model

Every command example is tagged with a severity badge. This is not decoration — it is a production discipline tool. Read the badge before the command.

Configuration changedaemon.json— Daemon-wide config change; reload required.

cat > /etc/docker/daemon.json <<'EOF'
{
"log-driver": "json-file",
"log-opts": {
  "max-size": "10m",
  "max-file": "3"
}
}
EOF

Service impact possiblerestart daemon— Stops every container on the host unless live restore is enabled. Check first.

systemctl restart docker

Destructiveremove container— Removes a container. Verify ID first.

docker rm -f web01

Data-loss riskdrop volume— Removes the named volume and all data inside. There is no undo and no prompt.

docker volume rm pgdata

Why the badges are load-bearing rather than decorative

The severity of a Docker command is frequently not visible in its text, which is the whole reason for the badge.

docker rm -f web01 reads like rm on a file and behaves like it, except that anything written inside the container’s writable layer — logs, uploads, a database somebody forgot to put on a volume — is gone with it.

docker volume rm pgdata is a one-word difference from docker volume ls and deletes a database.

systemctl restart docker mentions no container at all and stops all of them.

docker system prune -a is presented in a great deal of online advice as routine housekeeping; with -a it removes every image not used by a running container, which on a host that is mid-deploy includes the image you are about to roll back to.

Where a command is destructive, this course says so in the badge and tells you what to check first. Where it is safe, the badge says READ-ONLY and you can run it during an incident without thinking about it. That distinction is the point.

Lab

Mode B · Nested virtualisationMode C · Simulation / guided exercise

Mode B requires a Linux VM with nested virtualisation enabled and a Docker daemon installed. Mode C is a guided walkthrough you can complete without a real Docker host.

Lesson anatomy

Major lessons follow this structure:

What you will learn
Why this matters in production
Mental model
Architecture / visual explanation
How to configure it
How to validate it
How it fails
How to troubleshoot it
Security and performance implications
Production guidance and rollback

Two of those carry most of the weight. How it fails is where the failure modes live, usually in a “What could go wrong?” callout with the symptom, the reason the obvious diagnosis is wrong, and the fix. How to validate it always gives a command whose output distinguishes working from broken — “run it and see” is not validation anywhere in this course.

What if you already run Docker in production and want to skip ahead?

Read Part I (Foundations) and Part II (Linux Internals) anyway, and then jump.

The foundations chapters are short and they are where the course establishes the things later parts assume you will not re-derive: that the CLI is an HTTP client, that the daemon restart is an outage, that a container’s root is the host’s root, and that docker group membership is a root grant. Later lessons reference those facts rather than re-explaining them, so skipping the foundations does not save time — it moves the confusion later, into a chapter about something else.

If you genuinely only need one subject, each part stands alone enough to be read on its own, and the prerequisites field in every lesson’s frontmatter names what it expects you to have read.

Knowledge check

Where next?

The first deep-dive is on Linux container primitives — namespaces, cgroups, OverlayFS, capabilities — because every later decision in Docker depends on them. See Part II (Linux Internals) of the curriculum.