Ein Setup aus der Praxis

App, Datenbank, Mail

Ein typisches Web-Projekt braucht mehr als einen Container: die Anwendung, eine Datenbank und oft einen Mail-Catcher zum Testen. So sieht ein alltagstaugliches Compose-Setup aus.

Die compose.yaml

services:
  app:
    build: .                      # eigenes Image aus dem Dockerfile
    ports:
      - "8080:80"
    volumes:
      - ./:/var/www/html          # Code live einspiegeln
    depends_on:
      - db

  db:
    image: mariadb:11
    environment:
      MARIADB_ROOT_PASSWORD: secret
      MARIADB_DATABASE: app
    volumes:
      - db-data:/var/lib/mysql    # Daten überleben Neustarts

  mail:
    image: axllent/mailpit
    ports:
      - "8025:8025"               # Weboberfläche für Test-Mails

volumes:
  db-data:

Was hier passiert

Baustein	Zweck
`build: .`	baut das App-Image aus dem lokalen `Dockerfile`
`volumes: ./:/…`	spiegelt den Code in den Container – Änderungen sofort sichtbar
`depends_on`	startet `db` vor `app`
`db-data`	benanntes Volume für persistente Datenbankdaten
`mailpit`	fängt ausgehende Mails ab, zeigt sie im Browser

Loslegen

docker compose up -d
# App:        http://localhost:8080
# Mail-UI:    http://localhost:8025

Praxis-Tipp: Der Code liegt per Bind-Mount im Container, die Datenbank in einem benannten Volume. So bleibt der Code am Host editierbar und die Daten trotzdem persistent – die typische Trennung im Dev-Alltag.

Dieser Unterschied – Bind-Mount vs. benanntes Volume – lohnt einen genaueren Blick.