Intermediate

Take control of your container logs! Configure different logging drivers for better management, rotation, and analysis. Default logging: json-file By default, Docker uses the json-file driver: services: app: image: myapp logging: driver: json-file options: max-size: "10m" # Rotate after 10MB max-file: "3" # Keep 3 rotated files compress: "true" # Compress rotated files Without rotation, logs can fill your disk! Common logging drivers 1. Local driver (efficient storage) Optimized for performance and disk usage: ...

Speed up builds and reduce image size by managing build contexts effectively. Don’t send unnecessary files to the Docker daemon! Understanding build context The build context is what gets sent to Docker daemon: services: app: build: . # Current directory is the context # Everything in . gets sent to daemon! Check your context size: # See what's being sent docker build --no-cache . 2>&1 | grep "Sending build context" # Output: Sending build context to Docker daemon 458.2MB 😱 Custom build contexts Specify different contexts for different services: ...

Secure your application architecture by isolating services in separate networks. Not every service needs to talk to every other service! Default behavior: All connected By default, all services share the same network: # All services can communicate services: web: image: nginx api: image: myapi database: image: postgres Problem: web can directly access database - potential security risk! Network isolation pattern Create separate networks for different tiers: ...

Keep configurations DRY! The include directive enables modular, reusable Compose setups. Basic include usage Split configurations into logical modules: # compose.yml include: - path: ./services/database.yml - path: ./services/cache.yml - path: ./services/monitoring.yml services: app: image: myapp:latest depends_on: - postgres - redis # services/database.yml services: postgres: image: postgres:15 volumes: - postgres_data:/var/lib/postgresql/data volumes: postgres_data: Project-wide organization Structure complex projects: project/ ├── compose.yml # Main entry point ├── common/ │ ├── networks.yml # Shared networks │ └── volumes.yml # Shared volumes ├── services/ │ ├── frontend.yml # Frontend services │ ├── backend.yml # Backend services │ └── database.yml # Data layer └── environments/ ├── dev.yml # Development overrides └── prod.yml # Production config # compose.yml include: - path: ./common/networks.yml - path: ./common/volumes.yml - path: ./services/frontend.yml - path: ./services/backend.yml - path: ./services/database.yml - path: ${COMPOSE_ENV:-./environments/dev.yml} Conditional includes Include files based on environment: ...

Extension fields aren’t just for YAML reusability - they’re powerful metadata carriers that tools can leverage for platform-specific configurations! Extension fields as metadata Any key starting with x- is ignored by Compose but preserved in the configuration: # Top-level metadata x-project-version: "2.1.0" x-team: "platform-engineering" x-environment: "production" x-region: "us-east-1" services: api: image: myapi:latest # Service-level metadata x-tier: "frontend" x-cost-center: "engineering" x-sla: "99.9" x-owner: "api-team@company.com" Compose Bridge and Kubernetes integration Extension fields can provide hints for Kubernetes deployment: ...