Compose Service

services:
  # Service 1: Die Datenbank
  db:
    image: postgres:15
    environment:
      POSTGRES_PASSWORD: secret

  # Service 2: Die App
  web:
    build: .
    depends_on:
      - db

Hier gibt es zwei Services: db und web. Du kannst sie einzeln steuern: docker compose restart web. Oder zusammen: docker compose up.

Praxisroutine

In der Praxis lernst du Compose Service, indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.

Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.

1. Scaling & Replicas

Ein Service ist nicht gleich ein Container. docker compose up --scale web=3. Jetzt starten 3 Instanzen des Web-Containers. Docker Load Balancer (internes DNS) verteilt Anfragen an web automatisch auf die 3 IPs (Round Robin). In der YAML: deploy: replicas: 3 (Version 3 Syntax).

2. Service-to-Service Networking

Services finden sich per DNS. Der Service web kann einfach postgres://db:5432 aufrufen. Docker löst den Hostnamen db automatisch zur internen IP des Datenbank-Containers auf. Du musst niemals IPs hardcoden. Voraussetzung: Beide sind im gleichen Netzwerk (Standardmäßig erstellt Compose ein default Netzwerk).

3. Restart Policies & Dependencies

Mit depends_on legst du die Startreihenfolge fest. depends_on: condition: service_healthy. Das ist extrem mächtig: "Starte Web erst, wenn die Datenbank wirklich bereit ist (Healthcheck OK), nicht nur wenn der Container läuft." Verhindert "Connection Refused" Fehler beim Booten.

1. Volume Mounts vs. Bind Mounts

In der Service-Definition bestimmst du, wie Daten den Container-Tod überleben.

• Bind Mount (./data:/app/data): Mappt einen harten, absoluten Pfad deines Laptops direkt in den Container. Für Entwickler im Web-Backend unersetzlich, da jede Code-Änderung in der IDE sofort, ohne Image-Rebuild, Live im laufenden Service reflektiert wird.
• Named Volumes (db_data:/var/lib/postgresql/data): Docker verwaltet den physischen Ort auf der Host-Festplatte transparent selbst. Das ist der Industrie-Standard für Datenbank-Services, weil Docker sich um Dateirechte (Permission-Hürden in Linux UID/GID) und Isolation kümmert.

2. The Init Process (PID 1) Zombie Problem

Solltest du im Service ein simples Shell-Script via command: ./start.sh booten, wird dieses Konstrukt in Linux oft zur PID 1 (Prozess-ID 1) innerhalb der Isolation. PID 1 in Linux hat extrem mächtige Spezialeigenschaften: Es ist der Einzige, der SIGTERM Kill-Signale igorieren kann. Und es ist für das Säubern (Reaping) toter Kindprozesse (Zombie Processes) verantwortlich. Stirbt eine App in deinem Compose-Service fehlerhaft ab, leakt sie RAM mit Zombies, da dein dummes ./start.sh überhaupt nicht weiß, wie man Zombies beerdigt. Abhilfe: Die Flag init: true in der Docker Compose File ergänzen. Sie spannt einen winzigen C-Init-Prozess (Tini) vor deine App, der PID 1 übernimmt und Zombies perfekt wegschaufelt.

3. Compose Watch (Live Synchronization)

Seit neueren Docker Versionen hat Compose mit watch ein revolutionäres Konzept für Frontend/Backend-Iterationen erhalten, ohne den RAM-fressenden Ballast komplexer Webpack-Bindings und Inotify-Loops. In der .yml unter dem Service definierst du Verzeichnisse, die überwacht werden sollen. Du kannst definieren: Wenn sich .css ändert, synchronisiere sie hart und sofort hinein (action: sync). Wenn sich die package.json (Requirements) ändert, nützt Sync nichts. Hier löst du action: rebuild aus, was blitzartig einen Multi-Stage Partial-Buld triggert, um Abhängigkeiten des Services lokal frisch im Image neu zu generieren.