Unterstützung für Legacy-Laufzeiten

Legacy-Laufzeiten umfassen Sprachversionen, die nicht mehr von Open-Source-Communitys gepflegt werden. Da viele App Engine-Kunden immer noch von diesen Sprachversionen abhängig sind, bietet Google langfristige Unterstützung für die folgenden Legacy-Laufzeiten in der App Engine-Standardumgebung:

Wichtig: Google stellt Legacy-Laufzeiten auf die Phase Support eingestellt um. Weitere Informationen finden Sie im Zeitplan für die Laufzeitunterstützung.

Unser Ziel

Für Legacy-Laufzeiten wurde am 30. Januar 2024 das Ende des Supports erreicht.

Die folgenden Änderungen wurden an den Legacy-Laufzeiten vorgenommen:

  • So weit wie möglich wurden die Komponenten der Legacy-Laufzeiten in ihren Open-Source-Zustand zurückversetzt. Wir mussten einige Laufzeiten stark einschränken und ändern, um Ihre Anwendungen sicher in unseren Rechenzentren auszuführen. Durch Änderungen an der Funktionsweise der Laufzeiten in unseren Rechenzentren können wir langfristig eine sichere und skalierbare Umgebung für diese Laufzeiten bereitstellen.

  • Es wurden vollständige Build-Systeme hinzugefügt, die Paket-Repositories, idiomatische Komponenten-Builds und Asset-Repositories unterstützen.

Sicherheitsupdates

Wenn Communities bestimmte Versionen ihrer Sprachen nicht mehr pflegen, können Sicherheitslücken in Ihrer Anwendung entstehen, für die es keine öffentlich verfügbare Lösung gibt. Daher ist die weitere Ausführung Ihrer Anwendung in einigen App Engine-Laufzeiten mit einem höheren Risiko verbunden als ein Upgrade auf eine Laufzeit mit einer von der Community unterstützten Sprache.

Wir können keine Zusicherung geben, dass jede von Ihrer Anwendung verwendete API aktualisiert wird. Möglicherweise sind Updates nur in Bibliotheken für neuere Versionen der Sprache verfügbar.

Unterstützung für gebündelte App Engine-Dienste

Die Laufzeiten von Python 2.7, Java 8, Go 1.11 und PHP 5.5 bietet gebündelte App Engine-Dienste und APIs wie Blobstore, Memcache und Aufgabenwarteschlangen.

Sie können in bestimmten Laufzeiten der zweiten Generation weiterhin auf viele dieser gebündelten Dienste und APIs zugreifen:

Die Anwendung kann die gebündelten Dienst-APIs über sprachspezifische idiomatische Bibliotheken aufrufen und auf dieselben Funktionen wie in den Legacy-Laufzeiten zugreifen. Die gebündelten Dienste werden in den neueren Laufzeiten angeboten, um mehr Flexibilität zu bieten. Sie können sie entweder zu den nicht gebündelten Diensten migrieren oder weiterhin die gebündelten Legacy-Dienste der App Engine verwenden.

Wenn sich bestimmte veraltete Funktionen in der Pipeline befinden, befolgen wir die Richtlinie zur Einstellung von Produkten und Diensten und schlagen Alternativen vor. Wir gehen nicht davon aus, dass die Mehrheit der Anwendungen Codeänderungen oder erneute Bereitstellungen erfordert.

Aktueller Status jeder Laufzeit

Python 2.7

Die Python 2.7-Laufzeit wurde am 27. Februar 2012 eingeführt. Obwohl wir unsere Änderungen und Einschränkungen bereits größtenteils aus dieser Laufzeit entfernt haben, werden weitere Aktualisierungen folgen, um den Build-Prozess, den Anfragepfad und die Paketverfügbarkeit zu normalisieren. Diese Änderungen an der Laufzeit ermöglichen es Google Cloud, die Python 2.7-Laufzeit weit über den 1. Januar 2020 hinaus zu unterstützen. Ab diesem Datum wird Python 2.7 von der Python-Community nicht mehr offiziell unterstützt.

