Anwendung testen und bereitstellen

Regions-ID

REGION_ID ist ein abgekürzter Code, den Google anhand der Region zuweist, die Sie beim Erstellen Ihrer Anwendung ausgewählt haben. Der Code bezieht sich nicht auf ein Land oder eine Provinz, auch wenn einige Regions-IDs häufig verwendeten Länder- und Provinzcodes ähneln können. Das Einbinden von REGION_ID.r in App Engine-URLs ist für vorhandene Anwendungen optional und wird bald für alle neuen Anwendungen erforderlich sein.

Für einen reibungslosen Übergang wird App Engine nach und nach für die Verwendung von Regions-IDs aktualisiert. Wenn Ihr Google Cloud-Projekt noch nicht aktualisiert wurde, wird für Ihre Anwendung keine Regions-ID angezeigt. Da die ID für vorhandene Anwendungen optional ist, müssen Sie keine URLs aktualisieren oder andere Änderungen vornehmen, wenn die Regions-ID für Ihre vorhandenen Anwendungen verfügbar wird.

Hier finden Sie weitere Informationen zu Regions-IDs.

Hier erfahren Sie, wie Sie eine Anwendung lokal ausführen, bereitstellen und in App Engine testen.

Lokal ausführen

Wenn Sie die Funktionsweise Ihrer Anwendung vor der Bereitstellung testen möchten, führen Sie sie in Ihrer lokalen Umgebung mit den Entwicklungstools aus, die Sie normalerweise verwenden.

Weitere Informationen, einschließlich spezifischer Befehle für das jeweils verwendete Plug-in, finden Sie unter Lokales Testen für die Java 8/Jetty 9-Laufzeit oder unter Lokales Testen für die Java 8-Laufzeit.

Anwendung bereitstellen

Vorbereitung

Für die Bereitstellung der Anwendung müssen folgende Voraussetzungen erfüllt sein:

Dienst bereitstellen

Sie können jedes der unterstützten Tools verwenden, um Ihre Java-Anwendung in der flexiblen App Engine-Umgebung bereitzustellen. Verwenden Sie für die Befehlszeilenbereitstellung gcloud app deploy aus dem Cloud SDK oder die Plug-ins für Maven oder Gradle. Für Bereitstellungen in einer IDE verwenden Sie das Plug-in für IntelliJ oder Eclipse. Wenn Sie Anwendungen programmatisch bereitstellen möchten, verwenden Sie die Admin API.

Dateien ignorieren

Sie können eine Datei .gcloudignore verwenden, um Dateien und Verzeichnisse anzugeben, die beim Bereitstellen Ihrer Dienste nicht in Google Cloud hochgeladen werden sollen. So lassen sich Build-Artefakte und andere Dateien ausschließen, die beim Bereitstellen nicht hochgeladen werden müssen.

Weitere Informationen zur Syntax der Datei .gcloudignore finden Sie in der Referenz zu gcloud.

Container manuell für die Bereitstellung erstellen

Wenn Sie die Container-Images außerhalb der Google Cloud Platform erstellen möchten, müssen Sie Ihre Images zuerst in ein Container-Image-Repository hochladen, bevor Sie sie mit dem Befehl gcloud app deploy in App Engine bereitstellen können.

Wenn Sie die Container-Images beispielsweise lokal mit Docker erstellen, können Sie die Images zur Google Registry übertragen und dann die URL des Images im Flag --image-url des Befehls angeben:

gcloud app deploy src/main/appengine/app.yaml --image-url gcr.io/YOUR_PROJECT_ID/YOUR_CONTAINER_IMAGE

Automatisierte kontinuierliche Bereitstellungspipelines verwenden

Sie können mit Cloud Build Bereitstellungen in kontinuierlichen Bereitstellungspipelines automatisieren. Weitere Informationen finden Sie in der Cloud Build-Dokumentation unter Artefakte bereitstellen und Builds mit Build-Triggern automatisieren.

Docker-Basis-Images für Java

Wenn Sie eine benutzerdefinierte Java-Laufzeit neu erstellen möchten, können Sie im Dockerfile ein Basis-Image verwenden:

Laufzeit Docker-Befehl
Java 8 FROM gcr.io/google_appengine/openjdk
Java 8/Jetty 9 FROM gcr.io/google-appengine/jetty

App ansehen

Wenn Sie die Anwendung in App Engine bereitgestellt haben, können Sie mit dem folgenden Befehl den Browser starten und die Anwendung unter https://PROJECT_ID.REGION_ID.r.appspot.com aufrufen:

gcloud app browse

In App Engine testen

Bevor Sie eine neue Version zum Empfang von Traffic konfigurieren, können Sie sie in App Engine testen. Eine neue Version des Dienstes default wird beispielsweise so getestet:

  1. Stellen Sie Ihre neue Version mit dem Parameter promote auf false bereit:

  2. Greifen Sie über folgende URL auf die neue Version zu:

    https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com

    Sie können die neue Version jetzt in der App Engine-Laufzeitumgebung testen. Sie können Ihre Anwendung debuggen, indem Sie deren Logs in der Loganzeige der Google Cloud Console aufrufen. Weitere Informationen finden Sie unter Anwendungslogs schreiben.

    An https://PROJECT_ID.REGION_ID.r.appspot.com gesendete Anfragen werden weiterhin an die Version weitergeleitet, die zuvor für eingehenden Traffic konfiguriert wurde.

  3. Wenn Sie Traffic an die neue Version senden möchten, migrieren Sie den Traffic mithilfe der Cloud Console:

    Versionen verwalten

    Wählen Sie die Version aus, die Sie gerade bereitgestellt haben, und klicken Sie auf Traffic migrieren.

Zum Testen neuer Versionen anderer Dienste können Sie ebenso vorgehen. Ersetzen Sie in der URL einfach default durch den Namen des Dienstes:

Weitere Informationen zum Auswählen bestimmter Dienste und Versionen finden Sie unter Anfragerouting.

Fehlerbehebung

Beim Bereitstellen von Anwendungen können folgende Fehlermeldungen angezeigt werden:

PERMISSION_DENIED: Operation not allowed
The "appengine.applications.create" permission is required.
Wenn das Cloud-Projekt nicht die erforderliche App Engine-Anwendung enthält, kann der Befehl gcloud app deploy beim Ausführen des Befehls gcloud app create fehlschlagen. Nur Konten mit der Rolle „Inhaber“ haben die erforderlichen Berechtigungen zum Erstellen von App Engine-Anwendungen.
502 Bad Gateway
Das Cloud-Projekt kann nicht gestartet werden, wenn app.yaml falsch konfiguriert ist. Prüfen Sie die Anwendungslogs auf detailliertere Fehlermeldungen.