Laravel in Produktion: Docker Compose richtig strukturieren

Die Entwicklung einer Laravel-Anwendung endet selten mit einem einzigen Docker-Container. In der Praxis treffen verschiedene Anforderungen aufeinander: Webserver, PHP-Laufzeitumgebung, Datenbanken, Caching-Mechanismen und Hintergrundprozesse. Viele Docker-Setups vereinfachen diese Komplexität, doch genau das führt in der Produktion oft zu Problemen.

Warum einfache Docker-Setups in der Produktion scheitern

Typische Docker-Compose-Beispiele zeigen häufig nur einen Container für die Anwendung, ergänzt um eine Datenbank. Diese Struktur mag für Entwicklungszwecke ausreichen, doch in der Produktionsumgebung entstehen dadurch schnell folgende Herausforderungen:

• Begrenzte Beobachtbarkeit: Fehlende Logging- und Monitoring-Möglichkeiten erschweren die Fehlersuche.
• Komplexe Debugging-Prozesse: Fehler in gemischten Containern sind schwer zu isolieren.
• Fehlende Skalierbarkeit: Jede Komponente (PHP, Datenbank, Cache) benötigt unterschiedliche Ressourcen.
• Instabile Bereitstellungen: Änderungen in einem Container können unbeabsichtigte Auswirkungen auf andere haben.

Solche Setups mögen zunächst funktionieren, doch sie bieten keine Grundlage für eine zuverlässige Produktionsumgebung.

Der Schlüssel: Ein Container, eine Verantwortung

Nach jahrelanger Erfahrung mit Docker-Architekturen hat sich ein Grundsatz bewährt:

Jeder Container sollte genau eine Aufgabe erfüllen.

Diese Herangehensweise mag zunächst umständlich erscheinen, doch sie transformiert die Architektur grundlegend. Jeder Dienst – ob Webserver, PHP-FPM, Datenbank oder Hintergrundprozesse – läuft in einem eigenen Container. Dadurch entsteht eine klare Trennung der Verantwortlichkeiten.

Eine Produktionsbereite Docker-Compose-Struktur

Die folgende Architektur hat sich in echten Produktionsumgebungen bewährt:

• `app`: Enthält die PHP-FPM-Laufzeitumgebung für die Laravel-Anwendung.
• `web`: Nginx als Reverse-Proxy, der statische Dateien bedient und Anfragen an die PHP-Container weiterleitet.
• `db`: PostgreSQL als relationale Datenbank für die Anwendung.
• `redis`: Wird sowohl für Caching als auch als Warteschlange (Queue) genutzt.
• `horizon`: Laravel Horizon für die Verwaltung von Hintergrundprozessen.
• `scheduler`: Führt geplante Laravel-Jobs aus, die regelmäßig Aufgaben wie Datenbereinigung oder Berichte verarbeiten.

Jeder dieser Container ist isoliert und kann unabhängig voneinander skaliert oder neu gestartet werden. Fällt ein Dienst aus, bleiben die anderen funktionsfähig – ein entscheidender Vorteil für die Stabilität der Anwendung.

Häufiger Fehler: Statische Dateien und Volumes

Ein weit verbreiteter Fehler betrifft die Handhabung statischer Dateien, insbesondere im public-Verzeichnis. Viele Setups mounten das Verzeichnis direkt in einen Container:

volumes:
  - public:/var/www/app/public

Auf den ersten Blick scheint dies unproblematisch. Doch in der Praxis führt dies zu mehreren Problemen:

• Veraltete Dateien: Alte Versionen statischer Dateien (CSS, JavaScript) bleiben im Volume erhalten, obwohl die Anwendung aktualisiert wurde.
• Inkonsistente Bereitstellungen: Neue Builds werden nicht korrekt in den Container übertragen.
• Schwierige Fehlerbehebung: Die Ursache für fehlerhafte Darstellungen ist oft schwer zu identifizieren.

Eine bessere Lösung besteht darin, statische Dateien während des Build-Prozesses zu generieren und als separate Artefakte bereitzustellen.

Bootstrap vs. Laufzeit: Trennung von Initialisierung und Betrieb

Ein weiterer kritischer Punkt betrifft die Ausführung von Datenbankmigrationen und Initialisierungsschritten. Viele Setups führen diese Aufgaben innerhalb des Hauptcontainers aus:

php artisan migrate

Doch in einer Produktionsumgebung sind solche Operationen besser in separaten Containern oder sogar in CI/CD-Pipelines aufgehoben. Der Grund:

• Laufzeitcontainer sollten ausschließlich langlebige Prozesse ausführen.
• Bootstrap-Container sind für einmalige Aufgaben wie Migrationen oder Setup-Skripte zuständig.

Diese Trennung stellt sicher, dass Produktionssysteme stabiler und vorhersehbarer laufen.

Die Vorteile einer klar strukturierten Architektur

Die Entscheidung für eine Container-Architektur mit klaren Verantwortlichkeiten bringt mehrere entscheidende Vorteile mit sich:

• Bessere Isolation: Jeder Dienst läuft in seiner eigenen Umgebung und ist vor Störungen anderer Dienste geschützt.
• Einfacheres Debugging: Fehler lassen sich gezielt einem Container zuordnen, was die Fehlersuche beschleunigt.
• Sicherere Bereitstellungen: Änderungen in einem Container wirken sich nicht auf andere aus, was die Stabilität erhöht.
• Echte Skalierbarkeit: Ressourcen können gezielt dort eingesetzt werden, wo sie benötigt werden – ob für PHP-Container, Datenbanken oder Caching-Mechanismen.

Diese Struktur mag komplexer erscheinen als einfache Setups, doch sie ist die Grundlage für zuverlässige und skalierbare Produktionsumgebungen.

Nächste Schritte: Von der Theorie zur Praxis

Dieser Artikel konzentriert sich bewusst auf die grundlegenden Konzepte einer Produktionsarchitektur. Wer tiefer in die Materie einsteigen möchte, findet eine detaillierte Anleitung mit vollständigen Docker-Compose-Konfigurationen, Volumes, Healthchecks und weiteren Best Practices in der ausführlichen Anleitung auf FilamentMastery.

Dies ist Teil einer Serie zu Laravel- und Filament-Setups in der Produktion. Die weiteren Artikel behandeln Themen wie:

• Multi-Stage-Docker-Builds für optimierte Images
• Automatisierte CI/CD-Pipelines
• Strategien für sichere Bereitstellungen

Falls Sie bereits ähnliche Setups in der Produktion einsetzen, würde ich mich freuen, von Ihren Erfahrungen zu hören. Wie strukturieren Sie Ihre Docker-Container? Welche Herausforderungen sind Ihnen begegnet?