Containers
76 bites tagged Containers — interview questions with model answers, and 60-second explainers.
Building Images with Docker Compose
Docker Compose builds images from a `compose.yml` file, turning a Dockerfile into a runnable service within a multi-container app. It's for local dev where you need a database and backend to start together. The footgun: `up` won't rebuild without `--build`.
Docker Compose Networking: How Services Talk to Each Other
Docker Compose puts your services on a private network, letting them communicate using service names as hostnames. This is how a 'web' container finds your 'db' container. The footgun is using `localhost`; always use the service name for inter-container calls.
Docker Compose: Orchestrate Multi-Container Apps Locally
docker compose is a conductor for multi-container apps, using a single YAML file to define and run all the parts of your stack together. It's ideal for local development to spin up a database and API with one command.
Docker Compose Services: Defining Your App's Components
A service in Docker Compose is a blueprint for a running container. You define its image, ports, and environment to describe one piece of your application, like a web server or database. The footgun is using `build` and `image` together for one service.
The docker-compose.yml File: Your App's Blueprint
The `docker-compose.yml` file is a blueprint for defining and running multi-container Docker applications. Use it to spin up a local dev environment with a database, backend, and frontend with one command.
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.
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 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 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.
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.
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.
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.
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`.
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.
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.
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.
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.
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 Sidecar Pattern: Offload and Isolate Application Logic
The Sidecar Pattern attaches a helper container to your main application, like a sidecar on a motorcycle. It offloads tasks like logging or proxying, letting you add features without changing the main app's code. The footgun is over-engineering a solution.
Kubernetes StatefulSet: Pods with Stable Identity
A StatefulSet gives Kubernetes pods a stable identity and dedicated storage, like assigning a permanent desk and locker to an employee. Use it for databases or clustered apps where nodes need to find each other and retain data across restarts.
Docker Engine: Shipping Your Code in a Standard Box
Think of Docker as a standard shipping container for your code. It packages an app and all its dependencies into one unit that runs anywhere, solving the classic "it works on my machine" problem. The footgun is confusing it with a full VM; it's lighter.
Cloud Native Buildpacks: No More Dockerfiles
Cloud Native Buildpacks turn source code into container images without a Dockerfile. This lets platform teams enforce security and best practices, while app developers just push code. The footgun is assuming they're simple; they're a full build system.
CNI: The Universal Plug for Container Networking
CNI is the standard API that decouples container runtimes from network implementations. In Kubernetes, it lets you swap networking plugins like Calico or Flannel.
Kubernetes Pods: The Atomic Unit of Deployment
A Kubernetes Pod is the atomic unit of deployment, a logical host for containers sharing a network and storage. This is ideal for co-locating a main app with a helper "sidecar" container. The footgun: a Pod is not a container; you scale by adding more.
Get Containers bites daily.
Five a day, five minutes, offline. With quizzes so it sticks.
Open testing — you’ll join as an early tester.