DevOps tutorials

The operational material here covers the path from a working application to something running somewhere other than your laptop. Docker first — writing an image that is small and reproducible rather than one that merely builds — then multi-container setups, then orchestration.

The Kubernetes guides cover deploying real applications rather than a single stateless container: persistent volumes, secrets, multi-service applications with a database behind them, and the configuration that turns a manifest into something that survives a restart.

Every guide states the versions it was written against. This tooling moves quickly, and a manifest that worked two API versions ago will be rejected outright rather than degrading gracefully.

Image construction gets attention first because it determines everything downstream. A multi-stage build separates the toolchain from the runtime, so a compiled artefact ships without the compiler that produced it. Layer ordering decides whether a code change rebuilds one layer or all of them. Base image choice accounts for most of the difference between a lean image and one measured in gigabytes.

On the orchestration side the guides deploy applications with state rather than a single stateless container, because that is where configuration actually gets difficult: persistent volumes, secrets that are not baked into an image, service discovery between components, and the readiness checks that stop traffic reaching a container that is running but not yet ready.

The examples target Linux containers and assume nothing about the host beyond a working Docker installation. Where a command differs on macOS or Windows the difference is noted, but the manifests and Dockerfiles themselves are portable.

A container that starts is not yet a container that can be operated. Logs go to stdout and stderr rather than to a file inside the image, because the file disappears with the container and nothing collects it. Configuration arrives through the environment, so the same image can run in staging and production without a rebuild. The process has to handle SIGTERM, since an orchestrator sends it and then waits a fixed grace period before killing the container outright. The guides cover each of these where they come up, rather than treating a successful build as the finish line.

The through-line is that the container is the easy part. Building a small image is a solved problem, and the guides here spend more time on what happens after it starts: the health check the orchestrator actually reads, the difference between a liveness and a readiness failure, the ten seconds a process gets between SIGTERM and SIGKILL, and the volume that survives a rollout.

Where a topic has both a Compose and a Kubernetes treatment, the two are written to be read together. Compose is where the dependency ordering and the startup race are easiest to see; Kubernetes is where the same problems reappear with different names and a probe configuration attached to each one.

Almost every guide here ends up at the same practical question: what does this look like when it fails at three in the morning. That is why the logs, the exit codes and the diagnostic commands get as much space as the happy path. An exit code 137 is the kernel killing a container that exceeded its memory limit, not an application error, and knowing which of those two you are looking at is the difference between tuning a JVM flag and reading a stack trace that does not exist.