PHP-FPM im Docker-Umfeld: Was wirklich zählt
PHP-FPM ist heute die Standardlösung für den produktiven Betrieb von PHP-Anwendungen, vor allem in Docker-Containern. Doch nicht jede PHP-FPM-Installation taugt für den produktiven Einsatz. Häufig sind die Standard-Images unzureichend gehärtet, enthalten ungenutzte Extensions oder unsaubere Konfigurationen. Für erfahrene Entwickler und Agenturen ist es deshalb entscheidend, PHP-FPM-Images aus dem eigenen Build-Prozess zu liefern – maßgeschneidert, schlank und sicher.
In der Praxis zeigt sich oft: Entwickler übernehmen das Standard-PHP-FPM-Image von Docker Hub und packen Composer beim Containerstart drauf. Das funktioniert, führt aber zu unsauberem Setup, längeren Startzeiten und Schwierigkeiten bei Debugging oder Security-Audits. Stattdessen ist eine saubere Trennung zwischen Build- und Runtime-Phase erfolgskritisch.
Composer im Build-Prozess: Warum Installationen im Containerstart vermieden werden sollten
Composer ist unverzichtbar, wird aber oft falsch eingesetzt. Ein häufiger Fehler: Composer wird bei jedem Containerstart ausgeführt. Das kostet Zeit, erzeugt Instabilität und macht Skalierung schwer. Besser ist es, Composer im Build des Docker-Images einmalig laufen zu lassen. So sind alle Abhängigkeiten bereits vorinstalliert, der Container startet schnell und konsistent.
Das bedeutet konkret:
• Im Dockerfile wird Composer installiert oder ein fertiges Image mit Composer als Basis genutzt.
• Danach folgen die Composer-Installationen inklusive Optimierung für Production (z.B. --no-dev, --optimize-autoloader).
• Native PHP-Extensions, die die Dependencies brauchen, werden parallel installiert und aktiviert.
• Am Ende steht ein schlankes, produktionsfertiges Image, das ohne weitere Composer-Aktionen auskommt.
Diese Trennung verbessert nicht nur die Performance, sondern macht auch Security-Checks und Upgrades planbar. Es ist leichter, Composer-Vulnerabilities durch kontrollierte Builds zu erkennen und zu beheben.
Native PHP-Extensions: Wann lohnen sie sich wirklich?
Nicht jede Extension ist sinnvoll – gerade in Docker-Produktionsimages steigt mit jeder Extension die Angriffsfläche und die Komplexität. Die wichtigste Frage ist stets: Braucht das Projekt die Extension wirklich?
Aus eigener Erfahrung ist eine zu großzügige Auswahl der Extensions ein häufiger Fehler. Man installiert schnell alles, was potentiell helfen könnte, nur um am Ende nicht alle Funktionen zu nutzen. Das führt zu größeren Images, längeren Buildzeiten und erhöhtem Wartungsaufwand.
Typische Extensions, die oft gebraucht werden, sind z.B. intl, gd, pdo_mysql, redis und opcache. Andere, wie xdebug, gehören ausschließlich in Entwicklungsszenarien. In der Production sind Debug-Extension und Tools wie xdebug nicht nur unnötig, sondern ein Sicherheitsrisiko.
Wer Native Extensions nutzen will, sollte sie möglichst im Build automatisiert kompilieren und nur die wirklich nötigen aktivieren. Es ist hilfreich, sich auf schlanke Basisimages mit minimalem Footprint zu fokussieren und Extensions modular zu verwalten.
Security-Härtung von PHP-FPM-Containern: Mehr als nur ein schickes Image
Security ist kein Feature, sondern ein Prozess. Für PHP-FPM in Docker heißt das: Ein standardisiertes Image bringt nicht automatisch Sicherheit. Es braucht Härtung:
- Minimale Rechte: Container sollten mit so wenig Rechten wie möglich laufen. Nutzerwechsel weg von root ist Pflicht.
- Konfigurationshärte: PHP-Einstellungen wie disable_functions, error_reporting oder open_basedir müssen restriktiv gesetzt werden.
- Entfernen unnötiger Tools: Entwicklungswerkzeuge und Debugger gehören nicht ins Produktivimage.
- Netzwerk- und Dateisystemzugriffe einschränken: So wenig Volumes und Ports wie nötig, strikte Zugriffsrechte.
- Updates und Patches: PHP-Versionen und Extensions regelmäßig aktualisieren – im besten Fall automatisiert.
- Überwachung im Betrieb: Logs, Metriken und Auslastung müssen im Auge behalten werden, um mögliche Angriffe zu erkennen.
Aus meiner Erfahrung sind viele Probleme vermeidbar, wenn Härtung schon im Build-Prozess beginnt. Der Dockerfile ist der beste Ort, um konsequent aufzuräumen, Rechte zu setzen und unnötige Komponenten zu entfernen.
Meine Einschätzung: PHP-FPM in Docker ist kein Selbstläufer
In über 15 Jahren Webentwicklung habe ich oft gesehen, wie Teams an PHP-Docker-Containern scheiterten, weil das Thema zu oberflächlich behandelt wurde. Standardimages, Composer zur Laufzeit, zu viele Extensions und fehlende Härtung führen zu instabilen und unsicheren Deployments.
Ein Investment in einen sauberen Build-Prozess zahlt sich aus. Die Container starten schneller, sind leichter wartbar und sicherer. Automatisierung beim Extension-Build und Composer-Installationen sorgt für reproduzierbare Umgebungen und planbare Updates.
Natürlich kostet die initiale Einrichtung Zeit, aber sie vermeidet teure Nacharbeiten bei Problemen in Produktion. Für Agenturen bedeutet das zudem weniger Supportaufwand und höhere Kundenzufriedenheit.
Wer PHP-FPM in Docker produktiv betreibt, sollte daher nicht nur an den Code denken, sondern die Infrastruktur und Build-Pipelines als integralen Teil der Anwendung verstehen.
Weiterführend in dieser Serie
Für tiefergehende Informationen zur PHP 8 Migration ohne Stillstand und zur Verwendung von Native PHP-Extensions im Build-Prozess bieten sich folgende Artikel an:
- PHP 8 Migration ohne Stillstand
- Native PHP-Extensions 2026: Wann lohnen sie sich wirklich?
Fazit
Produktionstaugliche PHP-FPM-Container brauchen eine saubere Trennung zwischen Build und Runtime. Composer gehört in den Build, Native Extensions sollten gezielt und sparsam eingesetzt werden. Die Production-Härtung ist kein Nice-to-have, sondern Pflicht. Wer diese Punkte vernachlässigt, riskiert Performance-Einbußen, Sicherheitslücken und unnötigen Wartungsaufwand.
Mit gezieltem Aufwand im Build-Prozess entstehen schlanke, sichere und wartbare PHP-Docker-Images, die sich im Alltag bewähren und echten Mehrwert bieten.
bye
mo