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. Bei Anwendungen, die nach Februar 2020 erstellt wurden, ist REGION_ID.r in den App Engine-URLs enthalten. Bei Anwendungen, die vor diesem Datum erstellt wurden, ist die Regions-ID in der URL optional.

Hier finden Sie weitere Informationen zu Regions-IDs.

OK

Go Java Node.js PHP Python Ruby .NET Benutzerdefiniert

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

Lokal ausführen

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

Anwendung bereitstellen

Stellen Sie die Anwendung mit dem Befehl gcloud app deploy in App Engine bereit.

Der Cloud Build-Dienst erstellt Ihre Bereitstellung automatisch in einem Container-Image und stellt das Image in der flexiblen App Engine-Umgebung bereit. Der Container enthält alle lokalen Änderungen, die Sie am Laufzeit-Image vorgenommen haben.

Wenn Sie Anwendungen programmgesteuert erstellen möchten, verwenden Sie die Admin API.

Hinweise

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

• Der Inhaber des Cloud-Projekts muss Ihr Google Cloud-Projekt für App Engine einrichten.

• Ihr Nutzerkonto enthält die erforderlichen Berechtigungen.

Service bereitstellen

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

• Sie können aber auch die anderen Konfigurationsdateien Ihres Dienstes bereitstellen und dafür jede Datei einzeln als Ziel angeben und bereitstellen. 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 können Sie ein bestimmtes Google Cloud-Projekt zum Bereitstellen angeben.

Wenn Sie beispielsweise den in der Datei app.yaml definierten Dienst in einem bestimmten Google Cloud-Projekt bereitstellen möchten, weisen Sie dem Dienst eine benutzerdefinierte Versions-ID zu und verhindern Sie, dass Traffic zur neuen Version geleitet wird:

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

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

Sie können für das die gcloud CLI Attribute festlegen und SDK-Konfigurationen erstellen und verwalten. Sie müssen dann nicht bei jeder Bereitstellung Flags wie --project angeben.

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.

Hinweis: Sie können das Feld skip_files in der Datei app.yaml nicht angeben, wenn Sie eine Datei vom Typ .gcloudignore haben.

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

Container manuell für die Bereitstellung erstellen

Wichtig: Container Registry wurde verworfen und wird demnächst eingestellt. In Organisationen, die Container Registry vor dem 8. Januar 2024 nicht verwendet haben, werden neue gcr.io-Repositories standardmäßig in Artifact Registry gehostet. Ab dem 15. Mai 2024 unterstützen Google Cloud-Projekte ohne vorherige Verwendung von Container Registry nur das Hosting und die Verwaltung von Images für die Domain gcr.io in Artifact Registry.

Container Registry soll am 18. März 2025 eingestellt werden. Weitere Informationen zur Einstellung finden Sie unter Einstellung von Container Registry.

So erstellen Sie Container-Images außerhalb von Google Cloud:

1. Laden Sie Ihre Images in ein Artifact Registry-Repository hoch. Weitere Informationen finden Sie unter Images hoch- und herunterladen.
2. Mit dem Befehl gcloud app deploy in App Engine bereitstellen.

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

gcloud app deploy --image-url LOCATION-docker.pkg.dev/PROJECT-ID/REPOSITORY/IMAGE

Ersetzen Sie:

• LOCATION durch den Speicherort des Repositorys, in dem das Image gespeichert ist.

• PROJECT-ID durch ihre Google Cloud-Projekt-ID.

• REPOSITORY durch den Namen des Repositorys, in dem das Image gespeichert ist.

• IMAGE durch den Namen Ihres Container-Images

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 In App Engine bereitstellen und Build-Trigger erstellen und verwalten.

Docker-Basis-Images

Eine benutzerdefinierte Laufzeitanwendung erstellen Sie unter Docker-Datei erstellen.

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 Ihre neue Versionund fügen Sie das Flag --no-promote hinzu:

   gcloud app deploy --no-promote

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

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

   Hinweis: Sie finden die Versions-ID in der Google Cloud Console oder geben sie bei der Bereitstellung mit dem Parameter version an.

   Sie können die neue Version jetzt in der App Engine-Laufzeitumgebung testen. Sie können Ihre Anwendung debuggen, indem Sie deren Logs im Log-Explorer 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 Google 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:

https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com

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

Build-Umgebungsvariablen verwenden

Sie können auch Build-Umgebungsvariablen für Laufzeiten festlegen, die Buildpacks unterstützen.

Build-Umgebungsvariablen sind Schlüssel/Wert-Paare, die Sie zum Konfigurieren des Buildpacks angeben können, das Sie zum Bereitstellen der Anwendung verwenden. Sie können beispielsweise Compileroptionen angeben.

Hinweis

• Schlüssel müssen mit einem ASCII-Großbuchstaben beginnen und können Großbuchstaben, ASCII-Buchstaben, Ziffern und Unterstriche enthalten.
• Sie sollten keine Variablen mit dem Schlüsselpräfix GOOGLE_* erstellen.
• Derzeit sind die folgenden Schlüssel für die Nutzung durch Google reserviert:
  • GOOGLE_RUNTIME
  • GOOGLE_RUNTIME_VERSION
  • GOOGLE_ENTRYPOINT
  • GOOGLE_DEVMODE
