Docker Architecture & Production Containers

Container Runtimes, Linux Namespaces, cgroups & Multi-Stage Builds

A complete Docker course as IDE-style videos, plus a written companion built from the same scripts. 7 modules, 32 lessons, five to ten minutes each.

Intermediate · 3 hours · 32 lessons · 140 labs

Related guides

Who it is for

Intermediate level.

For developers, operations staff and new DevOps engineers who want to package, run and ship services in containers, and understand what Docker is doing underneath.

What you don't need yet:

What helps:

Before you start:

Take first:

Take next:

Learning paths:

Nobody needs to know everything before they start. Each course builds on the one before, so a learning path takes you there step by step.

Labs

140 labs: you write the code, it runs, and graded labs check the result. The outline lists each lesson's labs.

What is free

Start free: First module free with an account. Pro: Every course, lab, handbook, practice exam and certificate.

Course outline

Containers From The Ground Up

  1. Why Containers: Bare Metal, Machines And Processes (2 labs): You can explain what a container actually is, how it differs from a virtual machine, and why packaging the environment with the program removes a whole class of deployment failure.
  2. Namespaces And Cgroups: Isolation And Limits (3 labs): You can name the kernel features that make a container, read a container's namespace identifiers and control group limits from a shell, and explain which of the two does isolation and which does resource control.
  3. Union Filesystems, Images And Writable Layers (3 labs): You can explain what an image is made of, read the layer history of an image you built, and predict what happens to a file a container writes when that container is removed.
  4. Docker, OCI, The Engine And The CLI (2 labs): You can describe what happens between typing a docker command and a container running, name the three OCI specifications, and explain why removing Docker from Kubernetes did not break your images.
  5. Install Docker And Verify Your Environment (3 labs): You can install the right Docker for your operating system, prove the daemon is reachable from your shell, and know which post-install steps decide whether you type sudo for the rest of your career.

Images And The Container Lifecycle

  1. Pull And Inspect A Third Party Image (2 labs): You can pull a trusted image, read its metadata, and explain which parts of an image are content and which parts are a mutable runtime choice.
  2. Run, Stop, Restart And Remove A Container (3 labs): You can start a named container, observe its state, stop it cleanly, restart it, and remove the container without confusing it with its image.
  3. Commands, Logs, Exec And Exit Codes (3 labs): You can inspect a running container without rebuilding it, read its logs, execute a diagnostic command, and use exit codes to find the real failure.
  4. Run The Spine Service And Publish Its Port (3 labs): You can run the course service from its image, publish its listening port, test it from the host, and cleanly stop the service when the test is done.

Build Images Instruction By Instruction

  1. Build Context, Dockerignore And Your First Dockerfile (5 labs): You can write a four line Dockerfile for the task API, say exactly which files a build can read, keep secrets and junk out of the build context with a .dockerignore file, and choose the Dockerfile and the context independently.
  2. FROM, WORKDIR, COPY And ADD (5 labs): You can choose and pin a base image, predict exactly where WORKDIR and COPY put each file and who owns it, know the one job ADD does that COPY does not, and recognise an ONBUILD trigger inherited from a base image.
  3. RUN, SHELL And Efficient Layer Caching (6 labs): You can use RUN in shell and exec form, change the build shell with SHELL so pipes fail properly, read which steps a rebuild took from the cache, and order a Dockerfile so everyday code edits rebuild only the last few layers.
  4. ARG, ENV, LABEL, EXPOSE And VOLUME (5 labs): You can decide whether a setting belongs to build time or run time, parameterise a build with ARG, bake runtime defaults in with ENV, describe an image with OCI labels, and explain what EXPOSE and VOLUME really do when a container starts.
  5. CMD, ENTRYPOINT, USER And Process Signals (7 labs): You can choose between exec and shell form, predict how CMD and ENTRYPOINT combine and get overridden, run a service as a non-root user that owns only what it must, and make sure it hears SIGTERM and shuts down cleanly.
  6. Multi Stage Builds, Targets And Build Secrets (6 labs): You can split a build into stages so the toolchain never ships, build a single stage on purpose with a target, pass a secret to one build step without it reaching the image, history or logs, and read the task API's finished Dockerfile line by line.

