Python-Laufzeit

Hinweis: Einige Python-Laufzeiten haben das Ende des Supports erreicht. Sie können Versionen mit Laufzeiten nach dem Ende des Supports nicht noch einmal bereitstellen. Wir empfehlen ein Upgrade Ihrer Anwendung, um die aktuelle Version von Python zu verwenden.

Die Python-Laufzeit ist das Softwarepaket, das für die Installation Ihres Anwendungscodes und der Abhängigkeiten sowie für die Ausführung dieser Anwendung in der flexiblen Umgebung verantwortlich ist.

Python-Versionen

Python 3.12 verwendet Buildpacks. Eine vollständige Liste der unterstützten Phyton-Versionen und der entsprechenden Ubuntu-Versionen finden Sie im Laufzeitsupportzeitplan.

So verwenden Sie eine unterstützte Python-Version:

• Fügen Sie die Einstellungen runtime_config und operating_system in die Datei app.yaml ein, um ein Betriebssystem anzugeben.

• Installieren Sie die gcloud CLI-Version 420.0.0 oder höher. Sie können die Befehlszeilentools mit dem Befehl gcloud components update aktualisieren. Führen Sie den Befehl gcloud version aus, um Ihre installierte Version aufzurufen.

• Optional: Sie können eine Laufzeitversion angeben. Nehmen Sie dazu die Einstellung runtime_version in die Datei app.yaml auf. Standardmäßig wird die neueste Python-Version verwendet, wenn die Einstellung runtime_version nicht angegeben ist.

Beispiele

• So geben Sie Python 3.12 auf Ubuntu 22 an:

  runtime: python
  env: flex
  entrypoint: gunicorn -b :$PORT main:app
  
  runtime_config:
      operating_system: "ubuntu22"
      runtime_version: "3.12"
  

• So geben Sie die neueste unterstützte Python-Version unter Ubuntu 22 an:

    runtime: python
    env: flex
    entrypoint: gunicorn -b :$PORT main:app
  
    runtime_config:
        operating_system: "ubuntu22"
  

Weitere Informationen finden Sie auf der Referenzseite app.yaml.

Vorherige Laufzeitversionen

Warnung: Python Version 3.7 und früher haben das Ende der Unterstützung erreicht. App Engine blockiert die Bereitstellung von Anwendungen mit Laufzeiten, für die der Support eingestellt wurde. Wir empfehlen, dass Sie Ihre Anwendung zu einer unterstützten Version von Python migrieren oder eine benutzerdefinierte Laufzeit verwenden.

Für Python Version 3.7 und früher geben Sie eine Version mit den Einstellungen runtime_config und python_version in der Datei app.yaml Ihrer Anwendung an.

Beispiel

runtime: python
env: flex
entrypoint: gunicorn -b :$PORT main:app

runtime_config:
    python_version: 3.7

Bei den Python-Versionen 3.7 und früher ist der Standard-Interpreter Python 2.7.12, wenn runtime_config oder python_version weggelassen wird. Sie können beispielsweise die Standardlaufzeit verwenden. Geben Sie dazu runtime: python in der Datei app.yaml an:

runtime: python
env: flex

Weitere Informationen finden Sie auf der Referenzseite app.yaml.

Die Interpreter, die für jede -Einstellung bereitgestellt werden, sind in der folgenden Tabelle aufgeführt:

python_version-Einstellung	Bereitgestellter Interpreter	Laufzeit-ID	Beispiel für app.yaml
2 (Standard)	2.7.12	python2	runtime_config:  python_version: 2
3.4	3.4.8	python34	runtime_config:  python_version: 3.4
3.5	3.5.9	python35	runtime_config:  python_version: 3.5
3 oder 3.6	3.6.10	python36	runtime_config:  python_version: 3
3.7	3.7.9	python37	runtime_config:  python_version: 3.7

Hinweis: Wenn neue Nebenversionen von Python 3 veröffentlicht werden, kann es einen Zeitraum geben, in dem die generische 3-Einstellung auf die vorherige Nebenversion verweist. In den Versionshinweisen zur gcloud CLI wird angegeben, wann 3 auf die neueste Nebenversionsnummer verweist.

Unterstützung für andere Python-Laufzeiten

Wenn Sie eine Python-Version verwenden müssen, die nicht unterstützt wird, können Sie eine benutzerdefinierte Laufzeit erstellen und ein gültiges Basis-Image mit der von Ihnen benötigten Python-Version auswählen.

