Zur Python 3-Laufzeit migrieren

Auf dieser Seite finden Sie eine Anleitung zum Migrieren von Python-Laufzeiten der ersten Generation zur zweiten Generation. Informationen zum Aktualisieren Ihrer Anwendung der zweiten Generation auf die neueste unterstützte Version von Python finden Sie unter Vorhandene Anwendung aktualisieren.

Python 2.7 hat am 31. Januar 2024 das Ende des Supports erreicht. Ihre vorhandenen Python 2.7-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, mithilfe der Richtlinien auf dieser Seite zur neuesten unterstützten Version von Python zu migrieren.

Die Migration zur Python 3-Laufzeit bietet Ihnen die Möglichkeit, aktuelle Sprachfunktionen zu verwenden und mit idiomatischem Code portablere Anwendungen zu erstellen. Die Python 3-Laufzeit verwendet die neueste Version des Open-Source-Python-Interpreters, der von der Python Software Foundation bereitgestellt wird. Anwendungen, die in der Python 3-Laufzeit erstellt wurden, können das umfangreiche Python-Angebot an Paketen und Frameworks nutzen, einschließlich solcher, die C-Code verwenden. Dazu werden Abhängigkeiten in einer requirements.txt-Datei festgelegt.

Übersicht über den Prozess der Laufzeitmigration

Wir empfehlen den folgenden inkrementellen Ansatz für die Laufzeit-Migration, bei dem Sie während des gesamten Prozesses eine funktionierende und testfähige Anwendung verwalten.

1. Aktualisieren Sie Ihre App so, dass sie mit Python 3 kompatibel ist.

   Für dieses Upgrade stehen mehrere Lösungen zur Verfügung. Verwenden Sie beispielsweise Six, Python-Future oder Python-Modernize.

   Weitere Informationen zu diesem Schritt des Migrationsprozesses finden Sie unter Python 2-Code zu Python 3 übertragen auf der Dokumentationswebsite der Python Software Foundation.

2. Wählen Sie eine der Implementierungsstrategien für jeden gebündelten App Engine-Dienst aus, der von Ihrer Anwendung verwendet wird:

   1. Migrieren Sie die gebündelten Legacy-Dienste in Ihrer Python 2-Anwendung zu ungebündelten Google Cloud-Diensten, Drittanbieterdiensten oder anderen empfohlenen Ersatzdiensten.

   2. Verwenden Sie weiterhin die gebündelten Legacy-Dienste in Ihren Python 3-Anwendungen. Dieser Ansatz bietet Ihnen die Möglichkeit, später im Migrationszyklus zu ungebündelten Diensten zu wechseln.

      Hinweis: Nicht alle gebündelten Legacy-Dienste für Python 2 haben einen entsprechenden Dienst in Python 3. Daher müssen diese entweder zu einer Google Cloud oder zu einer Drittanbieter-Dienst migriert werden vor der Portierung zu Python 3.

   Testen Sie Ihre Anwendung nach der Migration der einzelnen Dienste.

3. App Engine-Konfigurationsdateien für die Python 3-Laufzeit vorbereiten. Einige wichtige Änderungen wirken sich auf die Konfigurationseinstellungen in app.yaml aus. Dazu gehören unter anderem:

   • Es wird davon ausgegangen, dass Anwendungen threadsicher sind. Wenn Ihre Anwendung nicht threadsicher ist, sollten Sie max_concurrent_requests in der app.yaml auf 1 setzen. Diese Einstellung kann dazu führen, dass mehr Instanzen erstellt werden, als für eine threadsichere Anwendung erforderlich sind. Dies kann zu unnötigen Kosten führen.

   • Die app.yaml-Datei leitet keine Anfragen mehr an Ihre Skripts weiter. Stattdessen müssen Sie ein Web-Framework mit In-App-Routing verwenden und alle script-Handler in app.yaml aktualisieren oder entfernen. Ein Beispiel für wie Sie das mit dem Flask-Framework tun, finden Sie im App Engine-Migrationsleitfaden-Codebeispiel in GitHub.

     Weitere Informationen zum Ändern dieser und anderer Konfigurationsdateien finden Sie im Abschnitt Konfigurationsdateien.

4. In den Laufzeiten der zweiten Generation sind Anwendungslogs nicht mehr in den Anfragelogs verschachtelt. Es sind zusätzliche Schritte erforderlich, um die verschachtelte Ansicht von Anfrage- und Anwendungslogs im Log-Explorer aufzurufen. Weitere Informationen finden Sie unter Zu Cloud Logging migrieren.

5. Aktualisierte Anwendung in Python 3 testen und bereitstellen

   Nachdem alle Tests bestanden wurden, stellen Sie die aktualisierte Anwendung in App Engine bereit, aber verhindern Sie, dass Traffic automatisch an die neue Version weitergeleitet wird. Trafficaufteilung verwenden, um Traffic langsam von Ihrer Anwendung in der Python 2-Laufzeit zur Anwendung in der Python 3-Laufzeit zu migrieren. Bei Problemen können Sie den gesamten Traffic an eine stabile Version weiterleiten, bis das Problem behoben ist.

