Anwendung testen und bereitstellen

Regions-ID

REGION_ID ist ein Abkürzungscode, den Google basierend auf 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 Regionen-IDs den häufig verwendeten Länder- und Provinzcodes ähneln. 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 wir Ihr Google Cloud-Projekt noch nicht aktualisiert haben, 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, sobald die Regions-ID für Ihre vorhandenen Anwendungen verfügbar ist.

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 der Anwendung vor der Bereitstellung testen möchten, können Sie sie in Ihrer lokalen Umgebung mit den Entwicklungstools ausführen, die Sie sonst auch verwenden.

Zum Beispiel können Sie in der Regel eine Flask-Anwendung mit Flasks Entwicklungsserver ausführen:

python main.py

Django-Anwendungen können so gestartet werden:

python manage.py runserver

Zur Simulation einer produktiven App Engine-Umgebung können Sie den vollständigen WSGI-Server (Web Server Gateway Interface) lokal ausführen. Verwenden Sie dazu denselben Befehl, der als entrypoint in Ihrer Datei app.yaml festgelegt ist. Beispiel:

gunicorn -b :$PORT main:app

Anwendung bereitstellen

Stellen Sie die Anwendung mit dem Befehl gcloud app deploy in App Engine bereit. Dieser Befehl legt mithilfe des Dienstes Cloud Build automatisch ein Container-Image an und stellt es anschließend in der flexiblen App Engine-Umgebung bereit. Der Container enthält alle von Ihnen lokal am Laufzeit-Image vorgenommenen Änderungen.

Wenn Sie Anwendungen programmatisch bereitstellen möchten, verwenden Sie die Admin API.

Hinweise

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

Erfolgreiche Bereitstellung gewährleisten

Wenn Sie aktualisierte Systemdiagnosen aktivieren und die Anwendung nicht den fehlerfreien Status "Healthy" erreicht, werden die Bereitstellungen zurückgesetzt.

Bei der Bereitstellung der ersten Anwendung in der flexiblen Umgebung kann es während des Einrichtens der virtuellen Maschine (VM) und weiterer Infrastruktur zu einer Verzögerung kommen. Nach der Ersteinrichtung wird anhand von Systemdiagnosen überprüft, ob die Instanz fehlerfrei ist und Traffic empfangen kann. Im Feld initial_delay_sec im Abschnitt liveness_check der Datei "app.yaml" ist eine Zeitspanne festgelegt. Erreicht die Anwendung nicht innerhalb dieser Zeitspanne den Status "Ready", schlägt die Bereitstellung fehl und wird zurückgesetzt.

Die Anwendung braucht eventuell mehr Zeit, bis sie bereit ist. Sie können für die Initialisierung der Anwendung beispielsweise große Dateien herunterladen oder Caches vorab laden. Aktualisierte Systemdiagnosen bieten die Möglichkeit, die Zeitspanne zu verlängern. Dazu müssen Sie die Konfigurationseinstellung app_start_timeout_sec im Abschnitt readiness_check der app.yaml-Datei entsprechend ändern.

Wenn Ihre Bereitstellung fehlschlägt, sorgen Sie dafür, dass die Cloud Build API in Ihrem Projekt aktiviert ist. App Engine aktiviert diese API automatisch, wenn Sie eine Anwendung zum ersten Mal bereitstellen. Wenn die API seither deaktiviert wurde, schlagen Bereitstellungen fehl.

Dienst bereitstellen

Zur Bereitstellung der Anwendung in App Engine stellen Sie Versionen der Anwendungsdienste und alle zugehörigen Konfigurationsdateien bereit.

Führen Sie zum Bereitstellen einer Version eines Anwendungsdienstes den folgenden Befehl in dem Verzeichnis aus, in dem sich die app.yaml-Datei des Dienstes befindet:

gcloud app deploy

Wenn Sie mit dem Befehl keine Dateien angeben, wird nur die app.yaml-Datei im aktuellen Verzeichnis bereitgestellt. Standardmäßig generiert der Befehl deploy eine eindeutige ID für die bereitgestellte Version, stellt die Version in dem Cloud-Projekt bereit, das Sie mit dem gcloud-Tool konfiguriert haben, und leitet den gesamten Traffic an die neue Version weiter.

Sie können das Standardverhalten des Befehls ändern, wenn Sie spezielle Dateien als Ziel angeben oder weitere Befehlsparameter einbeziehen:

  • Sie müssen jede Datei einzeln als Ziel angeben und erstellen, um weitere Konfigurationsdateien Ihres Dienstes zu erstellen. Beispiel:

    gcloud app deploy cron.yaml
    gcloud app deploy dispatch.yaml
    gcloud app deploy index.yaml
    
  • Mit dem Flag --version geben Sie eine benutzerdefinierte Versions-ID an.

  • Mit dem Flag --no-promote verhindern Sie, dass der Traffic automatisch zur neuen Version geleitet wird.

  • Mit dem Flag --project stellen Sie die Version in einem bestimmten Cloud-Projekt bereit.

Wenn Sie beispielsweise den durch app.yaml definierten Dienst in einem bestimmten Cloud-Projekt bereitstellen möchten, weisen Sie ihm eine benutzerdefinierte Versions-ID zu und verhindern Sie, dass Traffic an die neue Version weitergeleitet wird:

gcloud app deploy --project PROJECT_ID --version VERSION_ID --no-promote

Weitere Informationen zu diesem Befehl finden Sie in der Referenz zu gcloud app deploy.

Mehrere Dienste bereitstellen

Verwenden Sie dieselben Bereitstellungsbefehle, um die verschiedenen Dienste Ihrer Anwendung bereitzustellen oder zu aktualisieren.

Zum Bereitstellen mehrerer Dienste müssen Sie die Datei app.yaml für jeden einzelnen Dienst separat bereitstellen. Beispiel:

gcloud app deploy service1/app.yaml
gcloud app deploy service2/app.yaml

Sie können mit einem einzigen Bereitstellungsbefehl mehrere Dateien angeben:

gcloud app deploy service1/app.yaml service2/app.yaml

Anforderungen an die Bereitstellung mehrerer Dienste

  • Sie müssen zuerst eine Version der Anwendung für den Dienst default bereitstellen, bevor Sie weitere Dienste erstellen und bereitstellen können.

  • Geben Sie die ID des jeweiligen Dienstes in der zugehörigen app.yaml-Konfigurationsdatei an. Fügen Sie dazu in jede Konfigurationsdatei die Elementdefinition service ein. Wenn Sie die Elementdefinition in der Konfigurationsdatei nicht angeben, wird standardmäßig die Version für den Dienst defaultdefault bereitgestellt.

Dateien ignorieren

Sie können eine .gcloudignore-Datei 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 --image-url gcr.io/YOUR_PROJECT_ID/YOUR_CONTAINER_IMAGE

Automatisierte Bereitstellungspipelines verwenden

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

Docker-Basis-Images für Python

Wenn Sie eine Anwendung für eine benutzerdefinierte Python-Laufzeit neu erstellen möchten, verwenden Sie ein bereitgestelltes Basis-Image im Dockerfile:

Laufzeit Docker-Befehl Entsprechende Google-runtime
Python (2.7, 3.6 kann in der Docker-Datei festgelegt werden) FROM gcr.io/google-appengine/python runtime: python

Anwendung 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 die neue Version bereit und fügen Sie das Flag --no-promote hinzu:

    gcloud app deploy --no-promote
  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 erstellt 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 die folgenden Fehlermeldungen auftreten:

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.