Diese Seite wurde von der Cloud Translation API übersetzt.

Node.js-Laufzeitumgebung

Die Node.js-Laufzeit ist der Softwarestack, der für die Installation des Codes Ihres Webdiensts und der zugehörigen Abhängigkeiten sowie für die Ausführung des Diensts verantwortlich ist.

Die Node.js-Laufzeit für App Engine in der Standardumgebung wird in der Datei app.yaml so deklariert:

runtime: nodejsVERSION

Dabei ist VERSION die Node.js-Versionsnummer MAJOR. Wenn Sie beispielsweise die neueste Version Node.js 22 verwenden möchten, geben Sie 22 an.

Weitere unterstützte Node.js-Versionen und die entsprechende Ubuntu-Version für Ihre Node.js-Version finden Sie im Zeitplan für den Laufzeitsupport.

Node.js-Version

Die Node.js-Laufzeit verwendet den neuesten stabilen Release der Version, die in der Datei app.yaml angegeben ist. App Engine wird automatisch auf neue Patch- und Nebenversionen aktualisiert, aber nicht auf die Hauptversion.

Beispiel: Eine mit Node.js 10.9.4 und höher erstellte Anwendung wird automatisch auf Version 10.10.0 aktualisiert, aber nicht auf Node.js 12.x.x.

Da Neben- und Patch-Versionen automatisch aktualisiert werden, sofern vorhanden, kann das Attribut engines.node in der package.json-Datei nur die Hauptversion angeben und mit der Node.js-Version kompatibel sein, die in der Datei app.yaml angegeben ist.

Beispiel für 22:

22.x.x
^22.0.0
~22
>=6

Wenn Sie in Ihrer Datei package.json eine inkompatible Version von Node.js angeben, schlägt die Bereitstellung mit einer Fehlermeldung fehl.

Abhängigkeiten

Während der Bereitstellung installiert die Laufzeit die Abhängigkeiten mit dem Befehl npm install. Die Laufzeit unterstützt auch die Paketmanager Yarn (yarn.lock) und Pnpm (pnpm-lock.yaml). Weitere Informationen finden Sie unter Abhängigkeiten angeben. Da durch die Laufzeit eine Neuinstallation durchgeführt wird, müssen Sie den Ordner node_modules nicht hochladen.

können Sie angeben, welche Dateien ignoriert werden sollen.

Zur Unterstützung von Node.js-Paketen, die native Erweiterungen benötigen, enthält die Laufzeit Systempakete für die Verwendung von Tools wie ImageMagick, FFmpeg und Headless Chrome. Eine vollständige Liste der Pakete finden Sie unter Enthaltene Systempakete. Wenn Sie ein Paket anfordern möchten, melden Sie ein Problem in der Problemverfolgung.

NPM-Build-Skript

Standardmäßig führt die Node.js-Laufzeit npm run build aus, wenn in package.json ein build-Skript erkannt wird. Wenn Sie vor dem Starten Ihrer Anwendung zusätzliche Kontrolle über die Build-Schritte benötigen, können Sie einen benutzerdefinierten Build-Schritt hinzufügen. Fügen Sie dazu der Datei package.json ein gcp-build-Skript hinzu.

Wenn Sie verhindern möchten, dass Ihr Build das Script npm run build ausführt, haben Sie folgende Möglichkeiten:

Fügen Sie ein gcp-build-Script mit einem leeren Wert in Ihre package.json-Datei ein: "gcp-build":"". Weitere Informationen zum Konfigurieren der package.json finden Sie unter Konfigurationen von Node.js-Buildpacks.
Fügen Sie die Build-Umgebungsvariable GOOGLE_NODE_RUN_SCRIPTS mit einem leeren Wert in die Datei app.yaml ein.
```
build_env_variables:
  GOOGLE_NODE_RUN_SCRIPTS: ''
```

Weitere Informationen zum Angeben von Build-Umgebungsvariablen finden Sie im Abschnitt build_env_variables der Datei app.yaml.

Anwendungsstart

Standardmäßig startet die Laufzeit Ihrer Anwendung durch Ausführen von node server.js. Wenn Sie in der package.json-Datei ein start-Skript angeben, führt die Laufzeit stattdessen das angegebene Startskript aus. Beispiel:

"scripts": {
  "start": "node app.js"
}

Damit Ihre Anwendung HTTP-Anfragen empfangen kann, sollte das start-Skript einen Webserver starten, der den 0.0.0.0-Host und den von der PORT-Umgebungsvariablen angegebenen Port überwacht, auf den in Node.js als process.env.PORT zugegriffen werden kann.

Für eine optimale Leistung sollte das start-Skript einfach sein und keine Build-Schritte enthalten, da es immer dann ausgeführt wird, wenn eine neue Instanz Ihrer Anwendung erstellt wird.

