Docker &amp; Kubernetes

VMs vs. Containers: Houses vs. Apartments

VMs are like separate houses, each with a full OS. Containers are apartments sharing the host OS kernel. VMs provide strong isolation for different OSes, while containers offer lightweight packaging for apps.

The 'Works on My Machine' Problem

Code runs on your laptop but fails in production because of hidden differences in environments. Docker solves this by packaging an app and its dependencies into a portable container, ensuring it runs the same everywhere.

Linux Namespaces: A Virtual Slice of the OS

Linux namespaces give a process a virtualized slice of OS resources, like its own process tree or network stack. This is the core magic behind containers, providing the illusion of a separate machine without the overhead of a full virtual machine.

Linux cgroups: Resource Fences for Processes

Cgroups are resource fences for processes, letting the Linux kernel enforce CPU and memory limits. Container runtimes use them to isolate containers, which is how Kubernetes enforces Pod resource limits.

Container Runtime: The Engine That Runs Your Containers

A container runtime is the low-level engine that executes containers. Kubernetes uses a runtime like containerd or CRI-O on each node to pull images and manage container lifecycles.

OCI: The USB-C of Containers

OCI is the USB-C of containers: open standards that let any compliant runtime execute any image. It prevents vendor lock-in by decoupling image format from runtime. The footgun is treating "Docker image" as proprietary rather than an OCI-compliant bundle.

Union File Systems: Docker's Layered Magic

A Union File System stacks read-only layers and adds a writable one on top, like transparent overlays. This lets containers share base images, saving disk space, while isolating changes via copy-on-write. The footgun is performance on write-heavy apps.

OCI Runtime Spec: The 'How to Run' Standard for Containers

The OCI Runtime Spec is the universal instruction manual for executing a container. It defines a standard config.json and lifecycle actions, ensuring a container runs the same way across different runtimes like runc or crun.

Container Runtime Shim: Decoupling the Container Lifecycle

A runtime shim is a small process that decouples the container daemon (like containerd) from the container itself. This lets the daemon restart without killing running containers.

seccomp: A Kernel-Level Allowlist for Syscalls

seccomp is a Linux kernel firewall for system calls (syscalls), restricting which operations a process can request. Docker and Kubernetes use it to harden containers against exploits. The footgun is creating a custom profile so restrictive it breaks your app.

Container Lifecycle: From Create to Remove

A container is a state machine: created, running, paused, stopped, and removed. You manage this with commands like docker run, while orchestrators automate it. The footgun: stop doesn't delete a container; you must rm it to free up disk space.

The Dockerfile: A Recipe for Your Container

A Dockerfile is a text-based recipe for building a Docker image, specifying the OS, code, and dependencies. You use it to create consistent, portable application environments.

Docker Image Tagging: Versioning for Containers

A Docker tag is a human-readable label for a specific image version, like ubuntu:22.04. You use tags to pull specific base images or version your own builds. The biggest footgun is relying on the latest tag, which is just a convention.

Docker Volumes: Persistent Data for Ephemeral Containers

Think of a Docker Volume as an external hard drive for your container. It persists data even after a container is removed, perfect for databases or user uploads. The footgun is confusing volumes with bind mounts, which are less portable.

Docker Networking: How Containers Talk to Each Other

Docker gives each container its own isolated network, preventing port conflicts. Containers connect via networks, like bridge for local communication. For containers to find each other by name, you must use a user-defined bridge network; the default one…

Docker Build Cache: Don't Rebuild What Hasn't Changed

Docker's build cache is like a saved game for your image layers. It skips rebuilding if instructions and files haven't changed. A common footgun is an early COPY . . command, which can invalidate the cache for all subsequent steps on every code change.

intermediate1 min read

The .dockerignore File: Keep Your Build Context Lean

.dockerignore is like .gitignore for your Docker build. It tells the daemon which files to exclude from the build context, preventing large or sensitive files from slowing your build and bloating your image. The footgun is forgetting it and sending everything.

Docker Multi-stage Builds: Slimmer, Faster Images

Treat your Dockerfile like a pipeline: build your app in one stage with all its tools, then copy only the final artifact to a clean production stage. This keeps images small by excluding build-time dependencies.

Docker Image Scanning: A Background Check for Your Code

Docker image scanning is a background check for your software dependencies, checking packages against known vulnerability lists (CVEs). It's used in CI/CD to block vulnerable builds and in registries for continuous monitoring.