Docker-Compose

The real power comes from using all three mechanisms together, each doing what it does best. The scenario A team maintaining a web application with: Shared infrastructure (database, monitoring) reused across projects Common service configuration (logging, labels) applied to all services Different settings for local development vs CI vs production Project structure my-project/ ├── compose.yml # Main entry point ├── compose.override.yml # Local dev overrides ├── compose.ci.yml # CI-specific overrides ├── base/ │ └── service-base.yml # Shared service config (extends) └── infra/ ├── database.yml # Postgres stack (include) └── monitoring.yml # Prometheus + Grafana (include) Step 1: Shared service config with extends Define common configuration once: ...

Now that you understand how include, extends, and override files work, how do you pick the right one? Here’s a practical guide. Use override files for environment-specific configuration Override files are the right choice when you need to adapt the same stack to different environments or developer setups: # compose.yml - base definition, committed to git services: app: image: myapp:${TAG:-latest} environment: NODE_ENV: production # compose.override.yml - local dev tweaks, optionally gitignored services: app: build: . # Build locally instead of pulling image environment: NODE_ENV: development volumes: - .:/app # Mount source for hot reload Good fit for: ...

Docker Compose gives you three ways to split and reuse configurations. They look similar but work at different levels and serve different purposes. Override files: project-level merge Override files are merged with your main compose.yml at the project level. compose.override.yml is loaded automatically; additional files require the -f flag: # compose.override.yml is loaded automatically docker compose up # Explicit merge docker compose -f compose.yml -f compose.prod.yml up Mappings are merged (override wins), arrays are concatenated: ...

Need custom DNS resolution in containers? Use extra_hosts to add hostname mappings without touching system files! Basic extra_hosts usage Add custom host entries to containers: services: app: image: myapp extra_hosts: - "api.local:192.168.1.100" - "db.local:192.168.1.101" - "cache.local:192.168.1.102" Inside the container: docker compose exec app cat /etc/hosts # 127.0.0.1 localhost # 192.168.1.100 api.local # 192.168.1.101 db.local # 192.168.1.102 cache.local Dynamic host resolution Use host machine’s IP dynamically: services: app: image: myapp extra_hosts: - "host.docker.internal:host-gateway" # Magic value! This maps to: ...

Speed up I/O operations and enhance security by using tmpfs for temporary data. RAM-based storage that vanishes on restart! What is tmpfs? Tmpfs is a temporary filesystem that resides in memory: ⚡ Ultra-fast (RAM speed) 🔒 Secure (data doesn’t persist) 🧹 Self-cleaning (cleared on restart) Basic tmpfs usage Simple tmpfs mount: services: app: image: myapp tmpfs: - /tmp - /app/cache - /var/run With size limits: services: app: image: myapp tmpfs: - /tmp:size=100M - /app/cache:size=500M - /var/run:size=10M Advanced tmpfs options Fine-tuned configuration: ...