Referenz zur App Engine-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. Bei Anwendungen, die nach Februar 2020 erstellt wurden, ist REGION_ID.r in den App Engine-URLs enthalten. Bei Anwendungen, die vor diesem Datum erstellt wurden, ist die Regions-ID in der URL optional.

Hier finden Sie weitere Informationen zu Regions-IDs.

Die Einstellungen einer App Engine-Anwendung werden in der Konfigurationsdatei app.yaml konfiguriert. In der Konfigurationsdatei muss mindestens ein runtime-Eintrag angegeben sein.

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. Weitere Informationen zum Strukturieren mehrerer Dienste in Ihrer Anwendung finden Sie unter Konfigurationsdateien.

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.

Beispiel

Im Folgenden finden Sie ein Beispiel für eine app.yaml-Datei:

Laufzeit- und Anwendungselemente

Element	Beschreibung
`app_engine_apis`
`build_env_variables`	Optional. Wenn Sie eine Laufzeit verwenden, die Buildpacks unterstützt, können Sie Build-Umgebungsvariablen in der Datei `app.yaml` definieren. Weitere Informationen finden Sie unter Build-Umgebungsvariablen verwenden.
`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. Weitere Informationen finden Sie unter Cache-Ablauf.
`entrypoint`
`env_variables`	Optional. Sie können Umgebungsvariablen in Ihrer `app.yaml`-Datei definieren, um sie Ihrer Anwendung zur Verfügung zu stellen. Achten Sie darauf, dass der Schlüssel in Umgebungsvariablen mit dem Ausdruck "[a-zA-Z_][a-zA-Z0-9_]*" übereinstimmt (mit einem Buchstaben oder "_" beginnen, gefolgt von einem alphanumerischen Zeichen oder "_"). Umgebungsvariablen mit dem Präfix `GAE` sind für die Verwendung durch das System reserviert und in der Datei `app.yaml` nicht zulässig.
`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. `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. Warnung: Der Pfad zur Fehlerantwortdatei darf sich nicht mit den Handler-Pfaden für statische Dateien überschneiden. 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`	Optional. 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
`inbound_services`	Optional. Anwendungen müssen diese Dienste aktivieren, damit sie eingehende Anfragen empfangen können. Sie können den Dienst für eine Anwendung aktivieren, indem Sie in der Datei `app.yaml` den Abschnitt `inbound_services` einfügen. `warmup` Aktiviert Warmup-Anfragen. Siehe Aufwärmanfragen konfigurieren Beispiel: inbound_services: - 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.
`main`	Optional. Für Go der Pfad oder der vollständig qualifizierte Paketname des Hauptpakets. Diese Einstellung gilt nur, wenn Ihre Anwendung den Go-Modulmodus verwendet. Sie müssen den Pfad zum Hauptpaket angeben, wenn `package main` sich nicht im selben Verzeichnis wie Ihre `app.yaml`-Datei befindet. Das `main`-Element unterstützt Dateipfade, die relativ zu `app.yaml` oder vollständigen Paketnamen sind. Wenn Ihre App beispielsweise folgende Verzeichnisstruktur hat: myapp/ ├── app.yaml ├── go.mod ├── cmd │ └── web │ └── main.go └── pkg └── users └── users.go Dann verwenden Sie entweder main: ./cmd/web oder main: example.com/myapp/cmd/web
`runtime`	Erforderlich. Der Name der Laufzeitumgebung, die von der Anwendung verwendet wird. So geben Sie beispielsweise die Laufzeitumgebung an:
`service`	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. Die kombinierte Länge von `VERSION-dot-SERVICE-dot-PROJECT_ID`, wobei `VERSION` der Name Ihrer Version ist, `SERVICE` der Name des Dienstes ist und `PROJECT_ID` Ihre Projekt-ID ist, darf maximal 63 Zeichen lang sein und nicht mit einem Bindestrich beginnen oder enden. Wählen Sie für jeden Dienst und jede Version einen eindeutigen Namen. Verwenden Sie Namen von Diensten und Versionen nicht doppelt. Beispiel: service: service-name
`service_account`	Optional. Mit dem Element `service_account` können Sie ein versionsspezifisches Dienstkonto als Identität für die Version angeben. Das angegebene Dienstkonto wird verwendet, wenn Sie auf andere Google Cloud-Dienste zugreifen und Aufgaben ausführen. Beispiel: service_account: [SERVICE_ACCOUNT_NAME]@[PROJECT_ID].iam.gserviceaccount.com
`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. Weitere Informationen finden Sie unter Verbindung zu einem VPC-Netzwerk herstellen. `name` Stringliteral. Geben Sie den vollständig qualifizierten Namen Ihres Connectors für serverlosen VPC-Zugriff in Anführungszeichen an: "projects/`PROJECT_ID`/locations/`REGION`/connectors/`CONNECTOR_NAME`" `egress_setting` Optional. Der Standardwert ist `private-ranges-only`. Der Wert für `egress_setting` kann einer der folgenden sein: `private-ranges-only` Standardeinstellung. Anfragen an interne IP-Adressen werden über den Connector für serverlosen VPC-Zugriff an das verbundene VPC-Netzwerk gesendet. Anfragen an externe IP-Adressen werden an das öffentliche Internet gesendet. `all-traffic` Alle Anfragen werden über den Connector für serverlosen VPC-Zugriff an das verbundene VPC-Netzwerk gesendet. Beispiel vpc_access_connector: name: "projects/`PROJECT_ID`/locations/`REGION`/connectors/`CONNECTOR_NAME`" egress_setting: all-traffic

Handlers-Element

Das Element handlers 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 für statische Dateien, statische Verzeichnisse, Skripts in anderen Laufzeiten als Node.js sowie andere Einstellungen steuern.

Element	Beschreibung
`auth_fail_action`	Wenn Sie dieses Element verwenden möchten, muss `app_engine_apis` auf `true` gesetzt sein. 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. Zum Beispiel ist eine Anmeldung für das Verzeichnis `/profile/` oder eine Administratoranmeldung für das Verzeichnis `/admin/` erforderlich. Weitere Informationen finden Sie unter Users API. 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.
`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 den `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. Weitere Informationen zu App Engine-spezifischen Headern finden Sie unter Anfrageheader und Antworten. 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 # ... Tipp: 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`	Wenn Sie dieses Element verwenden möchten, muss `app_engine_apis` auf `true` gesetzt sein. Optional. Bestimmt, ob der URL-Handler erfordert, dass der Nutzer angemeldet ist. 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 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 an, dass Anfragen an den spezifischen Handler auf Ihre Anwendung ausgerichtet werden sollen. Der einzige akzeptierte Wert für das Element `script` ist `auto`, da der gesamte Traffic über den Befehl „entrypoint“ bereitgestellt wird. Damit Sie statische Handler verwenden können, muss mindestens einer Ihrer Handler die Zeile `script: auto` enthalten oder ein `entrypoint`-Element zur Bereitstellung definieren.
`secure`	Optional. Die Einstellung `secure` kann von jedem URL-Handler verwendet werden, einschließlich Handlern 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. 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. 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 und Anwendungscodedateien dürfen nicht übereinstimmen.
`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 Gruppierungen enthalten kann. `/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. Wenn kein Skalierungstyp angegeben ist, wird standardmäßig die automatische Skalierung festgelegt.

