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:

NameBeschreibung
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:

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"
  • operating_system: Gibt die Version des Ubuntu-Betriebssystems an, das Sie verwenden möchten.

    Erforderlich für Python Version 3.8 und höher. Wird in Python Version 3.7 und früheren Versionen nicht unterstützt. Die unterstützten Ubuntu-Versionen und -Laufzeiten finden Sie auf der Seite Python-Laufzeiten.

  • runtime_version: Optional für alle Laufzeitversionen. Gibt die Version der Python-Laufzeit an, die Sie verwenden möchten. Die unterstützten Versionen und die Standardwerte auf der Seite Python-Laufzeiten.
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"
  • operating_system: Gibt die Version des Ubuntu-Betriebssystems an, das Sie verwenden möchten.

    Erforderlich für Version 1.18 und höher. Wird in Go-Version 1.15 und niedriger nicht unterstützt. Die unterstützten Ubuntu-Versionen und -Laufzeiten finden Sie auf der Seite Go-Laufzeiten.

  • runtime_version: Optional für alle Laufzeitversionen. Gibt die Version der Go-Laufzeit an, die Sie verwenden möchten. Die unterstützten Versionen und die Standardwerte auf der Seite Go-Laufzeiten finden Sie hier.
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"
  • operating_system: Gibt die Version des Ubuntu-Betriebssystems an, das Sie verwenden möchten.

    Erforderlich für Version 18 und höher. Wird für Node.js-Version 16 und frühere Versionen nicht unterstützt. Informationen zu den unterstützten Ubuntu-Versionen und -Laufzeiten finden Sie auf der Seite Node.js-Laufzeiten.

  • runtime_version: Optional für alle Laufzeitversionen. Gibt die Version der Node.js-Laufzeit an, die Sie verwenden möchten. Die unterstützten Versionen und die Standardwerte finden Sie auf der Seite Node.js-Laufzeiten.
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"
  • operating_system: Gibt die Version des Ubuntu-Betriebssystems an, das Sie verwenden möchten.

    Erforderlich für Version 11 und höher. Wird für Java 8 nicht unterstützt. Die unterstützten Ubuntu-Versionen und -Laufzeiten finden Sie auf der Seite Java-Laufzeiten.

  • runtime_version: Optional für alle Laufzeitversionen. Gibt die Version der Java-Laufzeit an, die Sie verwenden möchten. Die unterstützten Versionen und die Standardwerte auf der Seite Java-Laufzeiten finden Sie hier.
runtime_config Ab Ruby-Version 3.2 müssen Sie die Version des Betriebssystems angeben.
runtime_config:
    operating_system: "ubuntu22"

operating_system: Gibt die Version des Ubuntu-Betriebssystems an, das Sie verwenden möchten.

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"
  • operating_system: Gibt die Version des Ubuntu-Betriebssystems an, das Sie verwenden möchten.

    Erforderlich für Version 6 und höher. Nicht unterstützt für .NET Version 3.1 und früher. Die unterstützten Ubuntu-Versionen und -Laufzeiten finden Sie auf der Seite .NET-Laufzeiten.

  • runtime_version: Optional für alle Laufzeitversionen. Gibt die Version der .NET-Laufzeit an, die Sie verwenden möchten. Die unterstützten Versionen und die Standardwerte auf der Seite .NET-Laufzeiten finden Sie hier.
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"
  • operating_system: Gibt die Version des Ubuntu-Betriebssystems an, das Sie verwenden möchten.

    Erforderlich für Version 7.4 und höher. In PHP-Version 7.3 und früheren Versionen nicht unterstützt. Die unterstützten Ubuntu-Versionen und -Laufzeiten finden Sie auf der Seite PHP-Laufzeiten.

  • runtime_version: Optional für alle Laufzeitversionen. Gibt die Version der PHP-Laufzeit an, die Sie verwenden möchten. Die unterstützten Versionen und die Standardwerte auf der Seite PHP-Laufzeiten finden Sie hier.
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 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:

  1. Erstellen Sie ein benutzerdefiniertes Subnetzwerk.

  2. Fügen Sie der Datei app.yaml wie oben angegeben den Namen des Netzwerks und des Subnetzwerks hinzu.

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

  1. 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
      
  2. 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 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:

NameBeschreibung
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