Schweis Logo
Schweis
Zurück zum Blog
DevOps 2026-01-30

So optimieren Sie Docker-Container für PHP-Hochleistungsanwendungen

So optimieren Sie Docker-Container für PHP-Hochleistungsanwendungen

Containerisierung richtig gemacht

Docker hat die Bereitstellung revolutioniert, aber das bloße Einpacken einer langsamen App in einen Container ergibt nur einen langsamen Container. Bei Schweis behandeln wir unser `Dockerfile` als einen kritischen Teil unserer Codebasis. Die Optimierung von Docker für PHP ist nicht nur eine Frage der Dateigröße; es geht um Laufzeiteffizienz, Sicherheit und Build-Geschwindigkeit.

1. Wahl des Basis-Images

Wir beginnen immer mit `alpine`. Das Image `php:8.3-fpm-alpine` ist unser Goldstandard. Es bietet eine minimale Angriffsfläche. Weniger Bibliotheken bedeuten weniger Schwachstellen (CVEs). Es zwingt uns dazu, explizit festzulegen, welche Bibliotheken wir installieren, und verhindert so, dass "Bloatware" in die Produktion gelangt.

2. OpCache-Tuning

PHP ist eine interpretierte Sprache, was bedeutet, dass das Kompilieren von Skripten bei jeder Anfrage verschwendete CPU-Zyklen sind. In unseren Container-Konfigurationen tunen wir OpCache aggressiv:


opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60
opcache.fast_shutdown=1
opcache.enable_cli=1

Diese Konfiguration stellt sicher, dass unser Anwendungscode einmal kompiliert wird und im Speicher bleibt. Für eine leselastige Seite wie einen Blog reduziert dies die Antwortzeiten auf Beinahe-Statik-Dateigeschwindigkeiten.

3. Multi-Stage Builds & Layer Caching

Wir setzen auf Multi-Stage Builds, um unsere Produktions-Images sauber zu halten. Build-Tools und Entwicklungsabhängigkeiten leben in einer `builder`-Etappe und schaffen es nie in das finale Image. Wir ordnen auch unsere `Dockerfile`-Befehle sorgfältig. Das Kopieren von Abhängigkeitsdateien vor dem Quellcode stellt sicher, dass der Layer-Cache von Docker nicht alles neu installiert, wenn wir nur eine Zeile CSS ändern.

Sicherheitskontexte

Wir führen Container niemals als Root aus. Unsere Dockerfiles wechseln explizit zu `www-data` oder einem benutzerdefinierten User. Wir verwenden nach Möglichkeit schreibgeschützte Dateisysteme und entziehen alle Berechtigungen (capabilities) bis auf die unbedingt notwendigen. In einer Hochsicherheitsumgebung ist die Containergrenze die letzte Verteidigungslinie; wir machen sie zur Festung.

Schweis Team

Schweis Project

Collective Intelligence