Informationen zu von Google bereitgestellten Basis-Images oder Docker-Basis-Images für Python finden Sie unter Benutzerdefinierte Laufzeiten erstellen.

Weitere Informationen zur Containerisierung von App Engine-Anwendungen für Cloud Run finden Sie im Migrationsleitfaden.

Abhängigkeiten

Die Laufzeit sucht im Quellverzeichnis der Anwendung nach der Datei requirements.txt und verwendet pip, um Abhängigkeiten zu installieren, bevor die Anwendung gestartet wird. Weitere Informationen zur Deklaration und Verwaltung von Paketen finden Sie unter Python-Bibliotheken verwenden.

Wenn Ihre Anwendung private Abhängigkeiten erfordert, müssen Sie zur Installation der entsprechenden Pakete eine benutzerdefinierte Laufzeit verwenden, die auf der Python-Laufzeit basiert.

Anwendungsstart

Die Laufzeit startet Ihre Anwendung mit dem in der Datei app.yaml definierten entrypoint. Der Einstiegspunkt sollte einen Prozess starten, der auf HTTP-Anfragen an dem von der Umgebungsvariablen PORT definierten Port antwortet.

Die meisten Webanwendungen verwenden einen WSGI-Server wie Gunicorn, uWSGI oder Waitress.

Bevor Sie einen dieser Server verwenden können, müssen Sie ihn als Abhängigkeit in die requirements.txt-Datei Ihrer Anwendung aufnehmen. Wenn Sie gunicorn für Ihre Flask-Anwendung verwenden, achten Sie darauf, dass die Python-Version Ihrer Anwendung kompatibel ist mit gunicorn.

Die Laufzeit stellt sicher, dass alle Abhängigkeiten installiert sind, bevor der Einstiegspunkt aufgerufen wird.

Flask==2.0.2
gunicorn==20.1.0

Beispiel für einen Einstiegspunkt unter Verwendung von Gunicorn für eine Flask-Anwendung:

entrypoint: gunicorn -b :$PORT main:app

Beispiel für einen Einstiegspunkt unter Verwendung von Gunicorn für eine Django-Anwendung:

entrypoint: gunicorn -b :$PORT mydjangoapp:wsgi

Hinweis: Der Einstiegspunktbefehl wird von der Bash-exec-Funktion ausgeführt. Shell-Variablen wie $PORT werden normalerweise ersetzt, aber Shell-Syntax wie if, for und while, die in den entrypoint-Befehl eingebettet ist, funktioniert nicht.

Gunicorn ist der empfohlene WSGI-Server, aber es ist durchaus möglich, einen anderen WSGI-Server zu verwenden. Das folgende Beispiel zeigt einen Einstiegspunkt, der uWSGI mit Flask verwendet:

entrypoint: uwsgi --http :$PORT --wsgi-file main.py --callable app

Für Anwendungen, die Requests ohne einen WSGI-Server verarbeiten können, müssen Sie lediglich ein Python-Script ausführen:

entrypoint: python main.py

Empfohlene Gunicorn-Konfiguration

Die einfachen oben aufgeführten entrypoint-Beispiele dienen als Ausgangspunkte und funktionieren möglicherweise mit Ihren Webanwendungen. Die meisten Anwendungen erfordern jedoch eine zusätzliche Konfiguration des WSGI-Servers. Statt alle Einstellungen für den Einstiegspunkt anzugeben, sollten Sie die Datei gunicorn.conf.py im Stammverzeichnis Ihres Projekts erstellen, in dem sich die Datei app.yaml befindet, und sie als Einstiegspunkt festlegen:

entrypoint: gunicorn -c gunicorn.conf.py -b :$PORT main:app

Weitere Informationen zu sämtlichen Konfigurationswerten von Gunicorn finden Sie in der zugehörigen Dokumentation.

Worker

Gunicorn verwendet Worker, um Requests zu bearbeiten. Gunicorn verwendet standardmäßig sync workers. Diese Worker-Klasse ist mit allen Webanwendungen kompatibel, aber jeder Worker kann jeweils nur einen Request bearbeiten. Gunicorn verwendet standardmäßig nur diese Worker. Dies kann häufig dazu führen, dass Ihre Instanzen nicht ausreichend ausgelastet sind und die Latenz in Anwendungen mit hoher Auslastung steigt.

Wir empfehlen, die Anzahl der Worker auf das 2- bis 4-Fache der Anzahl der CPU-Kerne für Ihre Instanz plus eins zu setzen. Sie können dies in gunicorn.conf.py folgendermaßen angeben:

