Benutzerdefinierte Laufzeiten erstellen

Mit einer benutzerdefinierten Laufzeit können Sie eine alternative Implementierung einer beliebigen unterstützten flexiblen Sprache der App Engine 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 App Engine-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:

Datei app.yaml bereitstellen

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 von Google angeben

Der erste Befehl in einem Dockerfile ist normalerweise der Befehl FROM, der ein Basis-Image angibt. Die folgende Tabelle zeigt den zu verwendenden Befehl FROM, mit dem Sie ein von Google bereitgestelltes Basis-Image zusammen mit dem GitHub-Projekt angeben, mit dem das Image erstellt wurde:

Runtime Befehl Hinweis
Go
GitHub-Projekt
FROM gcr.io/google-appengine/golang
Java (nur Open JDK 8)
GitHub-Projekt
FROM gcr.io/google-appengine/openjdk Dockerfiles für Java
Java (Open JDK 8 + Eclipse Jetty 9.3)
github-Projekt
FROM gcr.io/google-appengine/jetty Dockerfiles für Java
.NET
GitHub-Projekt
FROM gcr.io/google-appengine/aspnetcore
Node.js
GitHub-Projekt
FROM gcr.io/google-appengine/nodejs
PHP
GitHub-Projekt
FROM gcr.io/google-appengine/php
Python 2.7 und 3.6
GitHub-Projekt
FROM gcr.io/google-appengine/python
Ruby
GitHub-Projekt
FROM gcr.io/google-appengine/ruby

Benutzerdefinierte Java-Laufzeiten verwenden

Wenn Sie eine Java-Laufzeit anpassen und zusätzliche Anweisungen hinzuzufügen möchten, müssen Sie ein Dockerfile erstellen.

Beispiel Dockerfile für Java 8/Jetty 9:

FROM gcr.io/google-appengine/jetty
ADD test-webapp-1.0-SNAPSHOT.war $JETTY_BASE/webapps/root.war
WORKDIR $JETTY_BASE
RUN java -jar $JETTY_HOME/start.jar --approve-all-licenses --add-to-startd=jmx,stats,hawtio 
&& chown -R jetty:jetty $JETTY_BASE

Dabei ist test-webapp-1.0-SNAPSHOT.war der Name der integrierten WAR-Datei in Ihrem target/ (Maven)- oder build/staged-app/ (Graven)-Verzeichnis.

Im Gegensatz dazu benötigen Sie für die Bereitstellung Ihrer Anwendung in App Engine kein Dockerfile, wenn Sie ein nicht angepasstes Basis-Image einer der von Google bereitgestellten Java-Laufzeiten verwenden. Weitere Informationen finden Sie unter Java 8-Laufzeitumgebung oder Java 8-/Jetty 9-Laufzeit.

Eine vollständige Liste aller von Google bereitgestellten Images finden Sie im Projekt "google-appengine".

Dockerfile benennen und Speicherort ermitteln

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.

Erforderliche 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-Front-End leitet eingehende Anfragen an das entsprechende Modul an Port 8080 weiter. Sie müssen darauf achten, dass Ihr Anwendungscode Port 8080 überwacht.

Lebenszyklusereignisse verarbeiten

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

Anwendung herunterfahren

Beim Herunterfahren einer Instanz sendet die flexible App Engine-Umgebung normalerweise das Signal STOP (SIGTERM) an den Anwendungscontainer. Die Anwendung muss nicht auf dieses Ereignis reagieren, aber sie kann damit alle erforderlichen Bereinigungsaktionen ausführen, bevor der Container heruntergefahren wird. Unter normalen Bedingungen wartet das System bis zu 30 Sekunden, bis die Anwendung beendet wird, und sendet dann das Signal KILL (SIGKILL).

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.

Anwendung in die Google Cloud Platform 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 Platform-Diensten authentifizieren

Im Allgemeinen bieten die Standardanmeldedaten für Anwendungen die einfachste Möglichkeit zur Authentifizierung mit und zum Aufrufen von Google APIs.

Es ist möglich, Ihre Anwendung mithilfe der Compute Engine Metadata API direkt mit Zugriffstokens zu authentifizieren. Dies ist jedoch erheblich komplexer. Sie können diese Zugriffstoken dann in API-Anfragen verwenden, z. B. Anfragen an Dienste und Ressourcen von Cloud Storage und Datastore.

Weitere Informationen zu Authentifizierungsoptionen finden Sie hier.

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

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:

Log-Name 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