Von PHP 5.5 zur aktuellen PHP-Laufzeit migrieren

Auf dieser Seite finden Sie eine Anleitung für die Migration von der ersten zur zweiten Generation der PHP-Laufzeiten. Informationen zum Upgrade Ihrer Anwendung der zweiten Generation auf die aktuelle unterstützte PHP-Version finden Sie unter Vorhandene Anwendung aktualisieren.

PHP 5 hat am 30. Januar 2024 das Ende des Supports erreicht. Ihre vorhandenen PHP 5-Anwendungen werden weiterhin ausgeführt und erhalten Traffic. App Engine kann die erneute Bereitstellung von Anwendungen, die Laufzeiten verwenden, jedoch nach dem Enddatum des Supports blockieren. Wir empfehlen Ihnen, unter Berücksichtigung der Richtlinien auf dieser Seite zur aktuelle unterstützten PHP-Laufzeit zu migrieren.

Die Migration zu einer unterstützten PHP-Laufzeit der zweiten Generation bietet Ihnen die Möglichkeit, aktuelle Sprachfunktionen zu verwenden und mit idiomatischem Code einfacher portable Apps zu erstellen.

Kompatibilitätsprobleme zwischen PHP 5.5 und den PHP-Laufzeiten der zweiten Generation

Die offizielle PHP-Dokumentation enthält Informationen zur Migration von verschiedenen PHP-Versionen:

Wichtige Unterschiede zwischen PHP 5.5 und den PHP-Laufzeiten der zweiten Generation

Im Folgenden finden Sie eine Zusammenfassung der Unterschiede zwischen den PHP 5.5- und der PHP-Laufzeit der zweiten Generation in der App Engine-Standardumgebung:

Unterschiede bei der Arbeitsspeichernutzung

Laufzeiten der zweiten Generation haben eine höhere Referenz für die Arbeitsspeichernutzung im Vergleich zu Laufzeiten der ersten Generation. Dies ist auf mehrere Faktoren zurückzuführen, z. B. unterschiedliche Basis-Image-Versionen und Unterschiede bei der Berechnung der Arbeitsspeichernutzung durch die beiden Generationen.

Laufzeiten der zweiten Generation berechnen die Arbeitsspeichernutzung der Instanz als Summe von dem, was von einem Anwendungsprozess verwendet wird, und der Anzahl der Anwendungsdateien, die dynamisch im Arbeitsspeicher zwischengespeichert werden. Führen Sie ein Upgrade auf eine größere Instanzklasse mit mehr Arbeitsspeicher durch, um zu vermeiden, dass es bei arbeitsspeicherintensiven Anwendungen aufgrund des Überschreitens von Arbeitsspeicherlimits zum Herunterfahren von Instanzen kommt.

Unterschiede bei der CPU-Auslastung

Laufzeiten der zweiten Generation können beim Kaltstart von Instanzen eine höhere Referenz der CPU-Auslastung aufweisen. Abhängig von der Skalierungskonfiguration einer Anwendung kann dies unbeabsichtigte Nebenwirkungen haben, z. B. eine höhere Anzahl von Instanzen als erwartet, wenn eine Anwendung für die Skalierung basierend auf der CPU-Auslastung konfiguriert ist. Überprüfen und testen Sie die Konfigurationen der Anwendungsskalierung, damit die Anzahl der Instanzen akzeptabel ist, um dieses Problem zu vermeiden.

Unterschiede bei Anfrageheadern

Laufzeiten der ersten Generation ermöglichen, dass Anfrageheader mit Unterstrichen (z. B. X-Test-Foo_bar) an die Anwendung weitergeleitet werden. Laufzeiten der zweiten Generation führen Nginx in die Hostarchitektur ein. Aufgrund dieser Änderung werden Laufzeiten der zweiten Generation so konfiguriert, dass Header mit Unterstrichen (_) automatisch entfernt werden. Vermeiden Sie die Verwendung von Unterstrichen in Anwendungsanfrageheadern, um Anwendungsprobleme zu vermeiden.

Datei app.yaml migrieren

Damit sämtliches Routing in einer einzigen Anwendung verarbeitet wird, muss ein Front Controller eingerichtet werden. Weitere Informationen finden Sie unter Anwendungsstart.