import multiprocessing

workers = multiprocessing.cpu_count() * 2 + 1

Außerdem können einige Webanwendungen, die hauptsächlich I/O-gebunden sind, eine Leistungsverbesserung durch Verwendung einer anderen Worker-Klasse feststellen. Wenn Ihre Worker-Klasse zusätzliche Abhängigkeiten wie gevent oder tornado benötigt, müssen diese in der Datei requirements.txt Ihrer Anwendung deklariert werden.

HTTPS- und Weiterleitungs-Proxys

App Engine beendet die HTTPS-Verbindung am Load-Balancer und leitet die Anfrage zu Ihrer Anwendung weiter. Für die meisten Anwendungen müssen Sie nicht wissen, ob die Anfrage über HTTPS gesendet wurde. Für Anwendungen, die diese Informationen benötigen, sollte Gunicorn jedoch so konfiguriert werden, dass dem App Engine-Proxy in ihrer gunicorn.conf.py-Datei vertraut wird:

forwarded_allow_ips = '*'
secure_scheme_headers = {'X-FORWARDED-PROTO': 'https'}

Gunicorn stellt nun sicher, dass das auf wsgi.url_scheme festgelegte 'https', das die meisten Web-Frameworks als Hinweis auf die Anfrage verwenden, sicher ist. Wenn Ihr WSGI-Server oder -Framework dies nicht unterstützt, prüfen Sie den Wert des Headers X-Forwarded-Proto einfach manuell.

Einige Anwendungen müssen auch die IP-Adresse des Nutzers ermitteln. Diese Funktion ist im Header X-Forwarded-For verfügbar.

Beachten Sie, dass die Einstellung secure_scheme_headers in gunicorn.conf.py großgeschrieben werden muss, z. B. X-FORWARDED-PROTO. Die von Ihrem Code gelesenen Header werden hingegen in Klein- und Großbuchstaben geschrieben, z. B. X-Forwarded-Proto.

Laufzeit erweitern

Die flexible Python-Laufzeitumgebung kann zur Erstellung einer benutzerdefinierten Laufzeit verwendet werden. Weitere Informationen finden Sie unter Python anpassen.

Umgebungsvariablen

Die folgenden Umgebungsvariablen werden durch die Laufzeitumgebung festgelegt:

Umgebungsvariable	Beschreibung
GAE_INSTANCE	Der Name der aktuellen Instanz
GAE_MEMORY_MB	Die Größe des für den Anwendungsprozess verfügbaren Speichers
GAE_SERVICE	Der in der Datei app.yaml Ihrer Anwendung angegebene Dienstname. Wenn kein Dienstname angegeben ist, wird als Wert default festgelegt.
GAE_VERSION	Das Versionslabel der aktuellen Anwendung
GOOGLE_CLOUD_PROJECT	Die mit Ihrer Anwendung verknüpfte Projekt-ID, die in der Google Cloud Console angezeigt wird
PORT	Der Port, der HTTP-Anfragen empfängt

Sie können zusätzliche Umgebungsvariablen in der Datei app.yaml festlegen.

Metadatenserver

Jede Instanz Ihrer Anwendung kann den Compute Engine-Metadatenserver verwenden, um Informationen über die Instanz abzufragen, einschließlich ihres Hostnamens, ihrer externen IP-Adresse, Instanz-ID, benutzerdefinierten Metadaten und Dienstkontoinformationen. Sie können in App Engine nicht für jede einzelne Instanz benutzerdefinierte Metadaten festlegen. Sie haben aber die Möglichkeit, projektweite benutzerdefinierte Metadaten festzulegen und diese aus den App Engine- und Compute Engine-Instanzen zu lesen.

Diese Beispielfunktion ruft die externe IP-Adresse der Instanz über den Metadatenserver ab:

METADATA_NETWORK_INTERFACE_URL = (
    "http://metadata/computeMetadata/v1/instance/network-interfaces/0/"
    "access-configs/0/external-ip"
)


def get_external_ip():
    """Gets the instance's external IP address from the Compute Engine metadata
    server.

    If the metadata server is unavailable, it assumes that the application is running locally.

    Returns:
        The instance's external IP address, or the string 'localhost' if the IP address
        is not available.
    """
    try:
        r = requests.get(
            METADATA_NETWORK_INTERFACE_URL,
            headers={"Metadata-Flavor": "Google"},
            timeout=2,
        )
        return r.text
    except requests.RequestException:
        logging.info("Metadata server could not be reached, assuming local.")
        return "localhost"