Konfigurationsdatei app.yaml

In der Datei app.yaml sind die Konfigurationseinstellungen für die Laufzeit sowie allgemeine Anwendungs-, Netzwerk- und sonstige Ressourceneinstellungen definiert.

Fügen Sie app.yaml nicht zur Datei .gcloudignore hinzu. app.yaml ist möglicherweise für die Bereitstellung erforderlich und wenn Sie diese Datei zu .gcloudignore hinzufügen, schlägt die Bereitstellung fehl.

Syntax

Die Syntax der Datei app.yaml entspricht dem YAML-Format. Dieses unterstützt Kommentare, wobei Zeilen, die mit dem Rautezeichen (#) beginnen, ignoriert werden. Beispiel:

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

Allgemeine Einstellungen

Eine app.yaml-Datei kann die folgenden allgemeinen Einstellungen enthalten. Einige dieser Einstellungen sind zwingend erforderlich:

Name	Beschreibung
`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.
`runtime`	Erforderlich. Der Name der Laufzeitumgebung, die von der Anwendung verwendet wird. So geben Sie beispielsweise die Laufzeitumgebung an:
`env: flex`	Erforderlich: Wählen Sie die flexible Umgebung aus.
`service: service_name`	Erforderlich, wenn Sie einen Dienst erstellen. Optional für den Standarddienst. Jeder Dienst und jede Version muss einen Namen haben. Ein Name kann aus Zahlen, Buchstaben und Bindestrichen bestehen. In der flexiblen Umgebung darf die kombinierte Länge von `VERSION-dot-SERVICE-dot-PROJECT_ID`, wobei `VERSION` der Name Ihrer Version, `SERVICE` der Name des Dienstes und `PROJECT_ID` ist Ihre Projekt-ID, maximal 63 Zeichen lang sein und darf nicht mit einem Bindestrich beginnen oder enden. Wenn eine Bereitstellung ohne Angabe eines Dienstnamens erfolgt, wird eine neue Version des Standarddienstes erstellt. Wenn eine Bereitstellung mit einem bereits vorhandenen Dienstnamen erfolgt, wird eine neue Version dieses Dienstes erstellt. Wenn eine Bereitstellung mit einem nicht vorhandenen Dienstnamen erfolgt, werden ein neuer Dienst und eine neue Version erstellt. Wir empfehlen, für jede Kombination aus Dienst und Version einen eindeutigen Namen zu verwenden. Hinweis: Dienste wurden bisher als "Module" bezeichnet.
`service_account`	Optional. Mit dem Element `service_account` können Sie ein vom Nutzer verwaltetes 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. Das Dienstkonto muss im folgenden Format angegeben werden: service_account: [SERVICE_ACCOUNT_NAME]@[PROJECT_ID].iam.gserviceaccount.com
`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. Damit beispielsweise Dateien übersprungen werden, deren Namen mit `.bak` enden, fügen Sie einen Abschnitt `skip_files` wie den folgenden hinzu: skip_files: - ^.*\.bak$

Netzwerkeinstellungen

Sie können Netzwerkeinstellungen in der app.yaml-Konfigurationsdatei angeben. Beispiel:

network:
  name: NETWORK_NAME
  instance_ip_mode: INSTANCE_IP_MODE
  instance_tag: TAG_NAME
  subnetwork_name: SUBNETWORK_NAME
  session_affinity: true
  forwarded_ports:
    - PORT
    - HOST_PORT:CONTAINER_PORT
    - PORT/tcp
    - HOST_PORT:CONTAINER_PORT/udp

Mit den folgenden Optionen können Sie die Netzwerkeinstellungen konfigurieren:

Option	Beschreibung
`name`	Jede VM-Instanz in der flexiblen Umgebung wird bei der Erstellung einem Google Compute Engine-Netzwerk zugewiesen. Verwenden Sie diese Einstellung, um einen Netzwerknamen festzulegen. Geben Sie die Kurzform des Namens und nicht den Ressourcenpfad an (z. B. `default` anstatt `https://www.googleapis.com/compute/v1/projects/my-project/global/networks/default`). Wenn Sie keinen Netzwerknamen angeben, werden die Instanzen dem Standardnetzwerk des Projekts (namens `default`) zugewiesen. Wenn Sie den Namen eines Subnetzwerks festlegen möchten, müssen Sie einen Netzwerknamen angeben.
`instance_ip_mode`	Optional. Wenn Instanzen keine sitzungsspezifische externe IP-Adresse erhalten sollen, setzen Sie diese auf `internal` und aktivieren Sie privaten Google-Zugriff. Wenn Ihre Instanz zuvor ohne diese Einstellung oder mit der Einstellung `external` bereitgestellt wurde, werden bei einer erneuten Bereitstellung mit der Einstellung `internal` die sitzungsspezifischen externen IP-Adressen aus Ihren Instanzen entfernt. Für die Einstellung `internal` gelten Einschränkungen. Die Standardeinstellung ist `external`.
`instance_tag`	Optional. Jeder Instanz des Dienstes wird beim Erstellen ein Tag mit diesem Namen zugewiesen. Tags können in `gcloud`-Befehlen hilfreich sein, um eine Aktion für eine Gruppe von Instanzen durchzuführen. Ein Beispiel dafür ist die Verwendung der Flags `--source-tags` und `--target-tags` im Befehl compute firewalls-create. Wenn nicht angegeben, wird die Instanz mit `aef-INSTANCE_ID` gekennzeichnet, wenn die freigegebene VPC nicht verwendet wird. Wenn eine freigegebene VPC verwendet wird, wird die Instanz mit beiden `aef-INSTANCE_ID and aef-instance.` getaggt.
`subnetwork_name`	Optional. Sie können Ihr Netzwerk in Segmente aufteilen und ein benutzerdefiniertes Subnetzwerk verwenden. Achten Sie darauf, dass das Netzwerk `name` angegeben ist. Geben Sie die Kurzform des Namens und nicht den Ressourcenpfad an (z. B. `default` statt `https://www.googleapis.com/compute/v1/projects/my-project/global/networks/default/subnetworks/default`). Das Subnetzwerk muss sich in derselben Region wie die Anwendung befinden.
`session_affinity`	Optional. Setzen Sie diese Option auf `true`, um App Engine so zu konfigurieren, dass mehrere sequenzielle Anfragen für einen bestimmten Nutzer an dieselbe App Engine-Instanz geleitet werden, z. B. wenn Nutzerdaten während einer Sitzung lokal gespeichert werden. Die Sitzungsaffinität ermöglicht es, den Wert eines Cookies zu prüfen, um mehrere Anfragen desselben Nutzers zu identifizieren, und leitet dann alle derartigen Anfragen zur selben Instanz. Wenn die Instanz neu gestartet wird, fehlerhaft, überlastet oder nicht mehr verfügbar ist, nachdem die Anzahl der Instanzen verkleinert wurde, wird die Sitzungsaffinität gestört und weitere Anfragen werden an eine andere Instanz weitergeleitet. Das Aktivieren der Sitzungsaffinität kann sich auf die Einrichtung des Load-Balancings auswirken. Dieser Parameter ist standardmäßig deaktiviert.
`forwarded_ports`	Optional. Sie können Ports von Ihrer Instanz (`HOST_PORT`) an den Docker-Container (`CONTAINER_PORT`) weiterleiten. `HOST_PORT` muss zwischen 1.024 und 65.535 liegen und kann nicht in Konflikt mit den folgenden Ports stehen: 22, 8080, 8090, 8443, 10.000, 10001, 10400-10500, 11211, 24231. `CONTAINER_PORT` muss zwischen 1 und 65.535 liegen und darf keine Konflikte mit den folgenden Ports haben: 22, 10001, 10400-10500, 11211. Wenn Sie nur einen `PORT` angeben, geht App Engine davon aus, dass es sich auf dem Host und dem Container um denselben Port handelt. Standardmäßig wird sowohl TCP- als auch UDP-Traffic weitergeleitet. Der Traffic muss direkt an die IP-Adresse der Zielinstanz und nicht über die Domain appspot.com oder über Ihre benutzerdefinierte Domain geleitet werden.

Erweiterte Netzwerkkonfiguration

Sie können Ihr Compute Engine-Netzwerk in Subnetzwerke aufteilen. Auf diese Weise werden VPN-Szenarien ermöglicht, wie beispielsweise der Zugriff auf Datenbanken in Ihrem Unternehmensnetzwerk.

So aktivieren Sie Subnetzwerke für Ihre App Engine-Anwendung:

Erstellen Sie ein benutzerdefiniertes Subnetzwerk.
Fügen Sie der Datei app.yaml wie oben angegeben den Namen des Netzwerks und des Subnetzwerks hinzu.
Erstellen Sie ein Gateway und einen Tunnel für ein benutzerdefiniertes Subnetz-Netzwerk, um ein einfaches VPN mit statischem Routing einzurichten. Hier finden Sie Informationen zum Erstellen anderer VPN-Typen.

Portweiterleitung

Die Portweiterleitung ermöglicht direkte Verbindungen zum Docker-Container in Ihren Instanzen. Dieser Traffic kann über jedes Protokoll übertragen werden. Die Portweiterleitung soll in Situationen Unterstützung bieten, in denen Sie einen Debugger oder einen Profiler anhängen müssen. Der Traffic muss direkt an die IP-Adresse der Zielinstanz und nicht über die Domain appspot.com oder über Ihre benutzerdefinierte Domain geleitet werden.

Standardmäßig wird von außerhalb Ihres Netzwerks eingehender Traffic von den Google Cloud Platform-Firewalls blockiert. Wenn Sie in der Datei app.yaml die Portweiterleitung festgelegt haben, müssen Sie eine Firewallregel einfügen, die Traffic von den zu öffnenden Ports ermöglicht.

Firewallregeln können in der Google Cloud Console auf der Seite „VPC-Netzwerk“ > „Firewall“ oder mit gcloud-Befehlen festgelegt werden.

So leiten Sie beispielsweise TCP-Traffic von Port 2222 weiter:

Geben Sie in den Netzwerkeinstellungen der app.yaml-Datei Folgendes ein:
```
network:
  forwarded_ports:
    - 2222/tcp
```
1. Wenn Sie die Python-Laufzeit verwenden, ändern Sie app.yaml so:
```
entrypoint: gunicorn -b :$PORT -b :2222 main:app
```
Geben Sie eine Firewallregel in der Google Cloud Console an oder verwenden Sie gcloud compute firewall-rules create, um Traffic von jeder Quelle (0.0.0.0/0) und von tcp:2222 zuzulassen.

Ressourceneinstellungen

Diese Einstellungen steuern die Rechenressourcen. App Engine weist einen Maschinentyp basierend auf den von Ihnen angegebenen CPU- und Arbeitsspeicherwerten zu. Die Maschine hat dann mindestens so viele Ressourcen, wie Sie festgelegt haben, unter Umständen sogar noch mehr.

Sie können in den Ressourceneinstellungen bis zu acht tmpfs-Volumes angeben. Sie haben dann die Möglichkeit, Arbeitslasten zu aktivieren, die einen gemeinsamen Arbeitsspeicher über tmpfs benötigen, und die Dateisystem-E/A zu verbessern.

Beispiel:

resources:
  cpu: 2
  memory_gb: 2.3
  disk_size_gb: 10
  volumes:
  - name: ramdisk1
    volume_type: tmpfs
    size_gb: 0.5

Mit den folgenden Optionen können Sie die Ressourceneinstellungen konfigurieren:

Option	Beschreibung	Standard
`cpu`	Die Anzahl der Kerne; sie muss eins, eine gerade Zahl zwischen 2 und 32 oder ein Vielfaches von 4 zwischen 32 und 80 sein.	1 Kern
`memory_gb`	RAM in GB. Der erforderliche Arbeitsspeicher für Ihre Anwendung ohne ca. 0,4 GB Arbeitsspeicher, der für einige Prozesse benötigt wird. Jeder CPU-Kern benötigt einen Gesamtarbeitsspeicher zwischen 1,0 und 6,5 GB. So berechnen Sie den erforderlichen Arbeitsspeicher: `memory_gb` = `cpu` * [1,0 - 6,5] - 0,4 Für das obige Beispiel, in dem 2 Kerne angegeben wurden, können Sie zwischen 1,6 und 12,6 GB anfordern. Der gesamte für die Anwendung verfügbare Speicher wird von der Laufzeitumgebung durch die Umgebungsvariable `GAE_MEMORY_MB` festgelegt.	0,6 GB
`disk_size_gb`	Größe in GB. Der Mindestwert beträgt 10 GB und der Höchstwert 10.240 GB.	13 GB
`name`	Erforderlich, wenn Volumes verwendet werden. Name des Volume. Namen dürfen nur einmalig vergeben werden und müssen zwischen 1 und 63 Zeichen lang sein. Als Zeichen können Kleinbuchstaben, Ziffern oder Bindestriche verwendet werden. Das erste Zeichen muss ein Buchstabe und das letzte Zeichen darf kein Bindestrich sein. Das Volume wird im Anwendungscontainer als `/mnt/NAME` bereitgestellt.
`volume_type`	Erforderlich, wenn Volumes verwendet werden. Muss `tmpfs` lauten.
`size_gb`	Erforderlich, wenn Volumes verwendet werden. Größe des Volumes in GB. Das Minimum beträgt 0,001 GB und das Maximum ist der im Anwendungscontainer und auf dem zugrunde liegenden Gerät verfügbare Arbeitsspeicher. Google fügt Ihrem System keinen zusätzlichen Arbeitsspeicher hinzu, um die Laufwerkanforderungen zu erfüllen. Der für tmpfs-Volumes reservierte Arbeitsspeicher wird von dem für den App-Container verfügbaren Speicher abgezogen. Die Genauigkeit ist systemabhängig.

Geteilte Systemdiagnosen

Standardmäßig sind geteilte Systemdiagnosen ausgewählt. Sie können mit regelmäßigen Systemdiagnoseanfragen überprüfen, ob eine VM-Instanz erfolgreich bereitgestellt wurde und ob eine ausgeführte Instanz weiterhin fehlerfrei ausgeführt wird. Jede Systemdiagnoseanfrage muss in einem festgelegten Zeitintervall beantwortet werden.

Eine Instanz ist fehlerhaft, wenn sie auf eine festgelegte Anzahl aufeinanderfolgender Systemdiagnoseanfragen nicht antwortet. Wenn eine Instanz nicht aktiv ist, wird sie noch einmal gestartet. Wenn eine Instanz nicht bereit ist, erhält sie keine Clientanfragen. Eine Systemdiagnose kann auch fehlschlagen, wenn kein freier Speicherplatz vorhanden ist.

Sie können zwei Arten von Systemdiagnosen verwenden:

Mit Aktivitätsprüfungen wird ermittelt, ob die VM und der Docker-Container ausgeführt werden. Fehlerhafte Instanzen werden von App Engine neu gestartet.
Mit Bereitschaftsprüfungen wird ermittelt, ob Ihre Instanz bereit ist, eingehende Anfragen anzunehmen. Instanzen, die die Bereitschaftsprüfung nicht bestehen, werden nicht dem Pool verfügbarer Instanzen hinzugefügt.

Standardmäßig werden HTTP-Anfragen von Systemdiagnosen nicht an den Anwendungscontainer weitergeleitet. Wenn Sie Systemdiagnosen auf Ihre Anwendung ausdehnen möchten, müssen Sie einen Pfad für Aktivitätsprüfungen oder Bereitschaftsprüfungen angeben. Eine benutzerdefinierte Systemdiagnose Ihrer Anwendung wird als erfolgreich angesehen, wenn sie den Antwortcode 200 OK zurückgibt.

Aktivitätsprüfungen

Mit Aktivitätsprüfungen wird ermittelt, ob die VM und der Docker-Container ausgeführt werden. Als fehlerhaft angesehene Instanzen werden neu gestartet.

Sie können Anfragen für Aktivitätsprüfungen durch Hinzufügen eines optionalen Abschnitts liveness_check zur app.yaml-Datei anpassen. Beispiel:

liveness_check:
  path: "/liveness_check"
  check_interval_sec: 30
  timeout_sec: 4
  failure_threshold: 2
  success_threshold: 2

Die folgenden Einstellungen sind für Aktivitätsprüfungen verfügbar:

Feld	Standard	Bereich (Minimum-Maximum)	Beschreibung
`path`	Ohne		Wenn Aktivitätsprüfungen an den Anwendungscontainer weitergeleitet werden sollen, geben Sie einen URL-Pfad an, z. B. `"/liveness_check"`.
`timeout_sec`	4 Sekunden	1 bis 300	Zeitüberschreitungsintervall für jede Anfrage in Sekunden.
`check_interval_sec`	30 Sekunden	1 bis 300	Zeitintervall zwischen Prüfungen in Sekunden. Dieser Wert muss größer als timeout_sec sein.
`failure_threshold`	4 Prüfungen	1 bis 10	Eine Instanz ist fehlerhaft, wenn die angegebene Anzahl aufeinanderfolgender Prüfungen fehlschlägt.
`success_threshold`	2 Prüfungen	1 bis 10	Eine fehlerhafte Instanz gilt wieder als fehlerfrei, wenn sie in der angegebenen Anzahl aufeinanderfolgender Prüfungen eine Antwort sendet.
`initial_delay_sec`	300 Sekunden	0 bis 3.600	Verzögerung in Sekunden nach dem Start der Instanz, in denen Antworten von Systemdiagnosen ignoriert werden. Diese Einstellung gilt für jede neu erstellte Instanz. Sie erhält damit potenziell mehr Zeit für den Start. Die Einstellung verzögert die Überprüfung und potenzielle vorzeitige Neuerstellung der Instanz durch die automatische Reparatur, wenn die Instanz gerade gestartet wird. Der Timer für die anfängliche Verzögerung setzt ein, wenn die Instanz in den RUNNING-Modus wechselt. Sie sollten den Verzögerungszeitraum z. B. verlängern, wenn Ihre Anwendung umfangreiche Initialisierungsaufgaben ausführen muss, bevor sie für die Weiterleitung von Traffic bereit ist.

Bereitschaftsprüfungen

Mit Bereitschaftsprüfungen wird festgestellt, ob eine Instanz eingehende Anfragen annehmen kann. Instanzen, die die Bereitschaftsprüfung nicht bestehen, werden nicht zum Pool verfügbarer Instanzen hinzugefügt.

Sie können Anfragen für Systemdiagnosen durch Hinzufügen eines optionalen Abschnitts readiness_check zur app.yaml-Datei anpassen. Beispiel:

readiness_check:
  path: "/readiness_check"
  check_interval_sec: 5
  timeout_sec: 4
  failure_threshold: 2
  success_threshold: 2
  app_start_timeout_sec: 300

Es sind folgende Einstellungen für Bereitschaftsprüfungen verfügbar:

Feld	Standard	Bereich (Minimum-Maximum)	Beschreibung
`path`	Ohne		Wenn Bereitschaftsprüfungen an den Anwendungscontainer weitergeleitet werden sollen, geben Sie einen URL-Pfad an, z. B. `"/readiness_check"`.
`timeout_sec`	4 Sekunden	1 bis 300	Zeitüberschreitungsintervall für jede Anfrage in Sekunden.
`check_interval_sec`	5 Sekunden	1 bis 300	Zeitintervall zwischen Prüfungen in Sekunden. Dieser Wert muss größer als timeout_sec sein.
`failure_threshold`	2 Prüfungen	1 bis 10	Eine Instanz ist fehlerhaft, wenn die angegebene Anzahl aufeinanderfolgender Prüfungen fehlschlägt.
`success_threshold`	2 Prüfungen	1 bis 10	Eine fehlerhafte Instanz gilt wieder als fehlerfrei, wenn sie in der angegebenen Anzahl aufeinanderfolgender Prüfungen eine Antwort sendet.
`app_start_timeout_sec`	300 Sekunden	1 bis 1.800	Diese Einstellung gilt für neue Bereitstellungen, nicht für einzelne VMs. Sie gibt die maximale Zeit in Sekunden an, die für eine ausreichende Anzahl von Instanzen in einer Bereitstellung zum Bestehen von Systemdiagnosen zulässig ist. Nach Ablauf schlägt die Bereitstellung fehl und es wird ein Rollback durchgeführt. Der Timer wird mit der Bereitstellung der Compute Engine-Instanzen und der Erstellung des Back-End-Dienstes des Load-Balancers gestartet. Sie können das Zeitlimit erhöhen, wenn Sie während einer Bereitstellung mehr Zeit gewähren möchten, damit eine ausreichende Zahl von Instanzen fehlerfrei ist.

Häufigkeit der Systemdiagnosen

Für eine hohe Verfügbarkeit werden in App Engine redundante Kopien aller Systemdiagnosen erstellt. Wenn eine Systemdiagnose fehlschlägt, kann so eine redundante Kopie den Test ohne Verzögerung übernehmen.

Bei der Überprüfung der nginx.health_check-Logs für Ihre Anwendung stellen Sie eventuell fest, dass die Systemdiagnosen häufiger als von Ihnen konfiguriert erfolgen. Das ist darauf zurückzuführen, dass Ihre Einstellungen auch für die redundanten Systemdiagnosen gelten. Redundante Systemdiagnosen werden automatisch erstellt und können nicht konfiguriert werden.

Einstellungen für die Dienstskalierung

Welche Schlüssel zur Steuerung der Skalierung eines Dienstes verwendet werden, hängt von der Art der Skalierung ab, die Sie einem Dienst zuweisen.

Die Skalierung kann entweder automatisch oder manuell erfolgen. Standardmäßig wird die automatische Skalierung verwendet.

Autoscaling

Sie können Autoscaling konfigurieren, wenn Sie der Datei app.yaml den Abschnitt automatic_scaling hinzufügen. Beispiel:

automatic_scaling:
  min_num_instances: 1
  max_num_instances: 15
  cool_down_period_sec: 180
  cpu_utilization:
    target_utilization: 0.6
  target_concurrent_requests: 100

In der folgenden Tabelle sind die Einstellungen aufgeführt, die Sie für die automatische Skalierung verwenden können:

Name	Beschreibung
`automatic_scaling`	Die automatische Skalierung gilt standardmäßig. Fügen Sie diese Zeile hinzu, wenn Sie eine der automatischen Skalierungseinstellungen festlegen möchten.
`min_num_instances`	Die Mindestanzahl von Instanzen, die Ihrem Dienst zugewiesen wurden. Beim Bereitstellen eines Dienstes werden diesem entsprechend viele Instanzen zugewiesen und der Dienst wird je nach Traffic skaliert. Muss `1` oder größer sein. Die Standardeinstellung ist `2`, um die Latenz zu reduzieren. Hinweis: Die Anzahl der ausgeführten Instanzen kann bei einigen Ereignissen für einen kurzen Zeitraum unter diesen Wert fallen. Wenn Ihre Anwendung für eine bestimmte Anzahl von Instanzen kontinuierlich ausgeführt werden muss, sollten Sie eine Überdimensionierung in Betracht ziehen.
`max_num_instances`	Die maximale Anzahl von Instanzen bei der Skalierung des Dienstes. Die maximale Anzahl von Instanzen in Ihrem Projekt ist durch das Ressourcenkontingent Ihres Projekts begrenzt. Der Standardwert ist `20`.
`cool_down_period_sec`	Die Anzahl von Sekunden, nach der das Autoscaling Informationen von einer neuen Instanz erfasst. Mit diesem Wert wird verhindert, dass durch das Autoscaling Informationen während der Initialisierung der Instanz erfasst werden. Die erfasste Nutzung in diesem Zeitraum ist nicht zuverlässig. Die Wartezeit muss größer oder gleich 60 Sekunden sein. Die Standardeinstellung ist `120`.
`cpu_utilization`	Verwenden Sie diesen Header, wenn Sie die CPU-Zielauslastung angeben möchten.
`target_utilization`	CPU-Zielauslastung. Die CPU-Auslastung wird als Durchschnitt aller ausgeführten Instanzen ermittelt. Auf der Grundlage dieses Werts wird entschieden, ob die Anzahl der Instanzen reduziert oder erhöht wird. Instanzen werden unabhängig von in Übertragung befindlichen Anfragen 25 Sekunden nach dem Empfang des Signals zum Herunterfahren herunterskaliert. Standardwert ist `0.5`.
`target_concurrent_requests`	(Beta) Zielanzahl der gleichzeitigen Verbindungen pro Instanz. Wenn Sie einen Wert für diesen Parameter angeben, entscheidet das Autoscaling anhand der durchschnittlichen Anzahl gleichzeitiger Verbindungen für alle ausgeführten Instanzen, wann die Anzahl der Instanzen reduziert oder erhöht wird. Eine Instanz wird 25 Sekunden nach dem Empfang des Shutdown-Signals herunterskaliert, unabhängig von Anfragen, die gerade verarbeitet werden. Wenn Sie keinen Wert für diesen Parameter angeben, zielt das Autoscaling nicht auf eine Anzahl gleichzeitiger Verbindungen pro Instanz ab. Verbindungen unterscheiden sich von Anfragen. Eine Verbindung kann von einem Client wiederverwendet werden, um mehrere Anfragen zu senden.

Manuelle Skalierung

Sie können die manuelle Skalierung konfigurieren, wenn Sie der Datei app.yaml einen manual_scaling-Abschnitt hinzufügen. Beispiel:

manual_scaling:
  instances: 5

In der folgenden Tabelle sind die Einstellungen aufgeführt, die Sie für die manuelle Skalierung verwenden können:

Name	Beschreibung
`manual_scaling`	Erforderlich, um die manuelle Skalierung für einen Dienst zu aktivieren.
`instances`	Anzahl der Instanzen, die dem Dienst zugewiesen werden. Hinweis: Die Anzahl der ausgeführten Instanzen kann bei einigen Ereignissen für einen kurzen Zeitraum unter diesen Wert fallen. Wenn Ihre Anwendung für eine bestimmte Anzahl von Instanzen kontinuierlich ausgeführt werden muss, sollten Sie eine Überdimensionierung in Betracht ziehen.

Umgebungsvariablen definieren

Sie können in app.yaml Umgebungsvariablen für Ihre Anwendung definieren. Beispiel:

env_variables:
  MY_VAR: "my value"

Dabei sind MY_VAR und my value der Name und Wert der Umgebungsvariablen, die Sie definieren möchten, und jeder Eintrag der Umgebungsvariablen ist um zwei Leerzeichen unter dem Element env_variables eingerückt.