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.
Running Docker as root has always been a security trade-off. The daemon runs with full privileges, and a container escape can escalate to host root. Rootless mode changes that. The daemon and every container it runs execute as an unprivileged user, using user namespaces and subordinate UID mappings to create the illusion of root inside…
Environment variables are the default way to pass configuration to containers, and for non-sensitive values they are fine. For secrets they are a liability. A password passed with -e is visible in docker inspect, inherited by every child process, and often printed in logs when something goes wrong. Docker’s secret management exists to close that…
A container image built on an x86_64 laptop runs on an x86_64 server. It does not run on an Apple Silicon Mac, an AWS Graviton instance, or a Raspberry Pi. The binary inside the image is compiled for one CPU architecture, and the kernel rejects it on any other. Multi-platform builds solve this by producing…
A multi-arch image is not a single binary that runs everywhere. It is a manifest list, an OCI image index that points to separate per-architecture images . When a client pulls a tag, the container runtime reads the list, selects the entry matching the host’s architecture, and pulls only that image. The result is one…
A private container registry is the backbone of any serious container workflow. Public registries like Docker Hub are convenient for open-source images, but they impose pull rate limits, expose your image names to the world, and create a dependency on an external service that can go down or change its terms. For teams building proprietary…
A private registry running without authentication and TLS is a liability. Anyone who can reach the port can push malicious images, overwrite your tags, or pull your proprietary code. Anyone on the network path can read every byte of your images in transit. And even a secured registry will eventually fill its disk with orphaned…
Docker Swarm is Docker’s native clustering and orchestration solution, built directly into the Docker Engine. Unlike Kubernetes, which is a separate system that you install on top of your infrastructure, Swarm mode is activated with a single command and requires no additional software. This integration is both its greatest strength and its most limiting constraint:…
A Docker Swarm service is not a container. It is a declaration of intent. When you create a service, you are telling the Swarm manager what the cluster should look like—how many instances of an image should be running, how they should be networked, and what policies govern their lifecycle. The manager then works continuously…
Docker Swarm overlay networks solve a fundamental problem: how do containers running on different physical hosts communicate as if they were on the same machine? The answer has two layers. The first is the overlay network itself—a virtual Layer 2 network that spans all Swarm nodes, with container traffic encapsulated in UDP datagrams through the…
Docker Swarm provides two native cluster objects for delivering data to services: secrets for sensitive information and configs for non-sensitive configuration. Both solve the same fundamental problem—how to inject data into containers without baking it into images or passing it through environment variables—but they differ in one critical dimension: secrets are encrypted at rest in…