• Sie können einen beliebigen Schlüssel verwenden, der von Buildpacks unterstützt wird.

Wenn Sie Umgebungsvariablen mit Buildpacks verwenden möchten, geben Sie in Ihrer app.yaml-Datei das Feld build_env_variables an.

Weitere Informationen zu Buildpacks.

Cloud Trace verwenden

Cloud Trace ist hilfreich, um zu verstehen, wie Anfragen Ihre Anwendung durchlaufen. Sie können sich detaillierte Informationen zur Latenz einer einzelnen Anfrage oder gesammelte Informationen zur Latenz der gesamten Anwendung ansehen.

Sie können Trace-Details anzeigen. Im Trace-Explorer können Sie nach Ihrem spezifischen App Engine-Dienst und Ihrer Version filtern.

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 Google 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 Google Cloud-Projekt kann nicht gestartet werden, wenn app.yaml falsch konfiguriert ist. Prüfen Sie die Anwendungslogs auf detailliertere Fehlermeldungen.

[13] An internal error occurred while creating a Cloud Storage bucket.

App Engine erstellt in der Region, in der es auch Ihre Anwendung erstellt, einen multiregionalen Cloud Storage-Standard-Bucket für Sie. Es benötigt diesen Bucket, um den Inhalt Ihrer Anwendung zu speichern. Der Fehler wird zurückgegeben, wenn dieser Bucket nicht erstellt werden kann, wie in den folgenden Szenarien:

• Der Dienst-Agent für die flexible App Engine-Umgebung ist in Ihrem Projekt nicht vorhanden oder hat nicht die Rolle App Engine flexible environment Service Agent. Sie können das Dienstkonto des Agents wieder in Ihr Projekt aufnehmen, indem Sie ihm die richtigen IAM-Berechtigungen zuweisen. Siehe Gelöschten Dienst-Agent wiederherstellen.

• Das App Engine-Standarddienstkonto ist in Ihrem Projekt nicht vorhanden. Wenn das App Engine-Dienstkonto vor Ablauf von 30 Tagen entfernt wurde, können Sie es wiederherstellen.

• Ihr Projekt befindet sich in einer Organisation, die die Richtlinie constraints/gcp.resourceLocations erzwingt. Die Organisation lässt das Erstellen von Ressourcen in derselben Region, in der Ihre App Engine-Anwendung erstellt wurde, nicht zu. Sie müssen die erzwungene constraints/gcp.resourceLocations-Richtlinie für Ihr Projekt überschreiben und die multiregionalen Standorte in derselben Region zulassen, in der Ihre App Engine-Anwendung erstellt wurde.

Wenn Ihre App Engine-Anwendung beispielsweise in der Region europe-westerstellt wird, obwohl die Region den europe-west1-Standorten zugeordnet ist, müssen Sie die Einschränkung ändern, um Ressourcen in in:eu-locations zuzulassen, was alleEU-Regionen umfasst. Dies ist erforderlich, da die von App Engine erstellten Buckets multiregional sind. Wird Ihre App Engine-Anwendung in der US-Region erstellt, müssen Sie in:us-locations zulassen. Wird Ihre Anwendung in den ASIA-Regionen erstellt, müssen Sie in:asia-locations zulassen.

[13] An internal error occurred.

Dieser Fehler kann auftreten, wenn Sie Ihren Dienst mit einer Netzwerkkonfiguration über eine freigegebene VPC bereitstellen. Geben Sie Folgendes ein:

1. Prüfen Sie, ob Ihre app.yaml-Konfiguration gültig ist.
2. Achten Sie darauf, dass Ihre flexible App Engine-Umgebung alle Anforderungen für die Einrichtung einer freigegebenen VPC erfüllt. Flexible App Engine-Umgebung in einem freigegebenen VPC-Netzwerk verwenden
3. In Ihrem Projekt müssen konfigurierte Dienstkonten vorhanden sein. Andernfalls müssen Sie die Konten wiederherstellen. Die Subnetzregion im freigegebenen VPC-Hostprojekt muss mit dem Standort übereinstimmen, an dem Ihre App Engine-Umgebung erstellt wurde.

Wenn das Problem weiterhin besteht, stellen Sie den Dienst mit dem Google Cloud SDK neu bereit. Achten Sie darauf, das Flag --verbosity=debug hinzuzufügen. Wenden Sie sich an den Google Cloud-Support und stellen Sie dabei die Ausgabe des Befehls bereit.

IP space of {USER_SUBNETWORK_NAME} is exhausted and needs to be expanded.

Wenn die Bereitstellung mit dieser Fehlermeldung fehlschlägt, bedeutet dies, dass das für den App Engine-Dienst konfigurierte Netzwerk keine Adressen mehr für die neuen Instanzen des Dienstes hat. Zum Beheben des Problems erweitern Sie die VPC-Bereiche in dem Subnetz, das für den Dienst der flexiblen App Engine-Umgebung konfiguriert wurde.