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 single container’s logs are accessible with docker logs. A hundred containers across ten hosts are not. The logs are scattered across the machines, and the search requires the SSH into each one. The centralized log aggregation solves the problem: the container logs are shipped to a central system, indexed, and searchable from the single…
A running container is not the same as a healthy container. The docker ps shows the Up status, but it does not show the CPU spikes, the memory growth, the network saturation, or the disk I/O. The monitoring stack answers the question the docker stats cannot: what is the trend, what is the historical baseline,…
The Docker daemon is the background process that builds, runs, and manages every container on the host. It listens on the socket, pulls the images, starts the containers, and writes the logs. By default, it works well enough for the basic use, but the production environment demands the control over the logging, the storage, the…
A Docker host accumulates garbage. The stopped containers linger, the dangling images pile up, the build cache grows, and the unused volumes sit idle. The disk fills slowly, and then suddenly the builds fail, the pulls fail, and the daemon stops responding. The cleanup is not a one-time task; it is the ongoing maintenance. The…
A Docker image is not a single artifact. It is a stack of layers: a base operating system with its package manager, a language runtime with its dependency tree, and the application code itself. Each layer carries its own inventory of packages, and any one of them can contain a known vulnerability. Scanning exists to…
A container is a process, not a virtual machine. It runs directly on the host kernel, and the kernel does not distinguish between a process running in a container and a process running on the host. The only thing separating them is a set of kernel features: namespaces, cgroups, and capabilities. Capabilities are the most…
Capabilities restrict which operations a process may perform. Seccomp restricts which system calls a process may make. Linux Security Modules go one layer deeper: they restrict which resources a process may touch, even when the operation is permitted and the syscall is allowed. AppArmor does this by matching file paths and network rules. SELinux does…
A container shares the host kernel. Every action the containerized process takes, from opening a file to sending a network packet, is a system call into that kernel. The kernel’s syscall interface is the largest attack surface in the container model: roughly 300 calls, each a potential entry point for a kernel vulnerability. Seccomp (secure…
A container runs as root inside its own namespace by default. Without user namespace remapping, that root is the same root that owns the host. A process that escapes the container, or a kernel vulnerability that lets a process break out of the namespace, lands on the host as root. User namespace remapping (userns-remap) changes…
A container image tag is a mutable label. An attacker who compromises a registry can repoint myapp:latest to a malicious image, and every system that trusts the tag pulls the attacker’s code. Image signing closes this gap by attaching a cryptographic signature to the image digest. The signature proves who published the image and that…