Docker and container concepts

Containers and images

• Container A container is an ordinary process on the server, isolated by the kernel: it sees its own files, its own network and its own process list, and gets a share of CPU and memory. It starts in a fraction of a second because there is no operating system to boot. Beginner 1 exercise
• Image An image is a read-only package of everything a program needs to run: files, libraries, environment variables and the command to start. You build it once, then run it anywhere, as many times as you like. Beginner 2 exercises
• Image vs container The image is the recipe, the container is the dish: one image can start any number of containers, each with its own state. Deleting a container leaves the image intact, and changing a container never changes the image. Beginner 2 exercises
• Writable layer Each container gets a thin writable layer on top of its image. Every file it creates or changes lands there, and that layer is deleted with the container. Beginner 2 exercises
• Image tags A tag is a movable name for an image, like orders-api:1.4 or postgres:16. Several tags can point to the same image, and a tag can be moved to a new image at any time. Beginner 4 exercises
• Container lifecycle A container goes through created, running, exited and removed. docker stop, start and restart move it between these states; only docker rm deletes it, with its writable layer. Beginner 4 exercises
• Main process (PID 1) A container lives exactly as long as its main process, the one started by CMD or ENTRYPOINT. When that process exits, the container stops, whatever else runs inside. Beginner 2 exercises
• Exit codes When a container stops, docker ps -a shows the exit code of its main process. The number tells why it stopped: 0 it finished, 1 the app failed, 137 it was killed, 143 it was asked to stop. Beginner 6 exercises

Building images

• Dockerfile A Dockerfile is the recipe of an image: a base image, then instructions that copy files, run commands and say how the container starts. docker build turns it into an image, with one layer for each instruction that changes files. Beginner 4 exercises
• CMD and ENTRYPOINT CMD and ENTRYPOINT tell a container what to run. ENTRYPOINT is the fixed program, CMD the default arguments, which docker run can replace. Beginner 2 exercises
• Image layers An image is a stack of read-only layers, one for each instruction that changes files. Images built on the same base share its layers, on disk and in downloads. Intermediate 4 exercises
• Build cache docker build reuses a layer when its instruction and its inputs have not changed since the last build. The first instruction that changes invalidates the cache of every instruction after it. Intermediate 1 exercise
• Build context The build context is the folder given to docker build, often the final dot. Its files are sent to the builder, and they are the only files COPY can read. Intermediate 1 exercise
• .dockerignore A .dockerignore file at the root of the build context lists files that are never sent to the builder. It keeps images small and keeps secrets out of them. Intermediate 1 exercise
• Multi-stage builds A multi-stage Dockerfile has several FROM lines: the first stages compile with the full toolchain, the last one copies only the result. Compilers and sources never reach the final image. Intermediate 1 exercise
• Base images The FROM image decides most of the final size, the tools available and the security fixes you inherit. Full, slim, alpine and distroless variants trade convenience for size. Intermediate 2 exercises
• Static binaries A statically linked binary carries every library it needs, so it runs on scratch or distroless with nothing else in the image. Go builds one with CGO_ENABLED=0. Intermediate 1 exercise

Data and disk

• Volumes A volume is storage managed by Docker that lives outside any container. Mount it where an app writes its data, and the data survives docker rm, upgrades and recreated containers. Beginner 5 exercises
• Bind mounts A bind mount puts a folder of the server inside the container. A change on one side is seen at once on the other, which is ideal in development and risky in production. Intermediate 1 exercise
• Docker disk usage Images, stopped containers, volumes and build cache pile up on the server's disk until something runs out of space. docker system df shows what takes room and how much can be reclaimed. Beginner 2 exercises
• Dangling images A dangling image is an old image whose tag moved to a newer build. It shows up as <none>:<none>, nothing refers to it, and it can be removed safely. Beginner 1 exercise
• Log rotation Docker keeps everything a container prints, by default in a json-file that only disappears with the container. Rotation caps it: max-size and max-file, per container or for the whole daemon. Advanced 1 exercise
• Upgrading a database container A minor version reads the same data files: change the tag, keep the volume. A major version cannot: dump the data with the old version and restore it into the new one. Advanced 1 exercise

Networking

• Port publishing A container's ports are closed to the outside world until you publish them. -p 8080:80 forwards port 8080 of the server to port 80 of the container. Beginner 4 exercises
• Default bridge network Containers started without --network join the default bridge network. They can reach each other by IP address, but not by name. Beginner 1 exercise
• User-defined networks A network created with docker network create gives its containers a DNS: each one is reachable by its name. It also keeps them apart from containers on other networks. Beginner 2 exercises
• EXPOSE vs publishing EXPOSE in a Dockerfile only documents the port the app listens on; it opens nothing. Publishing with -p or ports: is what makes a port reachable from outside the server. Intermediate 1 exercise
• Proxies and container addresses Docker's DNS (127.0.0.11) returns the current address of a service's containers. A proxy that resolved the name once keeps the old address after the container is recreated. Advanced 1 exercise

Running containers

• Container logs Whatever the main process writes to stdout and stderr becomes the container's log. docker logs is the first thing to read when a container misbehaves. Beginner 3 exercises
• docker exec docker exec runs an extra command inside a running container, in the same files and the same network. It is how you look around, test a connection or open a shell. Beginner 3 exercises
• Environment variables Environment variables configure a container at start without rebuilding its image: the same image runs in staging and in production with different values. -e, --env-file and environment: in Compose set them. Beginner 3 exercises
• Restart policies A restart policy tells Docker what to do when a container stops: nothing (no), restart it after a crash (on-failure), or keep it running through crashes and reboots (unless-stopped, always). Beginner 4 exercises
• Healthchecks A healthcheck is a command Docker runs regularly inside the container to know whether the app really works. The container's status becomes starting, healthy or unhealthy. Intermediate 4 exercises
• Graceful shutdown docker stop sends SIGTERM to PID 1, waits for the grace period (10 seconds by default), then sends SIGKILL. A clean stop needs the app to receive the signal, and enough time to finish its work. Advanced 1 exercise