Die Änderungen, die wir an der Python 2.7-Laufzeit vorgenommen haben, und die Änderungen aus der Ankündigung vom Herbst 2021 stellen die meisten gebündelten App Engine-Dienste in Python 3 wieder her. Mit diesen Diensten können Sie einfacher zu Python 3 migrieren und/oder die gebündelten Dienste vor dem Ende des Supports durch entsprechende Google Cloud-Dienste ersetzen. Weitere Informationen finden Sie in den folgenden Anleitungen:

Java 8

Die Java 8-Laufzeit wurde am 28. Juni 2017 eingeführt. Diese Laufzeit wurde geringfügig für App Engine geändert und bot breite Unterstützung für den Import von Java-Paketen.

Wir nehmen folgende Aktualisierungen an dieser Laufzeit vor:

  • Die Java-Laufzeit wird in den Open-Source-Zustand zurückversetzt.

  • Der Anfragepfad wird normalisiert.

  • Ein Upgrade auf Jetty 9.4 wird ausgeführt.

Durch diese Änderungen kann Google Cloud die Java 8-Laufzeit in absehbarer Zukunft unterstützen.

Mit den Änderungen, die wir an der Java 8-Laufzeit vorgenommen haben, können Sie die gebündelten App Engine-Dienste vor dem Ende des Supports durch Google Cloud-Dienste ersetzen und zu Java 11/17 migrieren. Weitere Informationen finden Sie im Dokument zur Migration von Java 8 zu Java 11+.

Wir konnten Java 6- und Java 7-Anwendungen automatisch zur Java 8-Laufzeit migrieren, ohne dass Änderungen am Anwendungscode erforderlich waren. Bei Java 11 ist diese Art der Abwärtskompatibilität jedoch nicht gegeben, sodass es uns nicht möglich ist, Anwendungen automatisch zur Java 11-Laufzeit zu migrieren. Da Sie bei der Migration zu Java 11 unter Umständen erhebliche Änderungen an Ihren Java 6-, Java 7- und Java 8-Anwendungen vornehmen müssen, können Sie die Anwendungen weiterhin in der Java 8-Laufzeit ausführen.

Go 1.11

Die Go 1.11-Laufzeit wurde am 20. März 2019 mit der Empfehlung eingeführt, Go-Anwendungen der Versionen 1.6 bis 1.9 zur Go 1.11-Laufzeit zu migrieren. Die Go 1.11-Laufzeit ist der langfristige Laufzeitzustand für Anwendungen, die mit Go 1.6 bis Go 1.11 erstellt wurden.

Sobald Ihre Anwendungen auf Go 1.11 ausgeführt werden, können Sie die gebündelten App Engine-Dienste und APIs vor dem Ende des Supports durch Google Cloud-Dienste ersetzen und auf eine unterstützte Version von Go aktualisieren. Weitere Informationen zur Migration finden Sie unter App Engine-Anwendungen zu Go 1.12 migrieren.

PHP 5.5

Wir haben die PHP 5.5-Laufzeit am 16. Mai 2013 eingeführt. Diese Laufzeit hat viele Funktionen aus der Open-Source-Version entfernt und Anwendungen in einer benutzerdefinierten Sandbox ausgeführt.

Wir setzen diese Laufzeit derzeit auf ihren Open-Source-Zustand zurück und modernisieren die Sandbox. Wir werden weitere Aktualisierungen vornehmen, um den Anfragepfad zu normalisieren und die Leistung zu optimieren. Diese Änderungen ermöglichen es uns, die PHP 5.5-Laufzeit auf absehbare Zeit zu unterstützen.

Durch die Änderungen an der PHP 5.5-Laufzeit können Sie die gebündelten App Engine-Dienste vor dem Ende des Supports durch Google Cloud-Dienste ersetzen und zu PHP 7/8 migrieren. Weitere Informationen finden Sie unter Anwendungen von PHP 5.5 zu PHP 7/8 migrieren.

Bereitstellungen für Legacy-Laufzeiten aktivieren, die das Ende des Supports erreichen

Gemäß der Laufzeitrichtlinie von App Engine können Sie Anwendungen nicht mehr mit Laufzeiten bereitstellen, die das Ende des Supports erreicht haben. Wichtige Zeiträume, die sich auf Ihre Laufzeit auswirken, finden Sie im Supportzeitplan.

