Docker Compose patterns for multi-service research applications including web APIs, databases, message queues, Jupyter notebooks, and development workflows.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Docker Compose patterns for multi-service research applications including web APIs, databases, message queues, Jupyter notebooks, and development workflows.
A comprehensive guide to orchestrating multi-service research applications with Docker Compose. This skill covers compose file structure, service patterns for scientific workloads, environment management, networking, volume strategies, and development workflow optimization. Whether you are standing up a Jupyter-backed research stack or deploying a production API with a database and cache layer, the patterns and templates here will get you running quickly and correctly.
Development override with live reload, debug ports, relaxed health checks
Quick Reference Card
Compose File Structure
# Top-level keys in a compose.ymlservices:# Container definitions (required)networks:# Custom network definitionsvolumes:# Named volume definitionsconfigs:# Configuration objects (Swarm / recent Compose)secrets:# Sensitive data references
Key Directives
# Lifecycle
docker compose up -d # Start all services detached
docker compose down # Stop and remove containers
docker compose down -v # Stop and remove containers + volumes# Multi-file
docker compose -f compose.yml -f compose.override.yml up -d
# Profiles
docker compose --profile debug up -d # Start services tagged with "debug"# Logs and status
docker compose logs -f api # Follow logs for a service
docker compose ps # List running services
docker compose top # Show running processes# Exec and run
docker compose exec api bash # Shell into running container
docker compose run --rm api pytest # One-off command in new container# Build
docker compose build # Build all images
docker compose build --no-cache api # Rebuild without cache# Watch (development)
docker compose watch # Auto-sync / rebuild on file changes
When to Use
Standing up a multi-service research application (API + database + cache)
Running JupyterLab alongside backend services for interactive analysis
Creating reproducible development environments for a team
Prototyping microservice architectures for scientific pipelines
Managing worker queues for batch processing or ML training jobs
Providing a single-command setup for contributors (docker compose up)
Isolating services with custom networks and persistent volumes
Compose File Structure
A compose file defines five top-level objects. Only services is required.
services
Each service maps to one container. Key fields:
services:api:image:python:3.12-slim# Use a pre-built imagebuild:./api# Or build from a Dockerfileports:-"8000:8000"# HOST:CONTAINERenvironment:-DATABASE_URL=postgresql://user:pass@db:5432/appvolumes:-./src:/app/src# Bind mount for developmentdepends_on:db:condition:service_healthy# Wait for dependency health checkrestart:unless-stopped
networks
networks:backend:driver:bridge# Default; most commonfrontend:driver:bridge
volumes
volumes:pg-data:# Named volume (managed by Docker)redis-data:
configs
configs:app-config:file:./config/app.yml# Injected into containers
secrets
secrets:db-password:file:./secrets/db-password.txt# Mounted at /run/secrets/<name>
Service Patterns
Web App + Database
The classic pattern: a Python API backed by PostgreSQL and optionally Redis for caching or task queues.
A JupyterLab notebook server connected to an API and database for interactive research. Notebooks are bind-mounted so work persists outside the container.
Reference variables in compose files with ${VAR} syntax:
services:db:image:postgres:16-alpineenvironment:POSTGRES_USER:${POSTGRES_USER}POSTGRES_PASSWORD:${POSTGRES_PASSWORD}POSTGRES_DB:${POSTGRES_DB}ports:-"${DB_PORT:-5432}:5432"# Default value with :-
Multiple .env Files
services:api:env_file:-.env# Shared variables-.env.local# Local overrides (git-ignored)
Development vs Production
Use the override pattern to keep a clean base file and layer development-specific settings on top.
project/
├── compose.yml # Base (production-like)
├── compose.override.yml # Auto-loaded dev overrides
├── compose.prod.yml # Explicit production overrides
└── .env
Tag services so they only start when a profile is explicitly activated:
services:api:# No profile — always startsdebug-tools:image:nicolaka/netshootprofiles:-debug# Only starts with --profile debugmonitoring:image:grafana/grafanaprofiles:-monitoring
docker compose up -d # api only
docker compose --profile debug up -d # api + debug-tools
docker compose --profile debug --profile monitoring up -d # all three
Common Mistakes
Using depends_on without condition: service_healthy — The service starts before the dependency is actually ready to accept connections.
Storing secrets in environment blocks — Use Docker secrets or .env files that are git-ignored instead.
Not using named volumes for database data — Bind mounts can cause permission issues; named volumes are portable and Docker-managed.
Hardcoding ports — Use variable substitution (${API_PORT:-8000}:8000) so team members can avoid conflicts.
Missing restart policy — Services will not restart after a crash unless you set restart: unless-stopped or restart: on-failure.
Forgetting --rm with docker compose run — One-off containers accumulate and waste disk space.
Bind-mounting over container directories with important content — The host directory replaces the container directory entirely, hiding installed packages or built assets.
Running containers as root when not necessary — Set user: in the service or use a non-root base image.
Best Practices
Pin image tags — Use postgres:16-alpine, not postgres:latest.
Use health checks on every stateful service — Databases, caches, and message brokers should all have health checks.
Separate concerns with networks — Only expose services that need to communicate with each other.
Use the override pattern — Keep compose.yml production-like; layer dev settings with compose.override.yml.
Parameterize with .env — Avoid hardcoded values; use variable substitution for ports, credentials, and image tags.
Prefer named volumes over bind mounts for data — Named volumes are faster on macOS/Windows and avoid permission issues.
Use profiles for optional services — Monitoring, debugging, and admin tools should not start by default.
Add restart: unless-stopped — Ensures services recover from crashes without restarting after manual stops.
Use multi-stage builds — Keep production images small; use a development target for tooling.
Document the stack — Add comments in the compose file explaining non-obvious configuration.