Memory and CPU

• Resource limits By default a container may use all the memory and all the CPU of the server. --memory and --cpus cap it, so one runaway service cannot take the whole server down. Intermediate 3 exercises
• OOM killer When a container goes over its memory limit, or the server runs out of memory, the kernel's OOM killer kills a process to free memory. The container exits with code 137. Intermediate 1 exercise
• Swap Swap is disk space the kernel uses as extra memory. It delays out-of-memory kills, but memory on disk is hundreds of times slower, so every service on the server slows down. Intermediate 2 exercises

Docker Compose

• Docker Compose Compose describes a whole application, its services, networks and volumes, in one compose.yaml file. docker compose up creates and starts everything, in the right order, with one command. Intermediate 8 exercises
• Compose networks Compose creates a network for each project and attaches every service to it. Services reach each other by service name, like db or cache, on their own ports. Intermediate 2 exercises
• Compose override files Compose merges several files: compose.yaml for what is shared, compose.override.yaml for development, and a production file given with -f. Each environment only changes what differs. Intermediate 1 exercise
• Startup order depends_on starts the database before the API, but started is not ready: PostgreSQL needs a few seconds before it accepts connections. condition: service_healthy waits until it really does. Intermediate 2 exercises
• Dev/prod parity Development and production should run the same image with different settings. Code mounted from the laptop, debug ports and hot reload belong to development only. Intermediate 1 exercise

Security

• Keeping secrets out of images Anything written into an image, by ENV, ARG, COPY or a RUN, can be read by whoever can pull it, even if a later layer deletes it. Secrets are given to the container when it starts. Beginner 4 exercises
• Running as non-root Containers run as root unless told otherwise. With USER in the Dockerfile, a compromised app only has the rights of an ordinary user. Intermediate 2 exercises
• File permissions in containers Inside a container, Linux permissions work as on any server: a process can only write where its user is allowed to. Users are numbers (UIDs), shared between the container and the server. Intermediate 1 exercise
• Build secrets Some builds need a credential: a private registry token, an SSH key. BuildKit secrets give it to one RUN only, without writing it into any layer, history or cache key. Advanced 1 exercise
• Read-only root filesystem read_only: true mounts the container's image read-only: nothing can be added or changed outside volumes and tmpfs mounts, neither by the app nor by an attacker who takes it over. Advanced 1 exercise
• Linux capabilities Root's powers are split into capabilities: CHOWN, SETUID, NET_RAW and so on. Docker gives 14 of them to every container by default; most services need none. Advanced 1 exercise

Shipping images

• Image registries A registry stores images so that other machines can pull them. An image's name is its address: registry host, project, repository and tag, as in registry.shop.internal/shop/api:1.4.0. Advanced 4 exercises
• Build once, deploy everywhere An image is built once, by the CI, and that very image goes to every environment and every server. Servers pull it; they never build it. Advanced 2 exercises
• Image digests A digest (sha256:...) is the hash of an image's manifest: it names exactly one image, forever. A tag is a label that anyone allowed to push can move to another image. Advanced 2 exercises

Orchestration with Swarm

• Swarm mode docker swarm init turns Docker engines into a cluster: managers keep the desired state and schedule work, workers run it. You describe services; the cluster keeps them running across the nodes. Expert 2 exercises
• Services and tasks A service is a desired state (an image, a number of replicas, constraints); the managers turn it into tasks, one container each, placed on the nodes that can run them, and replace any task that ends. Expert 5 exercises
• Overlay networks and the routing mesh Overlay networks span every node of the swarm. Each service gets a virtual IP that balances over its healthy tasks, and a published port answers on every node and forwards to a task wherever it runs. Expert 2 exercises
• Rolling updates docker service update replaces a service's tasks batch by batch, following deploy.update_config: how many at a time, in which order, how long to watch each one. Done right, customers never notice a release. Expert 2 exercises
• Automatic rollback update_config.failure_action decides what Swarm does when a new task fails during its monitor window: pause (default), continue, or rollback to the previous spec with rollback_config. Expert 1 exercise
• Swarm secrets docker secret create stores a value encrypted in the managers' Raft log; a service that lists it gets it as a file in /run/secrets, in memory, and nowhere else. docker service inspect never shows its value. Expert 2 exercises
• Placement constraints deploy.placement.constraints limits the nodes a service may run on: by role, host name, or labels you put on nodes. It is how a stateful service stays where its data is. Expert 4 exercises
• Managers and quorum Managers agree through Raft: every change needs a majority of all the managers. 3 managers tolerate 1 failure, 5 tolerate 2; 2 managers tolerate none. Expert 1 exercise

Designing a platform

• Supply-chain security Every image you run is built on images and packages written by others. Supply-chain security is making sure that what you build and deploy is exactly what you reviewed, even if a registry, a mirror or an account is compromised. Architect 1 exercise
• Multi-platform images An image is built for one CPU architecture. An image index groups several, one per platform (linux/amd64, linux/arm64), under a single tag: each machine pulls the one it can run. Architect 1 exercise
• Capacity planning Capacity planning is making sure the cluster can hold what the services need, including after losing a node (N+1), and telling the scheduler what each task needs so that it places them accordingly. Architect 1 exercise
• Disaster recovery drills A recovery plan says how to rebuild everything somewhere else from what survives: the repository, the registry, the vault and the backups. RTO is how long it takes, RPO how much data can be lost. Only a drill proves both. Architect 1 exercise