Benutzerdefinierte Laufzeit erstellen

Mit einer benutzerdefinierten Laufzeit können Sie eine alternative Implementierung einer beliebigen unterstützten flexiblen Umgebungs-Sprache verwenden oder eine von Google bereitgestellte Sprache wählen. Außerdem können Sie Code in jeder anderen Sprache schreiben, die eingehende HTTP-Anfragen verarbeiten kann (Beispiel). Mit einer benutzerdefinierten Laufzeit bietet und verwaltet die flexible Umgebung die Skalierungs-, Monitoring- und Lastenausgleichsinfrastruktur für Sie, sodass Sie sich ganz auf das Erstellen Ihrer Anwendung konzentrieren können.

Bevor Sie eine benutzerdefinierte Laufzeit erstellen, müssen Sie folgende Vorbereitungen treffen:

app.yaml-Datei angeben

Die Konfigurationsdatei app.yaml muss mindestens die folgenden Einstellungen enthalten:

runtime: custom
env: flex

Weitere Informationen darüber, welche Einstellungen Sie sonst noch für Ihre Anwendung festlegen können, finden Sie unter Anwendung mit app.yaml konfigurieren.

Dockerfile erstellen

Eine umfassende Dokumentation zum Erstellen von Dockerfiles finden Sie auf der Docker-Website. Wenn Sie eine benutzerdefinierte Laufzeit verwenden, müssen Sie ein Dockerfile bereitstellen, unabhängig davon, ob Sie ein eigenes Basis-Image bereitstellen oder eines der Basis-Images von Google verwenden.

Basis-Image angeben

Der erste Befehl in einem Dockerfile ist normalerweise der Befehl FROM, der ein Basis-Image angibt. Ein Basis-Image wird verwendet, um den Container und Ihre Anwendung zu erstellen. Sie können Ihr eigenes Basis-Image erstellen oder ein Basis-Image aus Container-Registries wie DockerHub auswählen.

Dockerfile suchen

Im Allgemeinen heißt das Dockerfile immer Dockerfile und befindet sich im selben Verzeichnis wie die entsprechende app.yaml-Datei. Aber in einigen Fällen gibt die Tool-Umgebung möglicherweise andere Anforderungen vor. Cloud SDK-basierte Java-Tools wie die Maven-, Gradle-, Eclipse- und IntelliJ-Plug-ins erfordern beispielsweise, dass sich Dockerfile in src/main/docker/Dockerfile und die app.yaml-Datei in src/main/appengine/app.yaml befindet. Weitere Informationen finden Sie in der Dokumentation zu Ihrer Tool-Umgebung.

Codestruktur

In diesem Abschnitt wird das Verhalten beschrieben, das vom Code implementiert werden muss, unabhängig davon, ob Sie ein von Google bereitgestelltes Basis-Image oder Ihr eigenes Basis-Image verwenden.

Port 8080 überwachen

Das App Engine-Frontend leitet eingehende Anfragen an das entsprechende Modul an Port 8080 weiter. Sie müssen darauf achten, dass Ihr Anwendungscode Port 8080 überwacht.

Lifecycle-Event verarbeiten

Die flexible Umgebung sendet in regelmäßigen Abständen bestimmte Lebenszyklusereignisse an die Anwendung.

Anwendung herunterfahren

Wenn eine Instanz heruntergefahren werden muss, werden neu eingehende Anfragen an andere Instanzen weitergeleitet (falls vorhanden) und Anfragen, die aktuell verarbeitet werden, haben Zeit, zum Ende zu kommen. Beim Herunterfahren einer Instanz sendet die flexible Umgebung normalerweise das Signal STOP (SIGTERM) an den Anwendungscontainer. Die Anwendung muss nicht auf dieses Ereignis reagieren, kann dies aber nutzen, um alle erforderlichen Bereinigungsaktionen auszuführen, bevor der Container heruntergefahren wird. Unter normalen Bedingungen wartet das System bis zu 30 Sekunden darauf, dass die Anwendung beendet wird, und sendet dann ein KILL- (SIGKILL-)Signal, das die Instanz sofort herunterfährt.

In seltenen Fällen kann App Engine durch Ausfälle daran gehindert werden, vor dem Herunterfahren 30 Sekunden zu warten. Das bedeutet, dass die Signale STOP und KILL möglicherweise nicht gesendet werden, bevor eine Instanz beendet wird. Daher empfiehlt es sich, den Status der Instanz regelmäßig zu überprüfen und sie primär als speicherinternen Cache und nicht als zuverlässigen Datenspeicher zu verwenden.