Beispiele für das Konvertieren Ihrer Python 2-Anwendungen in Python 3 finden Sie in diesen zusätzlichen Ressourcen.

Hauptunterschiede zwischen den Laufzeiten von Python 2 und Python 3

Die meisten Änderungen, die Sie während der Laufzeit-Migration vornehmen müssen, sind auf die folgenden Unterschiede zwischen den Laufzeiten von Python 2 und Python 3 zurückzuführen:

• Unterschiede bei der Arbeitsspeichernutzung
• Unterschiede bei der CPU-Auslastung
• Unterschiede bei Anfrageheadern
• Unterschiede bei Gunicorn-Workern
• Kompatibilitätsprobleme zwischen Python 2 und Python 3
• Gebündelte App Engine-Dienste in der Python 3-Laufzeit
• Unterschiede bei den Konfigurationsdateien
• Für die Weiterleitung von Anfragen für dynamischen Content ist ein Web-Framework erforderlich.
• Apps, die nur statische Inhalte enthalten
• Unterschiede beim Testen
• Unterschiede bei der Bereitstellung

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.

Unterschiede bei Gunicorn-Workern

Bei Python 3+-Laufzeiten hat die Anzahl der Gunicorn-Worker direkten Einfluss auf die Arbeitsspeichernutzung. Die Erhöhung der Arbeitsspeichernutzung ist direkt proportional zur Zunahme der Worker-Anzahl. Um den Arbeitsspeicherverbrauch zu reduzieren, sollten Sie die Anzahl der Gunicorn-Worker reduzieren. Eine Anleitung zum Konfigurieren der Anzahl von Gunicorn-Workern finden Sie unter Best Practices für Einstiegspunkte.

Kompatibilitätsprobleme zwischen Python 2 und Python 3

Bei der ersten Veröffentlichung von Python 3 im Jahr 2008 wurden mehrere abwärtskompatible Änderungen an der Sprache vorgenommen. Einige dieser Änderungen erfordern nur geringfügige Aktualisierungen Ihres Codes, z. B. das Ändern der print-Anweisung in eine print()-Funktion. Andere Änderungen erfordern möglicherweise umfangreiche Aktualisierungen Ihres Codes, beispielsweise die Art und Weise, wie Sie Binärdaten, Text und Strings verarbeiten.

Viele beliebte Open-Source-Bibliotheken, einschließlich der Python-Standardbibliotheken, wurden auch beim Übergang von Python 2 zu Python 3 geändert.

Gebündelte App Engine-Dienste in der Python 3-Laufzeit

Zur Reduzierung des Aufwands und der Komplexität der Migration können Sie mit der App Engine-Standardumgebung auf viele gebündelte Legacy-Dienste und APIs in der Python 3-Laufzeit zugreifen wie z. B. Memcache. Die Python 3-Anwendung kann die gebündelten Dienst-APIs über sprachspezifische idiomatische Bibliotheken aufrufen und auf dieselben Funktionen wie in der Python 2-Laufzeit zugreifen.

Hinweis: Eine vollständige Liste der APIs für gebündelte Legacy-Dienste, die für Python 3 verfügbar sind, finden Sie unter Verfügbare APIs für gebündelte Legacy-Dienste.

Sie können auch Google Cloud-Produkte verwenden, die vergleichbare Funktionen wie die gebündelten Legacy-Dienste bereitstellen. Wir empfehlen eine Migration zu den nicht gebündelten Google Cloud-Produkten, da Sie dadurch kontinuierliche Verbesserungen und neue Features nutzen können.

Für die gebündelten Dienste, die in Google Cloud nicht als separate Produkte verfügbar sind, wie Bildverarbeitung, Suche und Messaging, können Sie unsere empfohlenen Drittanbieter oder andere Problemumgehungen verwenden.

Konfigurationsdateien

Bevor Sie Ihre Anwendung in der Python 3-Laufzeit der App Engine-Standardumgebung ausführen können, müssen Sie möglicherweise einige der von App Engine verwendeten Konfigurationsdateien ändern:

• app.yaml. Das Verhalten einiger Felder in Ihrer app.yaml-Konfigurationsdatei wurde geändert. Entfernen Sie alle verworfenen Felder und aktualisieren Sie andere Felder, wie im Migrationsleitfaden beschrieben.

• requirements.txt Erstellen Sie diese Datei, um Abhängigkeiten von Drittanbietern zu installieren, einschließlich Python-Pakete, die native C-Erweiterungen erfordern. App Engine installiert diese Abhängigkeiten automatisch während der Anwendungsbereitstellung in der Python 3-Laufzeit. Um Abhängigkeiten in der Python 2-Laufzeit zu installieren, mussten Sie bisher Ihre kopierten oder selbst gebündelten Bibliotheken in dieser Datei auflisten und dann einenpip install -t lib -r requirements.txt Befehl ausführen oder "Integrierte" Bibliotheken von Drittanbietern, die für Ihre Anwendung erforderlich sind, in derDatei app.yaml auflisten.

