Python 2 wird von der Community nicht mehr unterstützt. Wir empfehlen die Migration von Python 2-Anwendungen zu Python 3.

Referenz zu app.yaml

Regions-ID

REGION_ID ist ein abgekürzter Code, den Google anhand der Region zuweist, die Sie beim Erstellen Ihrer Anwendung ausgewählt haben. Der Code bezieht sich nicht auf ein Land oder eine Provinz, auch wenn einige Regions-IDs häufig verwendeten Länder- und Provinzcodes ähneln können. Das Einbinden von REGION_ID.r in App Engine-URLs ist für vorhandene Anwendungen optional und wird bald für alle neuen Anwendungen erforderlich sein.

Für einen reibungslosen Übergang wird App Engine nach und nach für die Verwendung von Regions-IDs aktualisiert. Wenn Ihr Google Cloud-Projekt noch nicht aktualisiert wurde, wird für Ihre Anwendung keine Regions-ID angezeigt. Da die ID für vorhandene Anwendungen optional ist, müssen Sie keine URLs aktualisieren oder andere Änderungen vornehmen, wenn die Regions-ID für Ihre vorhandenen Anwendungen verfügbar wird.

Hier finden Sie weitere Informationen zu Regions-IDs.

Die Einstellungen einer App Engine-Anwendung werden in der Datei app.yaml konfiguriert. Diese Datei legt die URL-Pfade für Anfrage-Handler und statische Dateien fest. Die Datei app.yaml enthält außerdem Informationen zum Code der Anwendung, zur Node.js-Laufzeit und zur neuesten Versionskennzeichnung.

Jeder Dienst in der Anwendung hat eine eigene app.yaml-Datei, die als Deskriptor für seine Bereitstellung dient. Erstellen Sie zuerst die Datei app.yaml für den Standarddienst default. Erst dann können Sie Dateien vom Typ app.yaml für zusätzliche Dienste in der Anwendung anlegen und bereitstellen.

Verzeichnisstruktur

Weitere Informationen zum Strukturieren mehrerer Dienste in Ihrer Anwendung finden Sie unter Konfigurationsdateien.

Beispiel

Das folgende Beispiel zeigt eine app.yaml-Datei für eine Python 2-Anwendung:

runtime: python27
api_version: 1
threadsafe: true

handlers:
- url: /
  script: home.app

- url: /index\.html
  script: home.app

- url: /stylesheets
  static_dir: stylesheets

- url: /(.*\.(gif|png|jpg))$
  static_files: static/\1
  upload: static/.*\.(gif|png|jpg)$

- url: /admin/.*
  script: admin.app
  login: admin

- url: /.*
  script: not_found.app

Eine script:-Anweisung kann entweder einen Dateipfad mit der Endung .py enthalten – das Skript nutzt dann CGI – oder einen Python-Modulpfad mit durch Punkte getrennten Paketnamen – das Skript nutzt in diesem Fall WSGI.

Syntax

Die Syntax von app.yaml entspricht dem YAML-Format.

