Using Advanced Docker Compose Features

1. Using Compose Profiles

Docker Compose profiles allow you to define and activate different sets of services or configurations based on environment or use case. This is useful for managing development, testing, and production environments with different service sets.

Profile	Services	Description
development	`web, db, redis`	Full stack for local development with debugging tools
testing	`web, db, test-runner`	Environment for running automated tests
production	`web, db, redis, load-balancer`	Production-ready services with load balancing

Example: Defining Profiles in Compose File

services:
  web:
    image: nginx
    profiles: [development, production]
  db:
    image: postgres
    profiles: [development, testing, production]
  redis:
    image: redis
    profiles: [development, production]
  test-runner:
    image: node:18
    profiles: [testing]
    command: npm test

Example: Activating a Profile

docker compose --profile development up

Note: Profiles are defined at the service level and can be activated using the --profile flag when running Docker Compose commands.

2. Using Watch Mode

Example: Watch Mode in docker-compose.yml

version: '3.8'
services:
  app:
    build: .
    volumes:
      - .:/app
    watch:
      - path: .
        target: /app
        action: sync

Option	Description	Values
watch	Enables file watching and synchronization	`array`
path	Source directory to watch for changes	`string`
target	Target directory in container to sync to	`string`
action	Sync action to perform on change	`sync`, `ignore`

Note: Watch mode is available in Docker Compose v2.20+ and requires Docker Desktop for full functionality.

3. Implementing Health Checks in Compose

Property	Description	Example
healthcheck	Defines how to test if a service is healthy	`healthcheck: test: ["CMD", "curl", "-f", "http://localhost"] interval: 30s timeout: 10s retries: 3`

Example: Basic HTTP Health Check

services:
  web:
    image: nginx
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost/health"]
      interval: 30s
      timeout: 10s
      retries: 3

Example: Custom Script Health Check

services:
  app:
    image: myapp
    healthcheck:
      test: ["CMD", "/bin/sh", "-c", "pg_isready -U user -d db"]
      interval: 1m
      timeout: 10s
      retries: 3

Note: Health checks are only supported in Docker Compose v2.1+.

Warning: If a service fails health checks, it will be restarted automatically if restart policy is set.

4. Defining Deploy Configuration

Field	Description	Values
deploy	Defines deployment configuration for the service	`object`
deploy.replicas	Number of containers to run for this service	`number`
deploy.update_config	Configuration for updates to the service	`object`
deploy.update_config.parallelism	Number of containers to update at once	`number`
deploy.update_config.delay	Delay between updates (e.g., `10s`)	`duration`
deploy.update_config.failure_action	Action to take on update failure (e.g., `rollback`)	`rollback`, `pause`
deploy.rollback_config	Configuration for rollback behavior	`object`
deploy.rollback_config.parallelism	Number of containers to rollback at once	`number`
deploy.rollback_config.delay	Delay between rollback updates (e.g., `10s`)	`duration`
deploy.rollback_config.failure_action	Action to take on rollback failure (e.g., `pause`)	`rollback`, `pause`
deploy.restart_policy	Restart policy for containers	`object`
deploy.restart_policy.condition	When to restart (e.g., `on-failure`)	`none`, `on-failure`, `any`
deploy.restart_policy.delay	Delay before restarting (e.g., `5s`)	`duration`
deploy.restart_policy.attempts	Number of attempts to restart	`number`
deploy.restart_policy.window	Time window to consider restarts (e.g., `120s`)	`duration`
deploy.resources	Resource limits and reservations	`object`
deploy.resources.limits	Resource limits (e.g., CPU, memory)	`object`
deploy.resources.limits.cpu	Maximum CPU shares (e.g., `0.5`)	`number`
deploy.resources.limits.memory	Maximum memory usage (e.g., `512M`)	`string`
deploy.resources.reservations	Resource reservations (e.g., CPU, memory)	`object`
deploy.resources.reservations.cpu	Reserved CPU shares (e.g., `0.25`)	`number`
deploy.resources.reservations.memory	Reserved memory (e.g., `256M`)	`string`
deploy.placement	Constraints for where containers run	`object`
deploy.placement.constraints	List of constraints (e.g., `node.role == manager`)	`array`
deploy.placement.max_replicas_per_node	Maximum containers per node	`number`
deploy.endpoint_mode	How services are accessed (e.g., `vip`)	`dnsrr`, `vip`
deploy.labels	Labels to apply to the service	`object`

Example: Basic deploy configuration

version: '3.8'
services:
  web:
    image: nginx
    deploy:
      replicas: 3
      update_config:
        parallelism: 1
        delay: 10s
        failure_action: rollback
      rollback_config:
        parallelism: 1
        delay: 10s
        failure_action: pause
      restart_policy:
        condition: on-failure
        delay: 5s
        attempts: 3
        window: 120s
      resources:
        limits:
          cpu: '0.5'
          memory: 512M
        reservations:
          cpu: '0.25'
          memory: 256M
      placement:
        constraints:
          - node.role == manager
        max_replicas_per_node: 1
      endpoint_mode: vip
      labels:
        env: production

5. Using Fragments and Extensions

Docker Compose supports fragment and extension features to help organize and reuse configuration across multiple compose files.

Feature	Description	Usage
fragments	Reusable configuration blocks defined in separate files and included using `include`.	`services: web: image: nginx include: ./fragments/web.yaml`
extensions	Custom keys that can be added to compose files for tool-specific configurations.	`x-custom: version: "1.0" config: key: value`