Wenn Ihre Organisation Bereitstellungen für Legacy-Laufzeiten wieder aktivieren soll, die das Ende des Supportzeitraums erreicht haben, können Sie mit constraints/appengine.runtimeDeploymentExemption eine neue Organisationsrichtlinie definieren. Diese Organisationsrichtlinie zum erneuten Aktivieren von Bereitstellungen ist allgemein verfügbar. Die kontinuierliche Verwendung von Legacy-Laufzeiten nach dem Enddatum des Supports ist experimentell und unterliegt den "Pre-GA-Angebotsbedingungen".

Zum Erstellen oder Ändern von Organisationsrichtlinien muss Ihr Konto die Rolle roles/orgpolicy.policyAdmin haben.

Richtlinien zum erneuten Aktivieren von Bereitstellungen verwenden

Verwenden Sie zum Erstellen einer Richtlinie, die Bereitstellungen aktiviert, das Google Cloud CLI oder die Google Cloud Console, die das Ende des Supports innerhalb einer bestimmten Organisation in der angegebenen Umgebung erreicht haben.

Console

  1. Rufen Sie in der Google Cloud Console die Seite „Organisationsrichtlinien“ auf.
    Zu den Organisationsrichtlinien

    Auf der Seite "Organisationsrichtlinien" wird eine Liste der verfügbaren Einschränkungen für Organisationsrichtlinien angezeigt.

  2. Wählen Sie das Projekt, den Ordner oder die Organisation aus, der Sie die neue Richtlinie hinzufügen möchten.

  3. Suchen Sie in der Liste die Richtlinie Laufzeitbereitstellungsausnahme (App Engine). Dazu können Sie das Feld Filter oben in der Liste verwenden.

  4. Klicken Sie auf den Namen der Richtlinie. Alternativ können Sie im Kontextmenü Richtlinie bearbeiten auswählen.

  5. Klicken Sie auf Richtlinie verwalten.

  6. Wählen Sie unter Gilt für die Option Anpassen aus.

  7. Wählen Sie unter Richtlinienerzwingung die Option Ersetzen aus.

  8. Klicken Sie unter Regeln auf Regel hinzufügen.

  9. Wählen Sie unter Richtlinienwerte die Option Benutzerdefiniert.

  10. Wählen Sie als Richtlinientyp Zulassen aus.

  11. Geben Sie unter Benutzerdefinierter Wert die Laufzeit an, die Sie in der Organisation erzwingen möchten. Unterstützte Werte sind:

    • python27, um Anwendungen mit Python 2.7 zuzulassen.
    • java8, um Anwendungen mit Java 8 zuzulassen
    • php55, um Anwendungen mit PHP 5.5 zuzulassen
    • Wenn Sie mehrere Laufzeiten explizit zulassen möchten, geben Sie python27, java8 und php55 zusammen an. Standardmäßig sind keine Laufzeiten zulässig, wenn keine Richtlinie festgelegt ist.

  12. Klicken Sie auf Fertig.

  13. Klicken Sie auf Speichern.

Nachdem Ihre Änderungen angewendet wurden, ermöglicht diese Richtlinie die Bereitstellung von App Engine-Laufzeiten, für die der Support eingestellt wurde, in der angegebenen Umgebung.

gcloud

Führen Sie dazu diesen Befehl aus:

gcloud resource-manager org-policies \
allow appengine.runtimeDeploymentExemption \
--organization=ORGANIZATION_NUMBER RUNTIME_ID

Ersetzen Sie:

  • ORGANIZATION_NUMBER durch die Nummer der Organisation, auf die die Richtlinie angewendet werden soll.
  • RUNTIME_ID durch die für die Bereitstellung zulässige Laufzeit.

  • RUNTIME_ID durch eine der folgenden Laufzeit-IDs:

    • python27, um Anwendungen mit Python 2.7 zuzulassen.
    • java8, um Anwendungen mit Java 8 zuzulassen
    • php55, um Anwendungen mit PHP 5.5 zuzulassen
    • Wenn Sie mehrere Sprachlaufzeiten explizit zulassen möchten, geben Sie python27, java8 und php55 zusammen an. Standardmäßig sind keine Sprachlaufzeiten zulässig, wenn keine Richtlinie festgelegt ist.