Das YAML-Format unterstützt Kommentare. Eine Zeile, die mit einem Rautezeichen (#) beginnt, wird ignoriert:

# This is a comment.

URL- und Dateipfadmuster verwenden die erweiterte POSIX-Syntax für reguläre Ausdrücke mit Ausnahme von Sortierelementen und -klassen. Rückverweise auf gruppierte Übereinstimmungen (z. B. \1) werden ebenso wie die folgenden Perl-Erweiterungen unterstützt: \w \W \s \S \d \D.

Laufzeit- und Anwendungselemente

Element Beschreibung
application

Es wird empfohlen, das Element application aus der Datei app.yaml zu entfernen und stattdessen die Anwendungs-ID mit einem Befehlszeilen-Flag anzugeben:

  • Zur Verwendung des Befehls gcloud app deploy müssen Sie das Flag --project angeben:
    
    gcloud app deploy --project [YOUR_PROJECT_ID]
  • Für den Befehl appcfg.py update geben Sie das Flag -A an:
    
    appcfg.py update -A [YOUR_PROJECT_ID]

Weitere Informationen zur Verwendung dieser Befehle finden Sie unter Anwendung bereitstellen.

Die Anwendungs-ID ist die Projekt-ID in der Cloud Console, die Sie beim Erstellen der Anwendung in der Google Cloud Console angegeben haben.

api_version

Erforderlich: Die Version der API in der Laufzeitumgebung, die von Ihrer Anwendung verwendet wird.

Dieses Feld ist in neueren App Engine-Laufzeiten nicht verfügbar.

Wenn Google die Unterstützung für eine neue Version der API einer Laufzeitumgebung bekannt gibt, verwendet Ihre bereitgestellte Anwendung weiterhin die Version, für die sie geschrieben wurde. Ändern Sie diesen Wert und stellen Sie die Anwendung anschließend noch einmal in App Engine bereit, um die Anwendung auf eine neue API-Version zu aktualisieren. Wenn Sie den Wert 1 angeben, wird bei jeder Bereitstellung dieser Anwendung die neueste unterstützte Laufzeitumgebung (derzeit ) verwendet.

Derzeit ist für App Engine genau eine Version der python27-Laufzeitumgebung vorhanden: 1.

auto_id_policy Optional. Wenn Sie Entitätenbezeichner automatisch festlegen, können Sie die verwendete Methode ändern, indem Sie die Richtlinie zur automatischen ID-Vergabe (auto ID policy) einrichten. Folgende Optionen sind gültig:
default
Standard. Verwendet verteilte, automatisch vergebene IDs, bei denen es sich um große, gut verteilte Ganzzahlen handelt, die jedoch klein genug sind, um durch 64-Bit-Gleitkommazahlen dargestellt zu werden.
legacy
Die Legacy-Option wird in einem zukünftigen Release verworfen und früher oder später entfernt. Weitere Informationen finden Sie im Blogpost zur Mitteilung dieser Änderung.
builtins

Optional. Das Python 2 SDK umfasst einige integrierte Handler für gebräuchliche Anwendungsfunktionen. Mit der Anweisung builtins können bestimmte Handler in app.yaml aufgenommen werden.

Dieses Feld wird in der Python 3-Laufzeit verworfen.

Folgende integrierte Handler stehen zur Verfügung:

appstats
Aktiviert AppStats unter /_ah/stats/. Damit können Sie die Leistung Ihrer Anwendung messen. Sie müssen auch die Ereignisaufzeichnung installieren, um Appstats zu verwenden.
deferred
Aktiviert den verzögerten Handler unter /_ah/queue/deferred. Dieser integrierte Handler ermöglicht Entwicklern die Verwendung von deferred.defer(), um die Erstellung von Aufgaben in Aufgabenwarteschlangen zu vereinfachen. Siehe auch Hintergrundarbeit mit der Bibliothek zurückgestellter Aufgaben.
remote_api
Aktiviert das remote_api-builtin unter /_ah/remote_api/. Mit diesem builtin wird Remoteanwendungen mit den entsprechenden Anmeldedaten Remotezugriff auf den Datenspeicher gewährt.
Beispiel:

builtins:
- deferred: on
- appstats: on

Die builtins-Anweisung ist eine spezielle Instanz der includes-Anweisung. Jede builtin-Anweisung entspricht in Python einer includes-Anweisung mit einem erweiterten Pfad. Beispiel:


builtins:
- name: on

entspricht:


includes:
- $PYTHON_LIB/google/appengine/ext/builtins/name/

Wenn Sie in der Datei app.yaml builtins verwenden, ersetzen Handler, die in der integrierten Datei include.yaml definiert sind, alle Handler, die Sie in der Datei app.yaml definieren. Wenn Sie jedoch eine Datei mit builtins oder includes verwenden, werden die Handler in der Reihenfolge der include-Hierarchie hinzugefügt. Anders ausgedrückt: Die Handler des "übergeordneten" include werden vor den builtins der "untergeordneten" includes hinzugefügt und so weiter.

Angenommen die folgende Datei app.yaml verwendet die integrierten appstats-Handler:


handlers:
- url: /.*
  script: main.app
builtins:
- appstats: on

Die daraus resultierende Liste von Handlern ist:


[/_ah/stats, /.*]

Wenn app.yaml eine includes-Anweisung verwendet:


includes:
- included.yaml

Und die included.yaml-Datei builtins verwendet:


handlers:
- url: /.*
  script: main.app
builtins:
- appstats: on

Dann ist die daraus resultierende Liste der Handler:


[/.*, /_ah/stats]

Die Reihenfolge der Platzierung der builtins-Klausel in einer .yaml-Datei ändert das Verhalten nicht.

default_expiration

Optional. Legt einen globalen Standard-Cache-Zeitraum für alle Handler statischer Dateien einer Anwendung fest. Außerdem haben Sie die Möglichkeit, eine Cache-Dauer für bestimmte Handler statischer Dateien zu konfigurieren. Der Wert setzt sich aus einem String von Zahlen und Einheiten zusammen, die durch Leerzeichen voneinander getrennt sind. Bei den Einheiten kann es sich um "d" für Tage, "h" für Stunden, "m" für Minuten und "s" für Sekunden handeln. Beispielsweise legt "4d 5h" den Cache-Ablauf auf 4 Tage und 5 Stunden nach der ersten Anforderung der Datei fest. Wenn keine Angabe gemacht wird, legt der Produktionsserver die Dauer auf 10 Minuten fest.

Beispiel:

runtime: python27
api_version: 1
threadsafe: true

default_expiration: "4d 5h"

handlers:
# ...

Weitere Informationen finden Sie unter Cache-Ablauf.

env_variables

Optional. Sie können Umgebungsvariablen in der Datei app.yaml definieren, um sie der Anwendung zur Verfügung zu stellen.

Umgebungsvariablen mit dem Präfix GAE sind für die Verwendung durch das System reserviert und in der Datei app.yaml nicht zulässig.

Diese Variablen sind im os.environ-Wörterbuch verfügbar:

env_variables:
  DJANGO_SETTINGS_MODULE: "myapp.settings"
error_handlers

Optional. Wird verwendet, um benutzerdefinierte Fehlerseiten zu konfigurieren, die für verschiedene Fehlertypen zurückgegeben werden.

Dieses Element kann folgende Elemente enthalten:

error_code
Optional. Der Wert für error_code kann einer der folgenden sein:
over_quota
Zeigt an, dass die Anwendung ein Ressourcenkontingent überschritten hat
.
dos_api_denial
Zeigt an, dass die Anfrage von der DoS-Schutzkonfiguration der Anwendung blockiert wurde.
timeout
Zeigt an, dass die Frist für das Senden einer Antwort durch die Anwendung abgelaufen ist.

Die Angabe "error_code" ist optional. Wenn Sie nichts festlegen, ist die angegebene Datei die standardmäßige Fehlerantwort für Ihre Anwendung.

file
Jeder Eintrag mit "file" gibt eine statische Datei an, die anstelle der allgemeinen Fehlerantwort bereitgestellt werden soll. Wenn Sie ein file-Element ohne entsprechendes error_code-Element angeben, wird die statische Datei als Standardfehlerseite für Ihre Anwendung verwendet. Die benutzerdefinierten Fehlerdaten müssen kleiner als 10 KB sein.
Beispiel

error_handlers:
  - file: default_error.html

  - error_code: over_quota
    file: over_quota.html
handlers

Erforderlich: Eine Liste mit URL-Mustern und Beschreibungen ihrer Verarbeitung. In App Engine können URLs auf zwei Arten verarbeitet werden: durch Ausführung von Anwendungscode oder durch Bereitstellung von statischen Dateien, die mit dem Code hochgeladen wurden, z. B. Bilder, CSS- oder JavaScript-Dateien.

Siehe Syntax von Handlern und Unterelementen

includes

Optional. Mit der Anweisung includes können Sie die Konfigurationsdatei für jede Bibliothek oder jeden Dienst in Ihrer Anwendung hinzufügen. Hier ein Beispiel mit einer Nutzerverwaltungsbibliothek:


includes:
- lib/user_admin.yaml

App Engine löst den enthaltenen Pfad in dieser Reihenfolge auf:

  • Absoluter oder relativer Pfad zum Arbeitsverzeichnis. Der angegebene Pfad wird in eine Datei aufgelöst.
  • Relativ zum Anwendungsverzeichnis. Dies wird auch als Basispfad bezeichnet. Basispfad und Pfad werden in eine Datei aufgelöst.
  • Relativ zur Datei, die die aktuelle Datei enthält. Der Speicherort der verweisenden Datei und der include-Pfad werden in die enthaltene Datei aufgelöst.

Wenn die include-Anweisung ein Verzeichnis angibt, sucht App Engine in diesem Verzeichnis nach einer Datei namens include.yaml. Wenn die include-Anweisung eine Datei ist, dann wird diese spezielle Datei hinzugefügt. Mit includes werden nur die folgenden Anweisungstypen aus der Zieldatei abgerufen (falls vorhanden):

Enthaltene skip_files-Muster werden entweder Mustern in der Datei app.yamloder der Standardliste hinzugefügt, wenn in app.yaml keine explizite Liste vorhanden ist. Beachten Sie, dass skip_files absolute Pfade vergleicht.

inbound_services

Optional. Anwendungen müssen diese Dienste aktivieren, damit sie eingehende Anfragen empfangen können. Sie können den Dienst für eine Python 2-Anwendung aktivieren, indem Sie in der Datei app.yaml einen Abschnitt inbound_services einfügen.

Die folgenden eingehenden Dienste sind verfügbar:

mail
Ermöglicht Ihrer Anwendung, E-Mails zu empfangen.
warmup
Aktiviert Aufwärmanfragen. Siehe Aufwärmanfragen konfigurieren.
Beispiel:

inbound_services:
  - mail
  - warmup
instance_class

Optional. Die Instanzklasse für diesen Dienst.

Die Verfügbarkeit folgender Werte hängt von der Skalierung Ihres Dienstes ab:

Autoscaling
F1, F2, F4, F4_1G
Standard: F1

Optional können Sie mit dem Element automatic_scaling die Standardeinstellungen für das Autoscaling ändern, z. B. Mindest- und Höchstzahl von Instanzen, Latenz und gleichzeitige Verbindungen.

Hinweis: Wenn instance_class auf F2 oder höher eingestellt ist, können Sie Ihre Instanzen optimieren, indem Sie max_concurrent_requests auf einen höheren Wert als den Standardwert von 10 setzen. Zum Ermitteln des optimalen Werts erhöhen Sie ihn schrittweise und überwachen die Leistung Ihrer Anwendung.

Einfache und manuelle Skalierung
B1, B2, B4, B4_1G, B8
Standard: B2

Bei einfachen und manuellen Instanzklassen muss entweder das Element basic_scaling oder das Element manual_scaling angegeben werden.

libraries

Optional. Die Python 2.7-Laufzeit enthält einige Bibliotheken von Drittanbietern. Einige davon sind standardmäßig verfügbar. Andere sind nur verfügbar, wenn sie konfiguriert wurden. Sie können angeben, welche Version Sie verwenden möchten. Dazu geben Sie die Werte name und version an.

Dieses Feld wird in der Python 3-Laufzeit verworfen.


libraries:
- name: PIL
  version: "1.1.7"
- name: webob
  version: "latest"
        

Beachten Sie, dass das SDK die neueste Bibliotheksversion zum Zeitpunkt der Bereitstellung bestimmt, wenn Sie latest angeben. Die Bibliotheksversion ändert sich nach der Bereitstellung nicht. Die einzige Möglichkeit, eine andere Version der Bibliothek zu erhalten, ist eine erneute Bereitstellung.

Wenn Sie eine Anwendung entwickeln, für die noch keine Nutzer vorhanden sind, brauchen Sie neue Versionen nicht zu kontrollieren. Wenn Ihre Anwendung jedoch aktiv genutzt wird, seien Sie vorsichtig: Möglicherweise stellen Sie überrascht fest, dass Ihre Anwendung beginnt, eine neue, nicht abwärtskompatible Version der Bibliothek zu verwenden.

Eine Liste der enthaltenen Bibliotheken von Drittanbietern finden Sie unter Integrierte Drittanbieterbibliotheken. Sie können zusätzliche reine Python-Drittanbieterbibliotheken verwenden, wenn Sie sie in einem lokalen Verzeichnis installieren.

Wenn Sie die flexible Umgebung verwenden, finden Sie weitere Informationen unter Python-Bibliotheken verwenden.

module

Hinweis: Module werden jetzt als Dienste bezeichnet.

Wenn Sie die Anwendung mit dem gcloud-Tool verwalten möchten, verwenden Sie stattdessen das Element service.

Für die Verwendung des appcfg-Tools müssen Dienste in app.yaml-Dateien als Module deklariert werden. Beispiel:


module: service-name

Erforderlich, wenn Sie einen Dienst erstellen. Optional für den Standarddienst default. Jeder Dienst und jede Version muss einen Namen haben. Ein Name kann Zahlen, Buchstaben und Bindestriche enthalten. Dienst- und Versionsname dürfen insgesamt nicht mehr als 63 Zeichen enthalten und beide Namen dürfen weder mit einem Bindestrich beginnen noch enden. Wählen Sie für jeden Dienst und jede Version einen eindeutigen Namen. Verwenden Sie nicht dieselben Namen für Dienste und Versionen.

runtime

Erforderlich: Der Name der Laufzeitumgebung, die von Ihrer Anwendung verwendet wird. Verwenden Sie Folgendes, um Python 2.7 anzugeben:


runtime: python27
service

Dienste wurden früher als Module bezeichnet.

Wird nur vom gcloud-Tool oder von Cloud SDK-basierten Plug-ins unterstützt, wie z. B. gcloud app deploy.

Informationen zur Verwendung des appcfg-Tools finden Sie unter "module".

Erforderlich, wenn Sie einen Dienst erstellen. Optional für den Standarddienst default. Jeder Dienst und jede Version muss einen Namen haben. Ein Name kann Zahlen, Buchstaben und Bindestriche enthalten. Dienst- und Versionsname dürfen insgesamt nicht mehr als 63 Zeichen enthalten und beide Namen dürfen weder mit einem Bindestrich beginnen noch enden. Wählen Sie für jeden Dienst und jede Version einen eindeutigen Namen. Verwenden Sie nicht dieselben Namen für Dienste und Versionen.

Beispiel:

service: service-name

Hinweis: Der Befehl gcloud app deploy ist abwärtskompatibel und unterstützt vorhandene app.yaml-Dateien, die als Module deklarierte Dienste enthalten. Beispiel:


module: service-name
skip_files

Optional. Mit dem Element skip_files wird angegeben, welche Dateien im Anwendungsverzeichnis nicht in App Engine hochgeladen werden sollen. Bei dem Wert handelt es sich entweder um einen regulären Ausdruck oder eine Liste mit regulären Ausdrücken. Jeder mit einem regulären Ausdruck übereinstimmende Dateiname wird beim Hochladen der Anwendung in der Liste der hochzuladenden Dateien ausgelassen. Dateinamen beziehen sich auf das Projektverzeichnis.

Für skip_files gilt folgender Standard:


skip_files:
- ^(.*/)?#.*#$
- ^(.*/)?.*~$
- ^(.*/)?.*\.py[co]$
- ^(.*/)?.*/RCS/.*$
- ^(.*/)?\..*$

Das Standardmuster schließt Folgendes aus: Emacs-Sicherungsdateien mit den Namensmustern #...# und ...~, .pyc- und .pyo-Dateien, Dateien in einem RCS-Versionskontrollverzeichnis sowie versteckte Unix-Dateien, deren Namen mit einem Punkt beginnen (.).

Wenn Sie die obige Liste regulärer Ausdrücke erweitern möchten, kopieren Sie sie in die Datei app.yaml und fügen Sie eigene reguläre Ausdrücke hinzu. Wenn Sie beispielsweise Dateien überspringen möchten, deren Namen zusätzlich zu den Standardmustern auf .bak enden, fügen Sie skip_files einen Eintrag wie diesen hinzu:


skip_files:
- ^(.*/)?#.*#$
- ^(.*/)?.*~$
- ^(.*/)?.*\.py[co]$
- ^(.*/)?.*/RCS/.*$
- ^(.*/)?\..*$
- ^(.*/)?.*\.bak$

Fügen Sie den Verzeichnisnamen zur Liste hinzu, um ein vollständiges Verzeichnis zu überspringen. Wenn zum Beispiel ein Verzeichnis namens logs übersprungen werden soll, fügen Sie den oben beschriebenen Zeilen diese Zeile hinzu:


skip_files:
- logs/
threadsafe

Erforderlich: Konfiguriert die Anwendung für die Verwendung gleichzeitiger Anfragen. Wenn Sie die Threading-Bibliothek von Python verwenden, werden die von threading.local() zurückgegebenen lokalen Thread-Daten nach jeder Anfrage gelöscht.

Dieses Feld wird in der Python 3-Laufzeit verworfen.


threadsafe: [true | false]

Hinweis: Die Anweisung threadsafe ist für Python 2.7-Anwendungen erforderlich. threadsafe: true erfordert, dass alle Skript-Handler WSGI-Handler sind. Das heißt, jedes Skript muss in einer script:-Anweisung als Python-Modulpfad angegeben werden; Paketnamen werden dabei durch Punkte voneinander getrennt. Die letzte Komponente einer script:-Anweisung als Python-Modulpfad ist der Name einer globalen Variable in service:. Diese Variable muss eine WSGI-Anwendung sein und wird gemäß Konvention normalerweise als app bezeichnet.

version

Es wird empfohlen, das Element version aus der app.yaml-Datei zu entfernen und stattdessen die Anwendungs-ID mit einem Befehlszeilen-Flag anzugeben:

  • Für den Befehl gcloud app deploy geben Sie das Flag -v an:
    
    gcloud app deploy -v [YOUR_VERSION_ID]
  • Für den Befehl appcfg.py update geben Sie das Flag -V an:
    
    appcfg.py update -V [YOUR_VERSION_ID]

Weitere Informationen zur Verwendung dieser Befehle finden Sie unter Anwendung bereitstellen.

Eine Kennzeichnung für die Version Ihres Anwendungscodes, den Sie in App Engine bereitstellen.

Die Versions-ID kann Kleinbuchstaben, Ziffern und Bindestriche enthalten. Sie darf nicht mit dem Präfix ah- beginnen. Außerdem sind die Namen default und latest reserviert und können nicht verwendet werden.

Hinweis: Versionsnamen sollten mit einem Buchstaben beginnen, damit sie sich von numerischen Instanzen unterscheiden, die immer durch eine Zahl angegeben werden. Damit wird das Problem der Mehrdeutigkeit umgangen, das bei URLs wie 123-dot-my-service.uc.r.appspot.com vorliegt. Diese URL kann nämlich auf zwei Arten interpretiert werden: Wenn die Version "123" existiert, ist das Ziel die Version "123" des jeweiligen Dienstes. Existiert diese Version nicht, ist das Ziel die Instanznummer 123 der Standardversion des Dienstes.

Jede Version einer Anwendung behält eine eigene Kopie von app.yaml. Beim Hochladen einer Anwendung ist die Version, die in der hochgeladenen app.yaml-Datei genannt wird, die Version, die durch das Hochladen erstellt wird oder die vorherige Version ersetzt. Ein Administrator kann mithilfe der Google Cloud Console festlegen, welche Version der Anwendung Traffic verarbeitet. Außerdem kann er andere Versionen testen, bevor sie für den Empfang von Traffic konfiguriert werden.

vpc_access_connector

Optional. Konfiguriert Ihre Anwendung für die Verwendung eines Connectors für serverlosen VPC-Zugriff, damit sie Anfragen an interne Ressourcen in Ihrem VPC-Netzwerk senden kann. Geben Sie im Feld name den vollständig qualifizierten Namen eines Connectors an:


vpc_access_connector:
  name: "projects/[PROJECT_ID]/locations/[REGION]/connectors/[CONNECTOR_NAME]"

Weitere Informationen finden Sie unter Verbindung zu einem VPC-Netzwerk herstellen.

Handlers-Element

Das Element handlers ist ein erforderliches Element in der Konfigurationsdatei app.yaml. Es enthält eine Liste von URL-Mustern und Beschreibungen zu deren Verarbeitung. In App Engine können URLs auf zwei Arten verarbeitet werden: durch Ausführung von Anwendungscode oder durch Bereitstellung von statischen Dateien, die mit dem Code hochgeladen wurden, z. B. Bilder, CSS- oder JavaScript-Dateien.

Die Muster werden in der Reihenfolge ausgewertet, in der sie in der Datei app.yaml aufgeführt sind, und zwar von oben nach unten. Die erste mit der URL übereinstimmende Zuordnung wird zum Verarbeiten der Anfrage verwendet.

In der folgenden Tabelle sind die Unterelemente des Elements handlers aufgeführt, die das Verhalten von Skripts, statischen Dateien, statischen Verzeichnissen und anderen Einstellungen steuern.

Element Beschreibung
application_readable Optional. Boolescher Wert. Standardmäßig werden Dateien, die in Handlern statischer Dateien deklariert sind, als statische Daten hochgeladen und ausschließlich Endnutzern bereitgestellt. Sie können nicht von Anwendungen gelesen werden. Wenn dieses Feld auf "true" gesetzt ist, werden die Dateien außerdem als Codedaten hochgeladen, damit Ihre Anwendung sie lesen kann. Beide Uploads werden Ihren Kontingenten für Code- und statische Datenspeicherressourcen angerechnet.

Dieses Feld ist in neueren App Engine-Laufzeiten nicht verfügbar.

auth_fail_action

Optional. Beschreibt die auszuführende Aktion, wenn für einen Handler das Element login angegeben und der Nutzer nicht angemeldet ist. Es gibt zwei mögliche Werte:

redirect
Standard. Der Nutzer wird zur Google Log-in-Seite oder, bei Verwendung der OpenID-Authentifizierung, zu /_ah/login_required weitergeleitet. Nachdem der Nutzer sich angemeldet oder ein Konto erstellt hat, wird er wieder zur Anwendungs-URL zurückgeleitet.
unauthorized
Die Anfrage wird mit dem Statuscode HTTP 401 und einer Fehlermeldung abgelehnt.

Wenn ein anderes Verhalten benötigt wird, können Sie die Verarbeitung von Nutzeranmeldungen in der Anwendung selbst implementieren. Weitere Informationen finden Sie unter Users API.

Im folgenden Beispiel sind eine Anmeldung für das Verzeichnis /profile/ und eine Administratoranmeldung für das Verzeichnis /admin/ erforderlich:


handlers:
- url: /profile/.*
  script: user_profile.app
  login: required

- url: /admin/.*
  script: admin.app
  login: admin

- url: /.*
  script: welcome.app

Sie können einen Handler so konfigurieren, dass der Zugriff auf geschützte URLs verweigert wird, wenn der Nutzer nicht angemeldet ist, statt den Nutzer zur Anmeldeseite weiterzuleiten. Dazu fügen Sie der Konfiguration des Handlers die Anweisung auth_fail_action: unauthorized hinzu:


handlers:
- url: /secure_api/.*
  script: api_handler.app
  login: required
  auth_fail_action: unauthorized
expiration Optional. Die Zeitdauer, für die eine von diesem Handler bereitgestellte statische Datei im Cache von Webproxys und Browsern gespeichert werden soll. Der Wert ist ein String aus Zahlen und Einheiten, die durch Leerzeichen getrennt sind. Als Einheiten können d für Tage, h für Stunden, m für Minuten und s für Sekunden verwendet werden. Beispielsweise legt "4d 5h" den Cache-Ablauf auf 4 Tage und 5 Stunden nach der ersten Anforderung der Datei fest. Wenn kein Wert angegeben ist, wird der Standardwert der Anwendung (default_expiration) verwendet. Weitere Informationen finden Sie unter Cache-Ablauf.
http_headers

Optional. Sie können HTTP-Header für Antworten Ihrer Handler für statische Dateien oder Verzeichnisse festlegen. Wenn Sie HTTP-Header in Ihren script-Handlern festlegen müssen, sollten Sie dies stattdessen im Code der Anwendung tun. Informationen darüber, welche Antwortheader das Caching beeinflussen, finden Sie unter Statische Inhalte im Cache speichern.

Beispiel

handlers:
- url: /images
  static_dir: static/images
  http_headers:
    X-Foo-Header: foo
    X-Bar-Header: bar value
    vary: Accept-Encoding
  # ...

CORS-Unterstützung

Ein wichtiger Nutzen dieser Funktion ist die Unterstützung von Cross-Origin Resource Sharing (CORS), z. B. beim Zugriff auf Dateien, die von einer anderen App Engine-Anwendung gehostet werden.

Sie können beispielsweise eine Spieleanwendung mygame.uc.r.appspot.com haben, die auf von myassets.uc.r.appspot.com gehostete Assets zugreift. Wenn mygame jedoch versucht, ein JavaScript-XMLHttpRequest an myassets zu senden, kann die Anfrage nur erfolgreich sein, wenn der Handler für myassets einen Antwortheader Access-Control-Allow-Origin: mit dem Wert http://mygame.uc.r.appspot.com zurückgibt.

So können Sie dafür sorgen, dass Ihr Handler für statische Dateien den erforderlichen Antwortheaderwert zurückgibt:


handlers:
- url: /images
  static_dir: static/images
  http_headers:
    Access-Control-Allow-Origin: https://mygame.uc.r.appspot.com
  # ...

Hinweis: Wenn Sie allen Nutzern Zugriff auf Ihre Assets gewähren möchten, können Sie anstelle von https://mygame.uc.r.appspot.com den Platzhalter '*' verwenden.

login

Optional. Bestimmt, ob der URL-Handler erfordert, dass der Nutzer angemeldet ist.

Dieses Feld ist in neueren App Engine-Laufzeiten nicht verfügbar.

Dieses Element hat drei mögliche Werte:

optional
Standardeinstellung. Erfordert nicht, dass der Nutzer angemeldet ist.
required
Wenn der Nutzer angemeldet ist, fährt der Handler normal fort. Andernfalls wird die in auth_fail_action angegebene Aktion ausgeführt.
admin
Führt wie bei required die Aktion in auth_fail_action aus, wenn der Nutzer nicht angemeldet ist. Wenn der Nutzer kein Administrator für die Anwendung ist, erhält er unabhängig von der Einstellung für auth_fail_action eine Fehlermeldung. Ist der Nutzer ein Administrator, fährt der Handler fort.

Wenn ein URL-Handler mit einer anderen login-Einstellung als optional eine URL abgleicht, prüft er zuerst, ob sich der Nutzer mithilfe der Authentifizierungsoption bei der Anwendung angemeldet hat. Ist dies nicht der Fall, wird der Nutzer standardmäßig zur Anmeldeseite weitergeleitet. Sie können die Anwendung mithilfe von auth_fail_action auch so konfigurieren, dass Anfragen von nicht ordnungsgemäß authentifizierten Nutzern an einen Handler einfach abgelehnt werden, statt die Nutzer zur Anmeldeseite weiterzuleiten.

Hinweis: Die Anmeldebeschränkung admin wird auch für interne Anfragen erfüllt, für die App Engine entsprechend spezielle X-Appengine-Header festlegt. Mit cron geplante Aufgaben erfüllen beispielsweise die admin-Beschränkung, da App Engine den HTTP-Header X-Appengine-Cron: true für die jeweiligen Anfragen festlegt. Die Anfragen erfüllen jedoch nicht die Anmeldebeschränkung required, da mit "cron" geplante Aufgaben nicht im Namen von Nutzern ausgeführt werden.

mime_type

Optional. Wenn angegeben, werden alle von diesem Handler bereitgestellten Dateien unter Verwendung des genannten MIME-Typs bereitgestellt. Wenn keine Angabe gemacht wurde, wird der MIME-Typ für eine Datei von der jeweiligen Dateiendung abgeleitet. Wenn dieselbe Datei mit mehreren Dateiendungen hochgeladen wird, kann die resultierende Endung von der Reihenfolge abhängen, in der die Uploads erfolgt sind.

Weitere Informationen zu den möglichen MIME-Medientypen finden Sie auf der IANA-Website für MIME-Medientypen.

redirect_http_response_code

Optional. redirect_http_response_code wird mit der Einstellung secure verwendet, um den HTTP-Antwortcode festzulegen, der zurückgegeben wird, wenn eine Weiterleitung gemäß Konfiguration der Einstellung secure erforderlich ist. Das Element redirect_http_response_code kann folgende Werte haben:

301
Antwortcode: Moved Permanently
302
Antwortcode: Found
303
Antwortcode: See Other
307
Antwortcode: Temporary Redirect
Beispiel

handlers:
- url: /youraccount/.*
  script: accounts.app
  login: required
  secure: always
  redirect_http_response_code: 301

Wenn eine Nutzeranfrage umgeleitet wird, wird der HTTP-Statuscode auf den Wert des Parameters redirect_http_response_code gesetzt. Wenn der Parameter nicht vorhanden ist, wird "302" zurückgegeben.

script

Optional. Gibt den Pfad zum Skript aus dem Stammverzeichnis der Anwendung an:


handlers:
# The root URL (/) is handled by the WSGI application named
# "app" in home.py. No other URLs match this pattern.
- url: /
  script: home.app

# The URL /index.html is also handled by the home.py script.
- url: /index\.html
  script: home.app

# A regular expression can map parts of the URL to the
# path of the script.
- url: /browse/(books|videos|tools)
  script: \1.catalog.app

# All other URLs use the WSGI application named in "app"
# in not_found.py.
- url: /.*
  script: not_found.app

Die Anweisung script: muss ein Python-Importpfad wie package.module.app sein, der auf eine WSGI-Anwendung verweist. Die letzte Komponente einer script:-Anweisung als Python-Modulpfad ist der Name einer globalen Variable im Modul: Diese Variable muss eine WSGI-Anwendung sein und wird gemäß Konvention normalerweise als app bezeichnet.

Hinweis: Wie bei einer Python-import-Anweisung muss jedes Unterverzeichnis, das ein Paket ist, eine Datei namens __init__.py enthalten.

In neueren App Engine-Laufzeiten hat sich das Verhalten dieses Feldes geändert.

secure Optional. Die Einstellung secure kann von jedem URL-Handler verwendet werden. Dazu zählen auch Skript-Handler und Handler für statische Dateien. Das Element secure kann folgende Werte haben:
optional
Sowohl HTTP- als auch HTTPS-Anfragen mit URLs, die dem Handler entsprechen, sind ohne Weiterleitungen erfolgreich. Die Anwendung kann die Anfrage untersuchen, um zu ermitteln, welches Protokoll verwendet wurde, und dann entsprechend reagieren. Dies ist die Standardeinstellung, wenn secure für einen Handler nicht angegeben wurde.
never
Anfragen für eine URL, die diesem Handler entsprechen und HTTPS verwenden, werden automatisch an die passende HTTP-URL weitergeleitet. Wenn die HTTPS-Anfrage eines Nutzers als HTTP-Anfrage umgeleitet wird, werden die Abfrageparameter aus der Anfrage entfernt. Dies verhindert, dass ein Nutzer versehentlich Abfragedaten, die für eine sichere Verbindung vorgesehen waren, über eine nicht sichere Verbindung sendet.
always
Anfragen für eine URL, die diesem Handler entsprechen und nicht über HTTPS gesendet werden, werden automatisch an die HTTPS-URL mit demselben Pfad weitergeleitet. Die Abfrageparameter werden für die Weiterleitung beibehalten.
Beispiel

handlers:
- url: /youraccount/.*
  script: accounts.app
  login: required
  secure: always

Der Entwicklungs-Webserver unterstützt keine HTTPS-Verbindungen. Der Parameter secure wird ignoriert, sodass Pfade, die für die Nutzung mit HTTPS vorgesehen sind, über normale HTTP-Verbindungen zum Entwicklungs-Webserver getestet werden können.

Wenn Sie mithilfe der Domain REGION_ID.r.appspot.com auf eine bestimmte Version der Anwendung verweisen möchten, ersetzen Sie die Punkte, mit denen normalerweise die Subdomainkomponenten der URL getrennt werden, durch den String "-dot-", z. B.:
https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com

Zur Verwendung von benutzerdefinierten Domains mit HTTPS müssen Sie zuerst SSL-Zertifikate für diese Domain aktivieren und konfigurieren.

An- und Abmeldungen in bzw. von Google-Konten erfolgen unabhängig von der Konfiguration der Anwendungs-URLs immer über sichere Verbindungen.

static_dir

Optional. Der Pfad zum Verzeichnis mit den statischen Dateien, ausgehend vom Stammverzeichnis der Anwendung. Alle Informationen nach dem Ende des übereinstimmenden url-Musters werden an static_dir angehängt, um den vollständigen Pfad zur angeforderten Datei zu bilden.

Jede Datei im statischen Verzeichnis wird mit dem MIME-Typ bereitgestellt, der der jeweiligen Dateiendung entspricht, sofern er nicht durch die Einstellung mime_type des Verzeichnisses überschrieben wird. Alle Dateien im angegebenen Verzeichnis werden als statische Dateien hochgeladen und keine davon kann als Skript ausgeführt werden.

Alle Dateien in diesem Verzeichnis werden mit Ihrer Anwendung als statische Dateien hochgeladen. Statische Dateien werden von App Engine getrennt von den Dateien Ihrer Anwendung gespeichert und bereitgestellt. Statische Dateien sind im Dateisystem der Anwendung nicht standardmäßig verfügbar. Setzen Sie die Option application_readable auf "true", um dies zu ändern.

Beispiel:

handlers:
# All URLs beginning with /stylesheets are treated as paths to
# static files in the stylesheets/ directory.
- url: /stylesheets
  static_dir: stylesheets
  # ...
static_files

Optional. Ein Handler für Muster statischer Dateien verknüpft ein URL-Muster mit Pfaden zu statischen Dateien, die mit der Anwendung hochgeladen werden. Mit dem regulären Ausdruck des URL-Musters können Gruppierungen regulärer Ausdrücke definiert werden, die beim Erstellen des Dateipfads verwendet werden sollen. Dies stellt eine Alternative zur Verwendung von static_dir dar, um bestimmte Dateien in einer Verzeichnisstruktur zuzuordnen, ohne dass das gesamte Verzeichnis zugeordnet wird.

Beispiel:

handlers:
# All URLs ending in .gif .png or .jpg are treated as paths to
# static files in the static/ directory. The URL pattern is a
# regular expression, with a grouping that is inserted into the
# path to the file.
- url: /(.*\.(gif|png|jpg))$
  static_files: static/\1
  upload: static/.*\.(gif|png|jpg)$
  # ...

Statische Dateien werden von App Engine getrennt von Anwendungsdateien gespeichert und bereitgestellt. Standardmäßig sind statische Dateien im Dateisystem der Anwendung nicht verfügbar. Setzen Sie die Option application_readable auf "true", um dies zu ändern.

Statische Dateien und Anwendungscodedateien dürfen nicht übereinstimmen. Wenn ein Pfad zu statischen Dateien mit einem Pfad zu einem Skript übereinstimmt, das von einem dynamischen Handler verwendet wird, kann der dynamische Handler nicht auf das Skript zugreifen.

upload

Optional. Ein regulärer Ausdruck, der mit den Dateipfaden aller Dateien übereinstimmt, auf die von diesem Handler verwiesen wird. Dies ist erforderlich, da mit dem Handler nicht ermittelt werden kann, welche Dateien im Anwendungsverzeichnis mit den angegebenen url- und static_files-Mustern übereinstimmen. Statische Dateien werden getrennt von Anwendungsdateien hochgeladen und verarbeitet. In obigem Beispiel könnte das folgende upload-Muster verwendet werden: archives/(.*)/items/(.*).

url

Erforderliches Element unter handlers. Das URL-Muster als regulärer Ausdruck. Der Ausdruck kann Gruppierungen enthalten, auf die im Dateipfad zum Skript mit Rückverweisen auf den regulären Ausdruck verwiesen wird. /profile/(.*)/(.*) stimmt zum Beispiel mit der URL /profile/edit/manager überein. edit und manager entsprechen dabei der ersten bzw. zweiten Gruppierung.

Das URL-Muster verhält sich etwas anders, wenn es mit den folgenden Elementen verwendet wird:

static_dir
Verwendet ein URL-Präfix. Das Muster des regulären Ausdrucks darf keine Gruppierungen enthalten, wenn es mit dem Element static_dir verwendet wird. Alle URLs, die mit diesem Präfix beginnen, werden von diesem Handler verarbeitet. Dabei wird der Teil der URL nach dem Präfix als Bestandteil des Dateipfads verwendet.
static_files
Ein Handler für Muster statischer Dateien verknüpft ein URL-Muster mit Pfaden zu statischen Dateien, die mit der Anwendung hochgeladen werden. Mit dem regulären Ausdruck des URL-Musters können Gruppierungen regulärer Ausdrücke definiert werden, die beim Erstellen des Dateipfads verwendet werden sollen. Dies stellt eine Alternative zur Verwendung von static_dir dar, um bestimmte Dateien in einer Verzeichnisstruktur zuzuordnen, ohne dass das gesamte Verzeichnis zugeordnet wird.

Elemente skalieren

Mit den Elementen in der folgenden Tabelle konfigurieren Sie, wie Ihre Anwendung skaliert wird. Weitere Informationen zur Skalierung von App Engine-Anwendungen finden Sie unter Skalierungstypen.

Element Beschreibung
automatic_scaling

Optional. Gilt nur für Anwendungen, die eine Instanzklasse von F1 oder höher verwenden.

Geben Sie dieses Element an, um die Standardeinstellungen für Autoscaling zu ändern, z. B. Mindest- und Höchstwerte für die Anzahl der Instanzen, Latenz und gleichzeitige Verbindungen für einen Dienst.

Dieses Element kann folgende Elemente enthalten:

max_instances
Optional. Geben Sie einen Wert zwischen 0 und 2.147.483.647 an, wobei 0 die Einstellung deaktiviert.

Dieser Parameter gibt die maximale Anzahl der Instanzen an, die von App Engine für diese Modulversion erstellt werden sollen. Dies ist nützlich, um die Kosten eines Moduls zu begrenzen.

Wichtig: Wenn Sie für die Bereitstellung "appcfg" aus dem App Engine SDK für Python 2 verwenden, können Sie diesen Parameter nicht in Ihrer Datei app.yaml nutzen. Geben Sie stattdessen den Parameter wie unter Autoscaling-Parameter mit dem API Explorer festlegen beschrieben oder mithilfe der App Engine Admin API an.

min_instances
Optional. Die Mindestanzahl der Instanzen, die von App Engine für diese Modulversion erstellt werden sollen. Diese Instanzen arbeiten den Traffic ab, wenn Anfragen eintreffen. Sie arbeiten den Traffic auch dann weiter ab, wenn zusätzliche Instanzen gestartet werden, die für die Verarbeitung des Traffics erforderlich sind.

Geben Sie einen Wert zwischen 0 und 1.000 an. Sie können den Parameter auf den Wert 0 setzen, um eine Skalierung auf 0 Instanzen zu ermöglichen und die Kosten zu senken, wenn gerade keine Anfragen verarbeitet werden. Ihnen wird die angegebene Anzahl von Instanzen in Rechnung gestellt, unabhängig davon, ob sie Traffic empfangen oder nicht.

Wichtig: Wenn Sie für die Bereitstellung "appcfg" aus dem App Engine SDK für Python 2 verwenden, können Sie diesen Parameter nicht in Ihrer Datei app.yaml nutzen. Geben Sie stattdessen den Parameter wie unter Autoscaling-Parameter mit dem API Explorer festlegen beschrieben oder mithilfe der App Engine Admin API an.

max_idle_instances

Optional. Die maximale Anzahl inaktiver Instanzen, die App Engine für diese Version beibehalten soll. Geben Sie einen Wert zwischen 1 und 1.000 oder automatic an. Der Standardwert ist automatic. Beachten Sie Folgendes:

  • Ein hoher Höchstwert führt dazu, dass die Anzahl inaktiver Instanzen bei der Rückkehr zum normalen Lastniveau nach einem Lastanstieg langsamer reduziert wird. Dies ermöglicht der Anwendung, bei einem schwankenden Anfrageaufkommen gleichbleibend hohe Leistung zu erbringen. Allerdings erhöhen sich dadurch in Zeiträumen hoher Auslastung auch die Anzahl inaktiver Instanzen und die sich daraus ergebenden laufenden Kosten.
  • Mit einem niedrigen Höchstwert sind die laufenden Kosten niedriger. Schwankende Lastniveaus können dann jedoch zu Leistungseinbußen führen.

Hinweis: Wenn nach einem Lastanstieg wieder das normale Lastniveau erreicht wird, kann die Anzahl inaktiver Instanzen vorübergehend über dem angegebenen Höchstwert liegen. Es werden Ihnen jedoch nicht mehr Instanzen als die von Ihnen angegebene maximale Anzahl berechnet.

min_idle_instances

Optional. Die Anzahl der zusätzlichen Instanzen, die weiter ausgeführt werden und für die Verarbeitung von Traffic für diese Version bereitstehen sollen.

App Engine berechnet die Anzahl der Instanzen, die zum Verarbeiten des aktuellen Anwendungstraffics erforderlich sind, basierend auf Skalierungseinstellungen wie target_cpu_utilization und target_throughput_utilization. Mit der Einstellung min_idle_instances wird die Anzahl der Instanzen festgelegt, die zusätzlich zu dieser berechneten Anzahl ausgeführt werden sollen. Wenn App Engine beispielsweise berechnet, dass 5 Instanzen zum Verarbeiten von Traffic erforderlich sind, und min_idle_instances auf 2 eingestellt ist, werden von App Engine 7 Instanzen ausgeführt (5 berechnet auf der Grundlage von Traffic plus 2 weitere pro min_idle_instances).

Ihnen wird die angegebene Anzahl von Instanzen in Rechnung gestellt, unabhängig davon, ob sie Traffic empfangen oder nicht. Diese Einstellung gilt nur für die Version, die den Großteil des Traffics empfängt. Beachten Sie Folgendes:

  • Ein niedriger Mindestwert ermöglicht Ihnen, die laufenden Kosten bei Inaktivität gering zu halten, sorgt aber möglicherweise auch dafür, dass bei einem plötzlichen Anstieg des Lastniveaus weniger Instanzen unmittelbar verfügbar sind.
  • Ein hoher Mindestwert ermöglicht Ihnen, die Anwendung auf sprunghafte Anstiege des Lastniveaus vorzubereiten. App Engine führt die Mindestanzahl von Instanzen für die Verarbeitung eingehender Anfragen aus. Unabhängig davon, ob sie Anfragen verarbeiten oder nicht, wird Ihnen die Anzahl der angegebenen Instanzen berechnet.

    Wenn Sie eine Mindestanzahl inaktiver Instanzen festlegen, wirkt sich die Latenzzeit der Warteschlange für ausstehende Anfragen weniger stark auf die Leistung der Anwendung aus.

target_cpu_utilization
Optional. Geben Sie einen Wert zwischen 0,5 und 0,95 an. Der Standardwert ist 0.6.

Dieser Parameter gibt den Schwellenwert für die CPU-Auslastung an, ab dem neue Instanzen zur Verarbeitung des Traffics gestartet werden. Dadurch erreichen Sie ein ausgeglichenes Kosten-Leistungs-Verhältnis, denn bei niedrigeren Werten werden Leistung und Kosten erhöht und bei höheren Werten wird die Leistung verringert, aber es werden auch die Kosten gesenkt. Ein Wert von 0,7 bedeutet beispielsweise, dass neue Instanzen gestartet werden, sobald die CPU-Auslastung 70 % erreicht hat.

Wichtig: Wenn Sie für die Bereitstellung das appcfg-Tool aus dem App Engine SDK für Python 2 verwenden, können Sie diesen Parameter nicht in der Datei app.yaml nutzen. Geben Sie stattdessen den Parameter wie unter Autoscaling-Parameter mit dem API Explorer festlegen beschrieben oder mithilfe der App Engine Admin API an.

target_throughput_utilization
Optional. Geben Sie einen Wert zwischen 0,5 und 0,95 an. Der Standardwert ist 0.6.

Wird mit max_concurrent_requests verwendet, um festzulegen, wann eine neue Instanz aufgrund von gleichzeitigen Anfragen gestartet wird. Wenn die Anzahl gleichzeitiger Anfragen den Wert max_concurrent_requests mal target_throughput_utilization erreicht, versucht der Planer, eine neue Instanz zu starten.

Wichtig: Wenn Sie für die Bereitstellung das appcfg-Tool aus dem App Engine SDK für Python 2 verwenden, können Sie diesen Parameter nicht in der Datei app.yaml nutzen. Geben Sie stattdessen den Parameter wie unter Autoscaling-Parameter mit dem API Explorer festlegen beschrieben oder mithilfe der App Engine Admin API an.

max_concurrent_requests

Optional. Die Anzahl gleichzeitiger Anfragen, die eine Instanz mit automatischer Skalierung annehmen kann, bevor der Planer eine neue Instanz erstellt (Standardeinstellung: 10, Höchstwert: 80).

Wird mit target_throughput_utilization verwendet, um anzugeben, wann eine neue Instanz aufgrund von gleichzeitigen Anfragen gestartet wird. Wenn die Anzahl gleichzeitiger Anfragen den Wert max_concurrent_requests mal target_throughput_utilization erreicht, versucht der Planer, eine neue Instanz zu starten.

Wir empfehlen, max_concurrent_requests nicht auf einen Wert unter 10 zu setzen, es sei denn, Sie benötigen ein Einzel-Threading. Ein Wert unter 10 führt wahrscheinlich dazu, dass mehr Instanzen erstellt werden, als für eine threadsichere Anwendung erforderlich sind. Dies kann zu unnötigen Kosten führen.

Wenn diese Einstellung zu hoch ist, kann es zu einer erhöhten API-Latenz kommen. Der Planer erzeugt möglicherweise eine neue Instanz, bevor die maximal zulässige Anzahl an Anfragen erreicht wird.

max_pending_latency

Der Zeitraum, den eine Anfrage maximal in der Warteschlange für ausstehende Anfragen verbleiben kann, bevor App Engine zusätzliche Instanzen zur Verarbeitung von Anfragen startet, um die Latenzzeit für ausstehende Anfragen zu reduzieren. Wenn dieser Schwellenwert erreicht wird, gilt das als Signal zum Hochskalieren und die Anzahl der Instanzen wird erhöht. Der Standardwert ist 30ms.

Ein niedriger Höchstwert bedeutet, dass App Engine zum Verarbeiten ausstehender Anfragen schneller neue Instanzen startet. Dadurch wird zwar die Leistung verbessert, doch die laufenden Kosten steigen ebenfalls.

Ein hoher Höchstwert bedeutet, dass Nutzer möglicherweise länger auf die Verarbeitung ihrer Anfragen warten müssen, wenn ausstehende Anfragen, aber keine inaktiven Instanzen vorhanden sind. Allerdings fallen dadurch weniger Kosten für die Ausführung Ihrer Anwendung an.

min_pending_latency

Ein optionales Element, mit dem Sie festlegen können, wie lange eine Anfrage in App Engine mindestens in der Warteschlange warten muss, bevor eine neue Instanz gestartet wird. Durch Angabe eines Werts können Sie zwar die Ausführungskosten reduzieren, aber Nutzer müssen länger auf die Verarbeitung ihrer Anfragen warten.

Bei kostenlosen Anwendungen ist der Standardwert 500ms. Bei kostenpflichtigen Anwendungen ist der Standardwert 0.

Dieses Element ermittelt zusammen mit dem Element max_pending_latency, wann App Engine neue Instanzen erstellt. Wenn sich ausstehende Anfragen in der Warteschlange befinden, gilt Folgendes:

  • Wenn der Wert niedriger als der von Ihnen angegebene Wert für min_pending_latency ist, erstellt App Engine keine neuen Instanzen.
  • Wenn der Wert höher als max_pending_latency ist, versucht App Engine, eine neue Instanz zu erstellen.
  • Wenn der Wert zwischen min_pending_latency und max_pending_latency liegt, versucht App Engine, eine vorhandene Instanz wiederzuverwenden. Wenn keine Instanzen die Anfrage vor max_pending_latency verarbeiten können, erstellt App Engine eine neue Instanz.
Beispiel

automatic_scaling:
  target_cpu_utilization: 0.65
  min_instances: 5
  max_instances: 100
  min_pending_latency: 30ms
  max_pending_latency: automatic
  max_concurrent_requests: 50
basic_scaling

Für Anwendungen, die eine Instanzklasse B1 oder höher verwenden, muss entweder dieses Element oder manual_scaling angegeben werden.

Dieses Element ermöglicht die einfache Skalierung von Instanzklassen des Typs B1 und höher. Es kann die folgenden Elemente enthalten:

max_instances
Erforderlich. Die maximale Anzahl von Instanzen, die App Engine für diese Dienstversion erstellen soll. Diese Beschränkung ist nützlich, um die Kosten eines Dienstes zu begrenzen.
idle_timeout
Optional. Gibt an, nach welcher Zeit ab Erhalt der letzten Anfrage die Instanz heruntergefahren wird. Die Standardeinstellung beträgt 5 Minuten (5m).
Beispiel:

basic_scaling:
  max_instances: 11
  idle_timeout: 10m
manual_scaling

Für Anwendungen, die eine Instanzklasse B1 oder höher verwenden, muss entweder dieses Element oder basic_scaling angegeben werden.

Dieses Element ermöglicht die manuelle Skalierung von Instanzklassen des Typs B1 und höher. Es kann die folgenden Elemente enthalten:

instances
Die Anzahl der Instanzen, die dem Dienst beim Start zugewiesen werden.
Beispiel

manual_scaling:
  instances: 5