• appengine_config.py Diese Datei wird in der Python 3-Laufzeit nicht verwendet und wird ignoriert, falls sie bereitgestellt wird. Zuvor in der Python 2-Laufzeit wurde diese Datei verwendet, um Python-Module zu konfigurieren und die Anwendung auf kopierte oder selbst gebündelte Bibliotheken von Drittanbietern verweisen zu lassen.

Zum Weiterleiten von Anfragen für dynamischen Inhalt ist ein Web-Framework erforderlich

In der Python 2-Laufzeit können Sie in der Datei app.yaml URL-Handler erstellen, um anzugeben, welche Anwendung ausgeführt werden soll, wenn eine bestimmte URL oder ein bestimmtes URL-Muster angefordert wird.

In der Python 3-Laufzeit muss Ihre Anwendung ein Web-Framework wie Flask oder Django verwenden, um Anfragen für dynamischen Inhalt weiterzuleiten, anstatt URL-Handler in app.yaml zu verwenden. Für statische Inhalte können Sie weiterhin in der Datei app.yaml Ihrer Anwendung URL-Handler erstellen.

Anwendungen, die nur statische Inhalte enthalten

Wenn Sie eine statische Web-App in App Engine hosten, geben Sie Handler in Ihrer app.yaml-Datei an, um URLs Ihren statischen Dateien zuzuordnen.

Wenn in Python 2 eine Anfrage mit keinem der in der app.yaml-Datei angegebenen Handler übereinstimmt, gibt App Engine den Fehlercode 404 zurück.

Wenn in Python 3 eine Anfrage mit keinem der Handler übereinstimmt, sucht App Engine nach einer main.py-Datei und gibt den Fehler 5xx zurück, wenn keine main.py-Datei gefunden wird. Da App Engine-Apps, die nur statische Inhalte enthalten, keine main.py-Datei erfordern, wird den meisten Nutzern neben Instanz-Startfehlern in Anwendungslogs dieser Fehler angezeigt.

Um dasselbe Verhalten beizubehalten, also die Rückgabe eines 404-Fehlers, wenn keiner der statischen Handler übereinstimmt, und um Fehler in Logs zu vermeiden, haben Sie folgende Möglichkeiten:

• Fügen Sie einen statischen Catchall-Handler hinzu, der auf ein leeres Verzeichnis in der Datei app.yaml verweist.
• Fügen Sie eine einfache dynamische Anwendung in die main.py-Datei ein, um den Fehler 404 zurückzugeben.

Beispiele für beide Optionen:

app.yaml

Erstellen Sie im Stammverzeichnis der Anwendung ein leeres Verzeichnis, z. B. empty/. Erstellen Sie im Handler-Abschnitt der Datei app.yaml ganz am Ende einen neuen Handler, um alle anderen URL-Muster zu erfassen, und geben Sie das Verzeichnis empty in den Elementen static_files und upload an:

  handlers:
  - url:
    .
    .
    .
  - url: /(.*)$
    static_files: empty/\1
    upload: empty/.*$

main.py

Erstellen Sie eine main.py-Datei und fügen Sie den folgenden Code hinzu, um einen 404-Fehler zurückzugeben:

  def app(env, start_response):
    start_response('404 Not Found', [('Content-Type','text/html')])
    return [b"Not Found"]

Test

Wir empfehlen Ihnen, einen Testansatz zu verwenden, der für Python idiomatisch und nicht von dev_appserver abhängig ist. Beispielsweise können Sie mit venv eine isolierte lokale Python 3-Umgebung erstellen. Jedes standardmäßige Python-Test-Framework kann zum Schreiben Ihrer Einheiten-, Integrations- und Systemtests verwendet werden. Sie können auch Entwicklungsversionen Ihrer Dienste einrichten oder die lokalen Emulatoren verwenden, die für viele Google Cloud-Produkte verfügbar sind.

Optional können Sie die Vorschauversion von dev_appserver verwenden, die Python 3 unterstützt. Weitere Informationen zu dieser Testfunktion finden Sie unter Lokalen Entwicklungsserver verwenden.

Wird bereitgestellt

Bereitstellungen über appcfg.py werden für Python 3 nicht unterstützt. Verwenden Sie stattdessen das gcloud-Befehlszeilentool zum Bereitstellen Ihrer Anwendung.

Logging

Das Logging in der Python 3-Laufzeit folgt dem Logging-Standard in Cloud Logging. In der PHP 3-Laufzeit werden Anwendungslogs nicht mehr mit den Anfragelogs gebündelt, sondern in verschiedenen Einträgen getrennt. Weitere Informationen zum Lesen und Schreiben von Logs in der Python 3-Laufzeit finden Sie in der Logging-Anleitung.

Zusätzliche Migrationsressourcen

Weitere Informationen zum Migrieren Ihrer App Engine-Anwendungen zu eigenständigen Cloud-Diensten oder der Python 3-Laufzeit finden Sie in den folgenden App Engine-Ressourcen:

• Codelabs und Videos zur serverlosen Anwendungsmigration
• Von der Community bereitgestellte Beispiele für die Migration von Python 2 zu Python 3