More in Docker & Kubernetes — page 14
Docker Image Prune: Reclaim Your Disk Space
Docker image prune is a garbage collector for your local Docker setup, deleting unused images to free up disk space. Use it when low on storage after many builds. The footgun: by default, it only removes *dangling* (untagged) images, not all unused ones.
Docker Login: Authenticating to a Container Registry
docker login saves your credentials for a container registry, letting you push and pull private images. Use it before interacting with private repos on Docker Hub, ECR, or GCR. The footgun: credentials are often stored unencrypted by default.
Docker Push and Pull: Moving Container Images
Think of `docker push` and `pull` like `git push` and `pull`, but for container images. They move images between your machine and a remote registry. A common mistake is forgetting to tag an image with the registry's full address before pushing.
Docker Hub: The Central Repository for Containers
Think of Docker Hub as the GitHub for Docker images. It's a central repository from Docker, Inc. for finding, storing, and sharing pre-built software containers to automate code deployment.
Docker Compose Secrets: Keep Credentials Out of Your Code
Docker Compose Secrets inject sensitive data into containers as files at runtime, keeping credentials out of your version-controlled `docker-compose.yml`. Use them for API keys and passwords. The footgun: your app must read from a file, not an env var.
Extending Compose Files for Different Environments
Think of extending Compose files like CSS for your services; a base file defines the structure, and override files style it for different environments. This is used to manage settings like local code mounts for dev vs. restart policies for prod.
Docker Compose Profiles: Activate Service Groups
Docker Compose profiles let you toggle groups of services on or off within a single `compose.yaml` file. Use it to separate your core app from debugging utilities or to define a "local dev" setup versus a "CI" setup.
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: 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.