Sie können dieses Verhalten überschreiben, indem Sie ein Skript im Feld entrypoint in app.yaml angeben. Statt node server.js oder ein Startskript auszuführen, startet die Laufzeit Ihre Anwendung mit dem Befehl, den Sie in entrypoint angeben.

Umgebungsvariablen

Folgende Umgebungsvariablen werden durch die Laufzeit festgelegt:

Umgebungsvariable	Beschreibung
`GAE_APPLICATION`	ID der App Engine-Anwendung. Diese ID hat das Präfix „`region code`~”, z. B. „e~” für Anwendungen, die in Europa bereitgestellt werden.
`GAE_DEPLOYMENT_ID`	ID der aktuellen Bereitstellung.
`GAE_ENV`	App Engine-Umgebung. Legen Sie `standard` fest.
`GAE_INSTANCE`	ID der Instanz, auf der Ihr Dienst gerade ausgeführt wird.
`GAE_MEMORY_MB`	Größe des für den Anwendungsprozess verfügbaren Speichers in MB
`GAE_RUNTIME`	Laufzeit, die in der Datei `app.yaml` angegeben ist.
`GAE_SERVICE`	Dienstname, der in der Datei `app.yaml` angegeben ist. Wenn kein Dienstname angegeben ist, wird als Wert `default` festgelegt.
`GAE_VERSION`	Aktuelle Versionsbezeichnung Ihres Dienstes.
`GOOGLE_CLOUD_PROJECT`	Google Cloud-Projekt-ID, die der Anwendung zugeordnet ist.
`PORT`	Port, der HTTP-Anfragen empfängt.
`NODE_ENV` (nur in der Node.js-Laufzeit verfügbar)	Erhält den Wert `production`, wenn der Dienst bereitgestellt wird.

Sie können in der Datei app.yaml weitere Umgebungsvariablen definieren. Die oben angegebenen Werte können aber mit Ausnahme von NODE_ENV nicht überschrieben werden.

HTTPS und Weiterleitungsproxys

App Engine terminiert HTTPS-Verbindungen am Load-Balancer und leitet Anfragen an die Anwendung weiter. Einige Anwendungen müssen die ursprüngliche Anfrage-IP-Adresse und das Protokoll bestimmen. Die IP-Adresse des Nutzers ist im Standardheader X-Forwarded-For verfügbar. Bei Anwendungen, die diese Informationen benötigen, sollte das Web-Framework so konfiguriert werden, dass dem Proxy vertraut wird.

Verwenden Sie für Express.js die Einstellung trust proxy:

app.set('trust proxy', true);

Wenn Sie trust proxy auf true festlegen, kann die req.ip-Eigenschaft anfällig für IP-Spoofing werden.

Dateisystem

Die Laufzeit enthält ein vollständiges Dateisystem. Das Dateisystem ist schreibgeschützt, mit Ausnahme des Speicherorts /tmp, bei dem es sich um ein virtuelles Laufwerk handelt, das Daten im RAM Ihrer App Engine-Instanz speichert.

Metadatenserver

Jede Instanz einer Anwendung kann mit dem App Engine-Metadatenserver Informationen über die Instanz und das Projekt abfragen.

Sie können auf den Metadatenserver über die folgenden Endpunkte zugreifen:

http://metadata
http://metadata.google.internal

An den Metadatenserver gesendete Anfragen müssen den Anfrageheader Metadata-Flavor: Google enthalten. Dieser Header gibt an, dass die Anfrage zum Abrufen von Metadatenwerten gesendet wurde.

In der folgenden Tabelle sind die Endpunkte aufgeführt, an die Sie HTTP-Anfragen für bestimmte Metadaten senden können:

Metadatenendpunkt	Beschreibung
`/computeMetadata/v1/project/numeric-project-id`	Projektnummer, die Ihrem Projekt zugewiesen ist.
`/computeMetadata/v1/project/project-id`	Projekt-ID, die Ihrem Projekt zugewiesen ist.
`/computeMetadata/v1/instance/region`	Region, in der die Instanz ausgeführt wird.
`/computeMetadata/v1/instance/service-accounts/default/aliases`
`/computeMetadata/v1/instance/service-accounts/default/email`	E-Mail-Adresse des Standarddienstkontos, die Ihrem Projekt zugewiesen ist.
`/computeMetadata/v1/instance/service-accounts/default/`	Listet alle Standarddienstkonten für Ihr Projekt auf.
`/computeMetadata/v1/instance/service-accounts/default/scopes`	Listet alle unterstützten Bereiche für die Standarddienstkonten auf.
`/computeMetadata/v1/instance/service-accounts/default/token`	Gibt das Authentifizierungstoken zurück, mit dem Ihre Anwendung gegenüber anderen Google Cloud APIs authentifiziert werden kann.

Wenn Sie z. B. Ihre Projekt-ID abrufen möchten, senden Sie eine Anfrage an http://metadata.google.internal/computeMetadata/v1/project/project-id.