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 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,…
The Compose file is not a single static document. It is a base configuration, and it can be layered with override files, scoped with profiles, and merged into a final model that Compose resolves before starting any container. This layering is what allows a single repository to serve development, testing, and production without duplicating the…
A microservices application has several services, and each one has its own codebase, its own dependencies, and its own runtime. Running the whole stack locally is the daily reality of a developer working on one of those services. The naive approach is to run the service under development with a local toolchain and run the…
Every container writes to stdout and stderr. That much is universal. What happens next depends entirely on the logging driver. The driver decides where the output goes, how it is formatted, and how long it is kept. Docker ships with a set of built-in drivers that cover the common cases: the local JSON files, the…