More in DevOps & Cloud — page 42
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.
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 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.
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.
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.