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 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…
A homelab or small server deployment that runs on a single machine is not highly available. When that machine reboots, every service goes down. When a disk fails, every container is lost. The purpose of building a Swarm cluster for a homelab is not to match the scale of a cloud provider—it is to eliminate…
Docker Compose and Kubernetes both run containers, but they are built on fundamentally different assumptions about what a deployment is. Compose assumes a single host, a single Docker Engine, and a developer who wants to start a multi-container application with one command. Kubernetes assumes a cluster of machines, a control plane that continuously reconciles desired…
kompose is the official Kubernetes project for converting Docker Compose files into Kubernetes or OpenShift manifests . Its purpose is mechanical translation: it reads the services, volumes, and port definitions in a compose.yaml file and produces Deployments, Services, and PersistentVolumeClaims that the Kubernetes API can accept . The tool is explicitly designed as a starting…
Docker Engine has always been a layered system. When you run docker run, the CLI talks to dockerd, which delegates to containerd, which in turn uses runc to create the actual container process . The containerd layer is the core runtime: it manages images, snapshots, and container lifecycle, and it is the component that Kubernetes…
The Open Container Initiative (OCI) is the governance body that turned containers from a Docker-specific technology into an open industry standard. Before OCI, the container ecosystem was locked into Docker’s proprietary formats: an image built by Docker ran on Docker, a registry built by Docker served Docker, and an alternative runtime had to reverse-engineer the…
The container runtime landscape is not a single tool but a layered ecosystem, and understanding the alternatives requires understanding what problem each one solves. CRI-O and Podman are both Red Hat-originated projects that emerged from the same architectural insight: Docker’s monolithic daemon was too much for most use cases, and the OCI specifications made it…
Podman Desktop is the graphical interface that turns Podman from a command-line tool into a complete development environment. It installs and configures Podman, provides a dashboard for containers, images, pods, and volumes, and integrates with Kubernetes through Kind, Minikube, and OpenShift . The tool is available on Linux, macOS, and Windows, and it joined the…