Example: Using Extensions

x-custom:
  version: "1.0"
  config:
    key: value

services:
  web:
    image: nginx
    x-custom:
      config:
        key: override

Note: Extensions are not part of the official Docker Compose specification and may vary between tools.

6. Interpolating Environment Variables

Variable	Value	Description
${VAR:-default}	`value`	If `VAR` is set, use its value; otherwise use `default`.
${VAR:-$DEFAULT}	`value`	If `VAR` is set, use its value; otherwise use the value of `DEFAULT`.
${VAR:-"default value"}	`value`	If `VAR` is set, use its value; otherwise use `"default value"`.
${VAR:=default}	`value`	If `VAR` is set and not empty, use its value; otherwise use `default`.
${VAR:=}	`value`	If `VAR` is set and not empty, use its value; otherwise use an empty string.
${VAR:-$HOME}	`/home/user`	If `VAR` is set, use its value; otherwise use the value of `$HOME`.

Example: Using Environment Variable Interpolation in docker-compose.yml

version: '3.8'
services:
  web:
    image: nginx
    environment:
      - PORT=${PORT:-80}
      - DB_HOST=${DB_HOST:-localhost}
      - LOG_LEVEL=${LOG_LEVEL:=info}

Note: Interpolation is processed by the Docker Compose CLI, not by the container's shell. Ensure that environment variables are properly exported in your shell or defined in a .env file.

Warning: Be cautious with nested variable interpolation like ${VAR:-${DEFAULT}}, as it may not be supported in all Docker Compose versions.

7. Using Secrets in Compose

Field	Description	Example
secrets	Defines secrets to be used in the service	`secrets: [db_password]`
file	Path to the secret file on the host	`file: ./db_password.txt`
environment	Maps secret to environment variable	`environment: DB_PASSWORD_FILE=/run/secrets/db_password`

Example: Using Secrets in Docker Compose

version: '3.8'
services:
  web:
    image: nginx
    secrets:
      - db_password
    environment:
      DB_PASSWORD_FILE: /run/secrets/db_password

secrets:
  db_password:
    file: ./db_password.txt

Note: Secrets are mounted as files in the container at /run/secrets/.

8. Using Configs in Compose

Docker configs allow you to manage sensitive data and configuration files for your services without embedding them in the image or exposing them in the command line.

Property	Description	Example
configs	List of configs to be mounted into the service's filesystem	`configs: - source: my-config target: /etc/config.json`
source	Name of the config defined in `configs` section or an external file	`source: app-config`
target	Path inside the container where config is mounted	`target: /app/config.json`
uid/gid	UID/GID to set on the mounted config file	`uid: 1000`

Example: Define and Use a Config

version: '3.8'
services:
  web:
    image: nginx
    configs:
      - app-config
configs:
  app-config:
    file: ./app.json

Note: Configs are mounted as read-only filesystems. Changes to the config file on the host do not automatically propagate to running containers.

9. Setting Resource Limits

Resource Type	Configuration Key	Description	Default Value
Memory	`mem_limit`	Maximum memory the container can use	Unlimited
CPU	`cpus`	Number of CPU cores the container can use	Unlimited
Memory Swap	`mem_reservation`	Amount of memory to reserve for the container	Unlimited
CPU Shares	`cpu_shares`	Relative weight for CPU allocation	1024

Example: Setting Memory Limit

services:
  web:
    image: nginx
    deploy:
      resources:
        limits:
          memory: 512M

Example: Setting CPU Limit

services:
  web:
    image: nginx
    deploy:
      resources:
        limits:
          cpus: '0.5'

Note: Resource limits in Docker Compose are applied per service and can be overridden at runtime using environment variables or command-line arguments.

10. Configuring Restart Policies

Policy	Description	Usage Example
no	Never restart the container if it stops or crashes.	`restart: "no"`
on-failure	Restart the container if it exits with a non-zero exit code.	`restart: "on-failure"`
always	Always restart the container regardless of exit status.	`restart: "always"`
unless-stopped	Restart the container unless it was stopped manually.	`restart: "unless-stopped"`

Example: Using restart policy in docker-compose.yml

services:
  web:
    image: nginx
    restart: "always"
  database:
    image: postgres
    restart: "on-failure"

Note: The restart policy is applied at the service level in Docker Compose.

11. Using Include Directive

Directive	Description	Usage
include	Allows including other compose files into the main docker-compose.yml	`include: <path-to-compose-file>`

Example: Including a Compose File

version: '3.8'
services:
  web:
    build: .
    ports:
      - "8000:8000"
include:
  - ./services/web-compose.yml

Note: The include directive is available from Docker Compose v2.20.0 onwards.

Warning: Ensure that included files are properly validated to avoid configuration conflicts.

Property	Values	Description
include	`string` or `array`	Path to the compose file(s) to include. Can be a single string or an array of strings.

12. Implementing Service Dependencies

Property	Description	Example
depends_on	Defines service dependencies for startup order	`depends_on: db: condition: service_healthy redis: condition: service_started`
condition	Specifies when to consider a service ready	`condition: service_healthy`

Example: Using depends_on with service_healthy

version: '3.8'
services:
  web:
    image: nginx
    depends_on:
      db:
        condition: service_healthy
  db:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: password
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      timeout: 20s
      retries: 3

Note: depends_on ensures startup order but does not wait for services to be ready for connections.

Key Points

depends_on controls service startup order
Use condition: service_healthy for readiness checks
Does not guarantee that dependent services are fully operational