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.
Docker’s CLI plugin system is the modern, supported way to extend the docker command with new subcommands. Unlike the deprecated engine plugin system, which required registering a daemon-side plugin with a manifest and Unix socket, a CLI plugin is simply an executable binary that Docker discovers and invokes. The naming convention is the entire contract:…
A database container is not like a web server container. The web server is stateless—kill it, restart it, and it serves the same content. The database holds state, and the entire value of the containerization exercise depends on that state surviving. Docker’s default filesystem is ephemeral: when the container is removed, everything written inside it…
A reverse proxy sits between the public internet and your application containers. It terminates TLS, routes requests by hostname or path, and forwards traffic to the appropriate backend. Containerizing it means the proxy itself becomes a service in the Compose stack, with its configuration mounted or baked into the image, and its lifecycle managed alongside…
A Node.js application containerized naively produces an image that is both enormous and insecure. A single-stage build with COPY . . followed by npm install bakes every devDependency—TypeScript, Jest, ESLint, Webpack—into the runtime image, along with the shell and package manager that an attacker can use after a breach. The official node:20 image is built…
A Python web application in a container is only as good as its process model. Running uvicorn main:app inside a Docker image works for development, but it leaves every CPU core beyond the first idle and provides no process supervision when a worker crashes. The production pattern pairs a process manager (Gunicorn) with an async…
Compiled languages produce a single artifact that either runs or does not. There is no interpreter, no virtual environment, no dependency resolution at startup. This property makes them ideal candidates for minimal container images: the build stage can be heavy, but the runtime stage needs only the binary and whatever shared libraries it dynamically links…
A Dev Container is not a production image with debugging tools bolted on. It is a separate artifact defined by a structured metadata file—devcontainer.json—that tells the editor how to build, start, and configure a containerized workspace . The distinction matters: production images should be minimal and hardened; development images should include compilers, debuggers, language servers,…
A CI pipeline for Docker images is not a single build step. It is a sequence of decisions: build the image without pushing, run the container to verify it starts, check a health endpoint, then rebuild with the same cache and push the tested artifact. GitHub Actions provides the primitives for this sequence through Docker’s…
The difference between a Docker CI pipeline that finishes in thirty seconds and one that takes four minutes is almost never the code. It is whether the layer cache survived from the previous run. GitHub-hosted runners are ephemeral: every job starts with an empty filesystem, and BuildKit’s local cache—the default mechanism that makes local builds…
The choice between DinD and DooD is a choice about where the Docker daemon lives and who controls it. Docker-in-Docker runs a nested daemon inside the CI job container, giving each job its own isolated Docker environment with its own image cache, network, and storage. Docker-outside-of-Docker mounts the host’s Docker socket into the job container,…