Tutorials covering the tools that developers use every day — version control, editors, build systems, package managers, containers, and the command-line utilities that make work faster. Each chapter is standalone, built around real examples and verified commands.
A bridge network puts the container behind a NAT. The container has its own IP, but it is on a virtual subnet, and the outside world reaches it only through published ports. Some applications do not accept this. A legacy application that uses broadcast discovery, a monitoring tool that needs to see all traffic, a…
A published port is a promise. The container’s application listens on a port inside its own network namespace, and the host promises that a connection to a specific host port will reach it. The mechanism behind that promise is a set of iptables rules in the host’s NAT table, a connection-tracking system, and—for the traffic…
A running container is not necessarily a working container. The main process can be alive while the application inside it is wedged — a web server stuck in an infinite loop, a database accepting connections but unable to serve queries, a worker that has lost its connection to the queue. Docker’s HEALTHCHECK instruction exists to…
A container that exits is not always a container that should stay exited. A web server that crashes because of a transient network error should come back. A database that is killed by the OOM killer should restart. A batch job that completes successfully should stay stopped. Docker’s restart policies are the mechanism that distinguishes…
A container without resource limits is a container that can consume the entire host. A runaway process inside a container can starve every other container, exhaust the host’s memory, and trigger the kernel’s OOM killer, which may terminate processes outside the container as well. Docker’s resource allocation controls exist to prevent this. They set boundaries…
When a container reaches its memory limit, the Linux kernel does not gracefully ask it to free memory. It sends SIGKILL. The process dies immediately, without cleanup, without flushing buffers, without closing connections. The container exits with code 137 (128 + 9), and docker inspect reports OOMKilled: true. This is the cgroup OOM killer, and…
Docker Compose begins with a single file. A compose.yaml file describes an entire application stack — every service, network, volume, and configuration — in declarative YAML. Instead of running docker run commands one by one, with all the flags, environment variables, port mappings, and network connections remembered separately, Compose reads the file and creates the…
The Compose specification is the schema that defines what a compose.yaml file can contain. It is not a Docker-specific format; it is an open specification that Docker Compose, Docker Swarm (partially), and other tools implement. The specification defines the top-level elements — services, networks, volumes, configs, secrets, and the project-level settings — and the sub-elements…
A multi-container application has an order. The database must be ready before the API can connect. The API must be ready before the frontend can proxy to it. The migration must complete before the application starts serving traffic. Compose’s depends_on is the key that expresses this order, and the key has two forms with very…
A Compose service is an abstract definition of a container. When the service is started, Compose creates one container for it. The scale option and the –scale flag create multiple containers for the same service, and Docker’s embedded DNS server load-balances the requests across them. The scaling is horizontal: more containers of the same service,…