Docker
99 bites tagged Docker — interview questions with model answers, and 60-second explainers.
Docker Compose: Control Startup with `depends_on`
`depends_on` controls service startup order in Docker Compose, ensuring a database starts before your app. The footgun: it only waits for the container to start, not for the application inside to be ready. Use `healthcheck` for true readiness.
Environment Variables in Docker Compose
Environment variables are the runtime knobs for your Docker Compose services, letting you pass configuration like API keys or database URLs without rebuilding your image. Use them to connect services or set feature flags.
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 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.
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 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.
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.
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.
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.
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.
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 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.
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.
Docker Image Tagging: A Strategy for Reliable Deployments
Think of Docker tags as pointers, not permanent labels. Multiple tags like `v1.2.3` and `production` can point to the same image SHA, enabling reliable CI/CD and rollbacks. The footgun is relying on mutable tags like `latest` in production.
Docker Compose: A Tool for Containerized Applications
Docker Compose is a tool in the Docker suite for running applications in containers. It ensures your app runs the same everywhere by packaging it with its dependencies, solving the 'works on my machine' problem.
Get Docker bites daily.
Five a day, five minutes, offline. With quizzes so it sticks.
Open testing — you’ll join as an early tester.