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 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: |
runtime_config |
Gibt die Python-Laufzeitversion an. Ab Python Version 3.8 müssen Sie die Version des Betriebssystems angeben.
runtime_config:
operating_system: "ubuntu22"
runtime_version: "3.12"
|
runtime_config |
Gibt die Go-Version an. Ab Go Version 1.18 müssen Sie die Version des Betriebssystems angeben. Wenn Sie beispielsweise Go 1.22 auswählen:
runtime_config:
operating_system: "ubuntu22"
runtime_version: "1.22"
|
runtime_config |
Gibt die Node.js-Version an. Ab der Node.js-Version 18 müssen Sie die Version des Betriebssystems angeben.
runtime_config:
operating_system: "ubuntu22"
runtime_version: "22"
|
runtime_config |
Gibt die Java-Version an. Ab Java Version 11 müssen Sie die Version des Betriebssystems angeben.
runtime_config:
operating_system: "ubuntu22"
runtime_version: "21"
|
runtime_config |
Ab Ruby-Version 3.2 müssen Sie die Version des Betriebssystems angeben.
runtime_config:
operating_system: "ubuntu22"
Erforderlich für Version 3.2 und höher. Wird für Ruby-Version 3.1 und früher nicht unterstützt. Die unterstützten Ubuntu-Versionen und -Laufzeiten finden Sie auf der Seite Ruby-Laufzeiten. |
runtime_config |
Ab .NET Version 6 und höher müssen Sie Folgendes angeben:
die Version des Betriebssystems.
runtime_config:
operating_system: "ubuntu22"
|
runtime_config |
Gibt die PHP-Version an. Ab PHP-Version 7.4 müssen Sie die Version des Betriebssystems angeben.
runtime_config:
operating_system: "ubuntu22"
runtime_version: "8.3"
|
env: flex |
Erforderlich: Wählen Sie die flexible Umgebung aus. |
entrypoint |
Der Befehl zum Starten Ihrer Anwendung. Der Einstiegspunkt startet einen Prozess, der auf HTTP-Anfragen an dem von der Umgebungsvariablen PORT definierten Port antwortet.
|
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 Das Dienstkonto muss im folgenden Format angegeben werden: service_account: [SERVICE_ACCOUNT_NAME]@[PROJECT_ID].iam.gserviceaccount.com |
skip_files |
Optional.
Mit dem Element Damit beispielsweise Dateien übersprungen werden, deren Namen mit 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 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:
Fügen Sie der Datei
app.yamlwie 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/tcpWenn Sie die Python-Laufzeit verwenden, ändern Sie
app.yamlso: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 vontcp:2222zuzulassen.
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:
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 |
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 |
– | 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 |
– | 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.
|
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. |
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.
Umgebungsvariablen verwenden