Posts

Your development Compose file isn’t your CI Compose file. A dedicated CI configuration ensures tests run against a clean, seeded database with no leftover state. The development stack Take a typical full-stack project like dockersamples/sbx-quickstart — a FastAPI backend with a Next.js frontend and PostgreSQL: # compose.yml services: backend: build: ./backend ports: - "8000:8000" environment: DATABASE_URL: postgresql://postgres:postgres@db:5432/devboard depends_on: db: condition: service_healthy frontend: build: ./frontend ports: - "3000:3000" db: image: postgres:16 environment: POSTGRES_PASSWORD: postgres POSTGRES_DB: devboard volumes: - db-data:/var/lib/postgresql/data healthcheck: test: ["CMD", "pg_isready"] interval: 5s retries: 5 volumes: db-data: Adding a CI override Create a compose.ci.yml that adapts the stack for testing: ...

docker compose up -d starts services in the background, but it returns immediately — before services are actually ready. --wait solves this by blocking until all services are healthy. The problem Without --wait, you often end up with fragile sleep-based scripts: # Fragile: how long is enough? docker compose up -d sleep 10 npm test The solution docker compose up --wait npm test --wait starts services in detached mode and blocks until every service with a healthcheck reports healthy. If a service fails to become healthy, the command exits with a non-zero status. ...

Running ML models, video processing, or any GPU-accelerated workload? Compose lets you reserve GPU devices for specific services. Basic GPU access Give a service access to all available GPUs: services: ml-training: image: pytorch/pytorch deploy: resources: reservations: devices: - driver: nvidia count: all capabilities: [gpu] Limiting GPU count Reserve a specific number of GPUs instead of all: services: inference: image: mymodel:latest deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu] Selecting specific GPUs by ID Target specific GPU devices when you have multiple: ...

Compose can orchestrate more than just Linux containers. By combining platform and runtime, you can run traditional containers alongside WebAssembly (Wasm) modules in the same stack. The platform key The platform key at service level tells Docker which platform the service targets: services: # Regular Linux container (default) web: image: nginx platform: linux/amd64 # WebAssembly module api: image: wasmedge/example-wasi-http runtime: io.containerd.wasmedge.v1 Mixing Linux and Wasm services Here’s a practical stack where a traditional nginx reverse proxy sits in front of a Wasm-based API: ...

When using dynamic port mapping or multiple services, it’s not always obvious which host port maps to which container port. docker compose port tells you exactly. Basic usage # Which host port maps to container port 80 on the web service? docker compose port web 80 # Output: 0.0.0.0:8080 Why dynamic ports matter When you let Docker assign ports automatically, the host port changes on every docker compose up: services: web: image: nginx ports: - "80" # Dynamic host port, container port 80 docker compose port web 80 # Output: 0.0.0.0:55432 (assigned dynamically) This is common in CI or when running multiple instances of the same project. ...