Docker Compose
Multi-container apps, services, networks, local dev stacks.
Theory
Docker Compose defines and runs multi-container applications using a single docker-compose.yml file. Instead of running multiple docker run commands with long flags, you declare all services, networks, and volumes in YAML and start everything with docker compose up. Compose is ideal for local development environments that mirror production topology.
A compose file has three top-level keys: services (container definitions), volumes (named persistent storage), and networks (custom bridge networks). Each service specifies: image or build context, ports (host:container), environment variables or env_file, volumes, depends_on (startup order), and healthcheck.
depends_on: [db] ensures the db container starts before the app container, but it only waits for the container to start — not for the database to be ready. Use a healthcheck on the db service and condition: service_healthy in depends_on to wait for actual readiness. Without this, apps crash on startup because Postgres isn't accepting connections yet.
Named volumes persist data across container restarts. Anonymous volumes (mounted paths without a name) are lost when the container is removed. Bind mounts (./src:/app/src) mount host directories into containers — perfect for hot-reload development where you edit code on the host and see changes instantly in the container.
Environment variables: define inline (environment: - DB_URL=postgres://...) or load from a file (env_file: .env). The .env file in the compose project root is automatically loaded for variable substitution in the YAML: image: myapp:${VERSION}. Never commit .env files with real secrets — .gitignore .env and document required variables in .env.example.
Networks: by default Compose creates a bridge network and all services join it, discovering each other by service name (app connects to db on hostname db:5432). Custom networks isolate groups of services — a frontend network for web+nginx, a backend network for web+db, with the web service on both. Services on different networks can't reach each other by default.
Production use: Compose is not a production orchestrator (no auto-scaling, no cross-host networking, no rolling deploys). For production, use Kubernetes or Docker Swarm. However, docker compose up is valid on a single VM for small deployments with Watchtower for auto image pull. The Compose file structure maps closely to Kubernetes manifests, making it a good learning step.
Architecture Diagram
Users / clients
|
Docker Compose
|
Core services
|
Data + observabilityExamples
# Docker Compose
# Multi-container apps, services, networks, local dev stacks.
# Validate in staging before production rollout.Interview Questions
What problem does Docker Compose solve?
It addresses the core use case described in production architecture — map features to reliability, scale, or velocity outcomes.
Key components of Docker Compose?
Identify inputs, outputs, control plane, data plane, and failure domains — interviewers want structured decomposition.
Common production pitfalls?
Misconfiguration, missing observability, no rollback path, and scaling bottlenecks under peak load.
How do you test changes safely?
Staging parity, canary/gradual rollout, automated health checks, and documented rollback.
Metrics to prove success?
Error rate, latency percentiles, throughput, cost, and toil reduction — pick one primary SLO.
Beginner vs advanced concern?
Beginners focus on setup; advanced teams focus on blast radius, security boundaries, and operability at 10× scale.
Best Practices
- Treat Docker Compose config as code with review and CI validation.
- Define SLOs and dashboards before production cutover.
- Document rollback and ownership for on-call.
- Use least privilege for credentials.
Common Mistakes
- Adopting Docker Compose without measurable success criteria.
- No staging environment mirroring production constraints.
- Missing rollback path during incidents.
- Undocumented on-call expectations.
Cheat Sheet
Practical Exercises
Stand up Docker Compose locally or in free tier; document commands and failure recovery.
Introduce misconfiguration; practice detection and rollback under time limit.