Zero-Downtime Deployment für PHP: Ausfallzeiten vermeiden

Wenn eine Sekunde Ausfallzeit Millionen kostet

Stell dir vor: Du aktualisierst deinen Online-Shop auf PHP, lädst die neue Version per FTP hoch – und plötzlich ist die Seite für 5 Minuten down. Fünf Minuten – das sind 300 Sekunden. In dieser Zeit wechseln 100 potenzielle Kunden zur Konkurrenz, und du verlierst nicht nur Geld, sondern auch deinen guten Ruf. Kommt dir das bekannt vor?

In der heutigen Welt, in der Nutzer keine Fehler verzeihen, ist Zero-Downtime Deployment für PHP-Dienste kein Luxus, sondern eine Notwendigkeit. Aber wie setzt man ein nahtloses Deployment um, wenn der Stack aus PHP, Nginx und mehreren Servern besteht? Lass es uns anhand praktischer Beispiele anschauen.

Warum PHP komplexer ist, als es scheint

Im Gegensatz zu Node.js oder Python unterstützt PHP kein Multithreading im klassischen Sinne. Jede Anfrage wird von einem separaten PHP-FPM-Prozess verarbeitet. Das bringt Einschränkungen mit sich: Du kannst den Code nicht einfach „neustarten“, ohne aktuelle Sessions zu verlieren. Aber genau diese Eigenschaft gibt uns eine Superkraft – die Möglichkeit, den Traffic fließend zwischen verschiedenen Versionen umzuleiten.

Die Hauptprobleme beim PHP-Deployment:

\n
• Verbindungsabbrüche – der Nutzer verliert Formulardaten oder die Session
\n
• Verschmutztes Caching – alter Code liefert Daten aus veraltetem Cache
\n
• Kaputte Migrationen – die neue Datenbankversion ist nicht mit dem alten Code kompatibel
\n

Um diese Fallstricke zu vermeiden, setzen wir auf bewährte Strategien. Und ja, Zero-Downtime Deployment ist keine Magie, sondern ein klarer Plan.

Strategie Nr. 1: Blue-Green Deployment

Der zuverlässigste Weg: Halte zwei vollständige Kopien der Anwendung bereit – „blau“ (aktuell) und „grün“ (neu). Nginx fungiert als Load Balancer.

So sieht es in der Praxis aus

Angenommen, du hast zwei Server: app1.example.com (blue) und app2.example.com (green). Auf beiden läuft PHP-FPM. Aktuell ist blue aktiv. Du deployst die neue Version auf green, testest sie und schaltest dann Nginx auf green um.

Beispiel einer Nginx-Konfiguration für die Umschaltung:

# nginx.conf\nupstream php_backend {\n    # Zuerst ist blue aktiv\n    server app1.example.com:9000 weight=1;  # blue\n    server app2.example.com:9000 weight=0;  # green (deaktiviert)\n}\n\nserver {\n    listen 80;\n    server_name myshop.de;\n\n    location ~ \\.php$ {\n        fastcgi_pass php_backend;\n        include fastcgi_params;\n        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;\n    }\n}\n

Nach dem Deployment auf green änderst du die Gewichte:

# Nach dem Deployment – Traffic umleiten\nupstream php_backend {\n    server app1.example.com:9000 weight=0;  # blue (deaktiviert)\n    server app2.example.com:9000 weight=1;  # green (aktiv)\n}\n

Lade Nginx ohne Ausfallzeit neu: nginx -s reload. Alle bestehenden Verbindungen werden ordentlich beendet, neue Anfragen gehen an green. Zero-Downtime Deployment für PHP – erledigt!

Vor- und Nachteile

Vorteile: Volle Ausfallsicherheit, schnelles Zurücksetzen möglich (einfach die Gewichte zurückändern).
\nNachteile: Doppelte Ressourcen (Server oder Container) erforderlich.

Strategie Nr. 2: Rolling Update (schrittweise Aktualisierung)

Wenn das Budget begrenzt ist, verwende ein Rolling Update. Die Idee: Aktualisiere die PHP-Server nacheinander, ohne die anderen auszuschalten. Nutzer bemerken keine Ausfallzeit, da Nginx die Anfragen an die aktiven Server weiterleitet.

Umsetzung mit PHP-FPM

Angenommen, du hast 3 Server mit PHP-FPM. Wir nehmen sie nacheinander aus der Rotation, aktualisieren den Code und fügen sie wieder hinzu.

Schritt 1: Server vom Load Balancer trennen (Graceful Shutdown):

# Auf dem Server, der aktualisiert wird\nsudo systemctl stop php8.1-fpm\n# Nginx sendet automatisch keine Anfragen mehr an diesen Server, da er nicht erreichbar ist\n

Schritt 2: Code aktualisieren (per git pull, rsync oder Docker).

Schritt 3: PHP-FPM wieder starten:

sudo