Bei PHP-Laufzeiten der zweiten Generation kann das script-Handler-Element nicht angepasst werden. Der einzige gültige Wert ist auto, da der gesamte Traffic über den Befehl "entrypoint" bereitgestellt wird. Alle nicht statischen URL-Handler müssen script: auto enthalten, damit sie bereitgestellt werden können.

Das Verhalten einiger Elemente in der Konfigurationsdatei app.yaml wurde geändert:

ElementArt der ÄnderungBeschreibung
entrypointHinzugefügtDieses Feld kann optional verwendet werden, um den Befehl anzugeben, der beim Start der Anwendung ausgeführt wird.
threadsafeVerworfenEs wird davon ausgegangen, dass alle Anwendungen threadsicher sind, d. h., eine Instanz kann mehrere Anfragen gleichzeitig verarbeiten.
api_versionVerworfenFrüher nötig, aber für PHP-Laufzeiten der zweiten Generation nicht mehr erforderlich.
application_readableVerworfen
builtinsVerworfen
librariesVerworfenMithilfe einer Metadatendatei wie composer.json können beliebige Abhängigkeiten von Drittanbietern installiert werden.
handlersGeändert
  • Das Feld script ist optional und kann nur den Wert auto enthalten. Verwenden Sie ein Web-Framework wie Laravel, Symfony, Slim oder eine ähnliche Option mit In-App-Routing, um ein Skript auszuführen, wenn eine Anfrage auf eine bestimmte Route trifft.
  • Das Feld "login" wird nicht unterstützt Verwenden Sie das Identity and Access Management (IAM) für die Nutzerverwaltung.

Wenn Sie eines der verworfenen Felder verwenden, tritt bei der Bereitstellung der Anwendung ein Fehler auf.

Weitere Informationen finden Sie in der Referenz zu app.yaml.

Weniger Laufzeitbeschränkungen

Die PHP-Laufzeiten der zweiten Generation haben weniger Einschränkungen als die PHP 5.5-Laufzeit.

Weitere Informationen finden Sie unter PHP-Laufzeitumgebung.

Aus dem App Engine PHP SDK migrieren

Um den Aufwand für die Laufzeitmigration und die Komplexität zu verringern, können Sie in der App Engine-Standardumgebung auf viele Legacy-Bundle-Dienste und APIs in der PHP-Laufzeit der zweiten Generation zugreifen, darunter Memcache. Ihre PHP-Anwendung der zweiten Generation kann über das App Engine SDK die APIs für gebündelte Dienste aufrufen und auf die meisten Funktionen der PHP 5-Laufzeit zugreifen. Nicht alle Legacy-Dienste, die für PHP 5 verfügbar sind, haben einen entsprechenden Dienst in den PHP-Laufzeiten der zweiten Generation. Eine vollständige Liste der gebündelten Legacy-Dienst-APIs, die für die PHP-Laufzeiten der zweiten Generation verfügbar sind, finden Sie in der Referenzdokumentation für gebündelte Legacy-Dienst-APIs.

Sie können auch Google Cloud-Produkte verwenden, die vergleichbare Funktionen wie die gebündelten Legacy-Dienste bereitstellen. Diese Google Cloud-Produkte bieten eine idiomatische Google Cloud CLI-Clientbibliothek. Für die älteren gebündelten Dienste, die in Google Cloud nicht als separate Produkte verfügbar sind, z. B. die Suche, können Sie Drittanbieter oder andere Behelfslösungen verwenden. Weitere Informationen zur Migration zu nicht gebündelten Diensten finden Sie unter Von gebündelten Diensten migrieren.

Anwendung lokal ausführen

So testen Sie Ihre Anwendung und führen sie lokal aus:

  1. Installieren Sie lokal eine PHP-Version, die einer in der App Engine-Standardumgebung verfügbaren PHP-Laufzeit der zweiten Generation entspricht.

  2. Webserver installieren und damit Ihre Anwendung lokal bereitstellen

Den HTTP-Server können Sie z. B. durch Ausführen des folgenden Befehls starten:

php -S localhost:8080

Anschließend können Sie sich die Anwendung im Webbrowser unter http://localhost:8080 ansehen.