Registries, Image Size And Security

  1. Tags, Digests And Reproducible Image References (4 labs): You can read every part of an image reference, give one build several meaningful tags, and pin an image by digest so that every machine runs exactly the same bytes.
  2. Authenticate, Tag, Push And Pull From A Registry (5 labs): You can run a private registry, push the service to it, pull it back by tag and by digest, and log in without leaving a reusable password lying around.
  3. Minimal Bases, Non Root Users And Smaller Images (5 labs): You can choose a base image deliberately, find and remove the layers that make an image fat, ship a compiled program on a distroless base, and prove the service runs as an unprivileged user.
  4. Scan, Patch And Inspect The Software Supply Chain (5 labs): You can list what an image really contains, explain how a scanner turns that list into vulnerabilities, attach an SBOM and provenance to a build, and patch by rebuilding on a supported base.

Data, Networks And Runtime Configuration

  1. Ephemeral Filesystems And Named Volumes (4 labs): You can show that a container's writable layer is deleted with the container, keep the task API's data in a named volume that survives removal, and find, inspect and safely remove volumes.
  2. Bind Mounts, Permissions And Backups (6 labs): You can bind-mount a host directory read-write or read-only, explain and fix a numeric user ID mismatch between a container and its mount, and back up and restore a named volume with a throwaway container and tar.
  3. Bridge Networks, DNS And Container Communication (4 labs): You can explain why containers on the default bridge only reach each other by address, put the task API on a user-defined bridge network where other containers find it by name or alias, and show that a network is an isolation boundary.
  4. Port Publishing, Localhost And Network Troubleshooting (3 labs): You can publish a container port on all interfaces or on loopback only, recognise and fix a server that listens on 127.0.0.1 inside its container, use EXPOSE, -P and docker port correctly, and work through a cannot-connect problem step by step.
  5. Environment, Secret Files And Runtime Restrictions (4 labs): You can configure one image differently per run with -e and --env-file, deliver a secret as a read-only file instead of an environment variable, and run the task API with a read-only filesystem, no capabilities, no privilege escalation and resource limits.

Compose And Local Development

  1. Define The Service And Database With Compose (6 labs): You can describe the task API and a Postgres database in one compose.yaml, check it with docker compose config, run it with up, ps, logs and exec, and take it down knowing which objects survive.
  2. Health Checks, Dependencies And Reliable Startup (6 labs): You can reproduce a startup race, fix it with a HEALTHCHECK, a Compose healthcheck and depends_on conditions, read health status from ps and inspect, and explain why the application must still retry.
  3. Development Overrides, Hot Reloading And Debuggers (6 labs): You can keep development-only settings in compose.override.yaml, predict how Compose merges files, see code changes land in a running container with compose watch, keep tools behind a profile, and expose a debugger safely.
  4. Integration Tests, Test Data And Compose Cleanup (6 labs): You can run integration tests in a container against the real stack, seed and load test data, isolate each run with its own project name, turn the result into an exit code, and clean up every container, network and volume a run created.

Operate The Service And Hand Off

  1. Diagnose Crashes, Resource Limits And Unhealthy Containers (4 labs): You can reproduce a crash, an out of memory kill, a slow stop, a crash loop and an unhealthy container, and name the cause of each from its exit code, its recorded state, its restart count, its events and its health log.
  2. Build, Test And Promote The Same Image In CI (5 labs): You can build one image per commit, test that exact image, push it, and promote it to staging and production by pointing tags at the same digest, both by hand against a local registry and as a CI workflow with a build cache.
  3. Harden And Deliver The Complete Service Stack (5 labs): You can deliver the service and its database as one Compose stack that runs as a non root user on a read only filesystem, with no capabilities, no privilege escalation, resource limits, health checks, a restart policy, a graceful stop and a secret file, and prove every one of those controls from a shell.
  4. From Local Containers To Kubernetes (4 labs): You can show that the service image is a standard OCI artifact that any conforming runtime can run, explain why removing dockershim from Kubernetes did not affect images, and translate each part of the Compose stack into the Kubernetes object that takes over its job.

Certification courses