Systemdiagnose-Anfragen

Sie können mit regelmäßigen Systemdiagnose-Anfragen überprüfen, ob eine VM-Instanz erfolgreich bereitgestellt wurde und ob eine ausgeführte Instanz weiterhin fehlerfrei ausgeführt wird.

Benutzerdefinierte Laufzeit erstellen und bereitstellen

Nachdem Sie die Dateien app.yaml und DOCKER konfiguriert haben, können Sie dieses Container-Image in App Engine erstellen und bereitstellen.

Alternativ können Sie vordefinierte Container-Images Ihrer benutzerdefinierten Laufzeiten bereitstellen, die in Artifact Registry gespeichert sind. Sie können beispielsweise Cloud Build verwenden, um Ihre Images separat zu erstellen und dann in Artifact Registry zu speichern. Weitere Informationen finden Sie unter Images hoch- und herunterladen.

Anwendung in Google Cloud einbinden

Anwendungen, die in benutzerdefinierten Laufzeiten ausgeführt werden, können mithilfe der Google Cloud-Clientbibliotheken auf die Google Cloud Platform-Dienste zugreifen. Anwendungen in benutzerdefinierten Laufzeiten können auch alle Dienste von Drittanbietern über Standard-APIs verwenden.

Mit Google Cloud-Diensten authentifizieren

Standardanmeldedaten für Anwendungen bieten die einfachste Möglichkeit, sich mit Google APIs zu authentifizieren und sie aufzurufen.

Wenn Ihre Anwendung Cloud Build zum Kompilieren von Docker-Images verwendet, hostet das Netzwerk cloudbuild die Standardanmeldedaten für Anwendungen, sodass die zugehörigen Google Cloud-Dienste Ihre Anmeldedaten automatisch finden können.

Weitere Informationen zur Authentifizierung finden Sie unter Authentifizierung bei Google.

Logging

Wenn eine Anfrage an Ihre in App Engine ausgeführte Anwendung gesendet wird, werden die Anfrage- und Antwortdetails automatisch in ein Log geschrieben. Sie können im Log-Explorer der Google Cloud Console angesehen werden.

Wenn die Anwendung eine Anfrage verarbeitet, kann sie auch eigene Logging-Nachrichten in stdout und stderr schreiben. Diese Dateien werden automatisch erfasst und können im Logs Explorer angezeigt werden. Nur die neuesten Einträge für stdout und stderr werden beibehalten, um ihre Größe zu begrenzen.

Sie können auch benutzerdefinierte Logs in /var/log/app_engine/custom_logs schreiben. Verwenden Sie dazu eine Datei, die auf .log oder .json endet.

Wenn Sie in Ihren Anwendungscontainer Drittanbieter-Agents einfügen, müssen Sie die Agents so konfigurieren, dass sie in stdout und stderr oder in einem benutzerdefinierten Log protokollieren. Dadurch wird sichergestellt, dass alle von diesen Agents generierten Fehler in Cloud Logging sichtbar sind.

Die Anfrage- und Anwendungslogs für Ihre Anwendung werden von einem Cloud Logging-Agent erfasst und maximal 90 Tage lang gespeichert. Die maximale Größe beträgt 1 GB. Wenn Sie Ihre Logs über einen längeren Zeitraum oder wenn sie mehr als 1 GB speichern möchten, können Sie sie in Cloud Storage exportieren. Außerdem besteht die Möglichkeit, Logs zur weiteren Verarbeitung nach BigQuery und Pub/Sub zu exportieren.

Es stehen noch weitere Logs zur Verfügung. Sehen Sie hier einige der Logs, die standardmäßig konfiguriert sind:

Logname Nutzlasttyp Zweck
crash.log Text Enthält Informationen zu fehlgeschlagenen Einrichtungen; wenn ein Fehler bei der Ausführung Ihrer Anwendung auftritt, prüfen Sie dieses Log
monitoring.* Text Enthält Informationen aus dem Docker-Container, von dem Daten in Cloud Monitoring veröffentlicht werden
shutdown.log Text Enthält beim Herunterfahren protokollierte Informationen
stdout Text Enthält die Standardausgabe der Anwendung
stderr Text Enthält den Standardfehler des Containers
syslog Text Enthält das VM-Syslog außerhalb des Docker-Containers