Docker Compose – Multi-Service Setups mit Beispielen

Mit Docker Compose startest du mehrere Services als ein Projekt. Statt Container einzeln zu tippen, beschreibst du alles in einer docker-compose.yml und lässt Compose sich um Netzwerke, Volumes, Umgebungsvariablen und Startreihenfolgen kümmern. In diesem Guide bekommst du verständliche Beispiele für typische Multi-Service Setups und lernst die wichtigsten Optionen, damit deine Stacks stabil und wartbar laufen.

Was Docker Compose für dich löst

Compose definiert deine Umgebung deklarativ. Du legst fest, welche Images laufen, welche Ports offen sind, welche Volumes Daten behalten und wie Services miteinander sprechen. Mit docker compose up -d startet alles, mit docker compose down stoppst du sauber. Das spart Zeit und verhindert Konfigurationsdrift.

Die Bausteine kurz erklärt

Ein Service ist ein Container mit Konfiguration. Networks verbinden Services isoliert. Volumes speichern persistente Daten. env_file und environment liefern Secrets und Konfiguration. depends_on und healthcheck regeln Startreihenfolge und Gesundheit. Mit profiles steuerst du optionale Teile deines Stacks.

Beispiel 1 – WordPress mit Datenbank und persistenten Daten

Ein klassischer Webstack mit WordPress und MariaDB. Du siehst Volumes, Umgebungsvariablen, Netzwerk und Healthchecks.

services:
  db:
    image: mariadb:11
    environment:
      - MARIADB_DATABASE=wp
      - MARIADB_USER=wp
      - MARIADB_PASSWORD=wpsecret
      - MARIADB_ROOT_PASSWORD=rootsecret
    volumes:
      - dbdata:/var/lib/mysql
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 10s
      timeout: 5s
      retries: 5

  wordpress:
    image: wordpress:php8.2-apache
    depends_on:
      db:
        condition: service_healthy
    environment:
      - WORDPRESS_DB_HOST=db:3306
      - WORDPRESS_DB_USER=wp
      - WORDPRESS_DB_PASSWORD=wpsecret
      - WORDPRESS_DB_NAME=wp
    ports:
      - "8080:80"
    volumes:
      - wpdata:/var/www/html

volumes:
  dbdata:
  wpdata:

Warum gut: Volumes halten Daten zwischen Neustarts, healthcheck sichert die Startreihenfolge, die Ports machen WordPress auf http://localhost:8080 erreichbar.

Beispiel 2 – FastAPI mit Redis Cache für schnelle Antworten

Ein leichter API Stack mit FastAPI und Redis. Du bindest lokalen Code ein und bekommst schnelle Iterationen.

services:
  api:
    image: tiangolo/uvicorn-gunicorn-fastapi:python3.11
    volumes:
      - ./app:/app
    environment:
      - REDIS_HOST=redis
    ports:
      - "8000:80"
    depends_on:
      - redis

  redis:
    image: redis:7
    command: ["redis-server", "--save", "", "--appendonly", "no"]

Minimaler Code in ./app/main.py:

from fastapi import FastAPI
import redis, os
r = redis.Redis(host=os.getenv("REDIS_HOST","redis"), port=6379, decode_responses=True)
app = FastAPI()
@app.get("/hit")
def hit(): return {"hits": r.incr("hits")}

Warum gut: Code-Mount erlaubt schnelles Hot-Reloading, Redis liefert Zähler und Cache ohne Setup-Hürde. Aufruf: http://localhost:8000/hit.

Beispiel 3 – Postgres mit pgAdmin für Administration

Datenbank plus GUI zur Verwaltung. Du lernst Credentials per env_file zu kapseln.

services:
  db:
    image: postgres:16
    env_file: .env
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER}"]
      interval: 10s
      timeout: 5s
      retries: 5

  pgadmin:
    image: dpage/pgadmin4
    env_file: .env
    depends_on:
      db:
        condition: service_healthy
    ports:
      - "5050:80"
    volumes:
      - pgadmindata:/var/lib/pgadmin

volumes:
  pgdata:
  pgadmindata:

.env Beispiel:

POSTGRES_USER=demo
POSTGRES_PASSWORD=demopw
POSTGRES_DB=demo
PGADMIN_DEFAULT_EMAIL=admin@example.com
PGADMIN_DEFAULT_PASSWORD=adminpw

Warum gut: env_file hält Passwörter aus der YAML heraus, Volumes bewahren Daten, pgAdmin macht die DB klickbar erreichbar auf http://localhost:5050.

Nützliche Optionen, die du kennen solltest

Netzwerke bewusst nutzen

Compose erstellt automatisch ein Default-Netzwerk. Für klarere Trennung definierst du eigene Netzwerke und weist Services gezielt zu. So bleiben etwa Datenbank und Admin-GUI intern, während nur Web Ports nach außen öffnet.

Restart-Policy und Ressourcen

Mit restart: unless-stopped starten Services nach Reboot automatisch. Über deploy.resources oder limits setzt du CPU und RAM Grenzen – nützlich auf kleinen Hosts.

Logs und Diagnose

Mit docker compose logs -f servicename verfolgst du Live-Logs. docker compose ps zeigt Status, docker compose exec öffnet eine Shell im Container. So findest du Fehler schnell.

Häufige Fehler und wie du sie vermeidest

Wenn ein Webservice nicht erreichbar ist, prüfe ports und Container-Port. Stimmen 80 im Container und 8080:80 außen. Bleibt ein Service gelb, fehlt oft ein healthcheck oder depends_on. Leere Daten nach Neustart weisen auf fehlende Volumes hin. Harte Passwörter in der YAML sind ein Risiko – nutze .env oder Secrets. Zu viele latest Tags erschweren Reproduzierbarkeit – pinne Versionen.

Best Practices für stabile Stacks

Nutze sprechende Servicenamen, benannte Volumes und ein README im Projekt. Halte .env unter Versionskontrolle mit Musterwerten (.env.example), aber nicht deine echten Secrets. Plane Backups für Volumes und teste docker compose down -v nur in Entwicklungsumgebungen. Teile große Stacks über profiles in dev und prod auf. Dokumentiere Standardports und Login-Daten kurz im Repo.

Fazit

Mit Docker Compose orchestrierst du mehrere Services schnell und nachvollziehbar. Die Beispiele zeigen, wie du Web, Cache und Datenbank mit Netzwerken, Volumes, env_file, depends_on und healthcheck sauber verbindest. Starte mit einem kleinen Setup, pinne Versionen, halte Passwörter aus der YAML heraus und beobachte Logs aktiv – so bleiben deine Multi-Service Setups stabil und leicht zu pflegen.