Weitere Informationen zur Skalierung von App Engine-Anwendungen finden Sie unter Skalierungstypen.

Element Beschreibung

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. `min_instances` Warnung: Achten Sie darauf, dass Aufwärmanfragen aktiviert sind und Ihre Anwendung Aufwärmanfragen verarbeitet, damit dieses Feature korrekt funktioniert. Hinweis: Diese Einstellung gilt nur, wenn die Version der Anwendung, die in dieser `app.yaml`-Datei definiert ist, für den Empfang konfiguriert ist. Weitere Informationen zum Weiterleiten von Traffic an verschiedene Versionen einer Anwendung finden Sie unter Traffic aufteilen. 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. `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 an. Wenn keine Angabe erfolgt, beträgt der Standardwert `automatic`, was bedeutet, dass App Engine die Anzahl der inaktiven Instanzen verwaltet. 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` Warnung: Achten Sie darauf, dass Aufwärmanfragen aktiviert sind und Ihre Anwendung Aufwärmanfragen verarbeitet, damit dieses Feature korrekt funktioniert. Hinweis: Diese Einstellung gilt nur, wenn die Version der Anwendung, die in dieser `app.yaml`-Datei definiert ist, für den Empfang konfiguriert ist. Weitere Informationen zum Weiterleiten von Traffic an verschiedene Versionen einer Anwendung finden Sie unter Traffic aufteilen. 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. 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. `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. `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: 1000). 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. Wenn keine Angabe erfolgt, beträgt der Standardwert `automatic`. Das bedeutet, dass Anfragen bis zu 10 Sekunden in der Warteschlange für ausstehende Anfragen verbleiben können, das maximale Zeitlimit für ausstehende Anfragen, bevor neue Instanzen ausgelöst werden. 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

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.

min_instances

Hinweis: Diese Einstellung gilt nur, wenn die Version der Anwendung, die in dieser app.yaml-Datei definiert ist, für den Empfang konfiguriert ist. Weitere Informationen zum Weiterleiten von Traffic an verschiedene Versionen einer Anwendung finden Sie unter Traffic aufteilen.

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.

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 an. Wenn keine Angabe erfolgt, beträgt der Standardwert automatic, was bedeutet, dass App Engine die Anzahl der inaktiven Instanzen verwaltet.

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. 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.

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.

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: 1000).

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.

Wenn keine Angabe erfolgt, beträgt der Standardwert automatic. Das bedeutet, dass Anfragen bis zu 10 Sekunden in der Warteschlange für ausstehende Anfragen verbleiben können, das maximale Zeitlimit für ausstehende Anfragen, bevor neue Instanzen ausgelöst werden.

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.