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

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.

Vor der Bereitstellung Ihrer Anwendung

Vor der Bereitstellung Ihrer Anwendung:

• Der Inhaber des Cloud-Projekts muss Ihr Google Cloud-Projekt für App Engine einrichten.
• Ihr Nutzerkonto enthält die erforderlichen Berechtigungen.

Anwendung bereitstellen

Stellen Sie die Anwendung mit dem Befehl gcloud app deploy in App Engine bereit. Während der Bereitstellung erstellt der Cloud Build-Dienst ein Container-Image der Anwendung, das in der Standardumgebung ausgeführt wird. Die einzelnen Builds werden in derselben Region wie Ihr Google Cloud-Projekt ausgeführt. Weitere Informationen finden Sie unter Build-Images verwalten.

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

Service bereitstellen

Für die Bereitstellung der Anwendung in App Engine erstellen Sie Versionen der Anwendungsdienste und alle zugehörigen Konfigurationsdateien.

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 Google Cloud-Projekt bereit, das Sie mit der Google Cloud CLI konfiguriert haben, und leitet den gesamten Traffic zur neuen Version.

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

• Alle weiteren Konfigurationsdateien müssen Sie einzeln als Ziel angeben und bereitstellen. Beispiele:

  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 ihm eine benutzerdefinierte Versions-ID zu und verhindern Sie, dass der Traffic zur neuen Version geleitet 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.

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

Mehrere Dienste bereitstellen

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

Hinweise:

• 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 service-Elementdefinition ein. Wenn Sie die Elementdefinition in der Konfigurationsdatei nicht angeben, wird standardmäßig die Version für den Dienst default bereitgestellt.

Wenn Sie mehrere Dienste bereitstellen möchten, müssen Sie die Datei app.yaml jedes Dienstes jeweils separat bereitstellen. Sie können mit einem einzigen gcloud app deploy-Befehl mehrere Dateien angeben:

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

Build-Logs anzeigen

Cloud Build streamt Build- und Bereitstellungslogs, die im Abschnitt Cloud Build-Verlauf der Cloud Console angezeigt werden können. Wenn Sie Builds in der Region der Anwendung aufrufen möchten, filtern Sie im Menü Region nach der Region.

Build-Images verwalten

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.

Jedes Mal, wenn Sie eine neue Version bereitstellen, geschieht Folgendes:

1. Die App Engine erstellt über den Dienst Cloud Build ein Container-Image.

2. Cloud Build erstellt das Container-Image in der Region der Anwendung und führt es in der App Engine-Standardumgebung aus.

3. Die App Engine speichert erstellte Container-Images in Artifact Registry. Sie können diese Images herunterladen, um sie an einem anderen Ort aufzubewahren oder auszuführen.

Nachdem die Bereitstellung abgeschlossen ist, benötigt App Engine die Container-Images nicht mehr. Container-Images werden nicht automatisch gelöscht. Wenn Sie verhindern möchten, dass Ihr Speicherkontingent ausgeschöpft wird, können Sie nicht mehr benötigte Images bedenkenlos löschen. Wenn Sie die Images jedoch möglicherweise in Zukunft benötigen oder Kopien der Images behalten möchten, müssen Sie vor dem Löschen eine Kopie exportieren. Weitere Informationen zum Verwalten von Images in Artifact Registry finden Sie unter Images verwalten.

Dateien ignorieren

Sie können mit einer .gcloudignore-Datei Dateien und Verzeichnisse festlegen, die beim Bereitstellen Ihrer Dienste nicht in App Engine 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.

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

Vor dem Verschieben von Traffic 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, aber verhindern Sie, dass Traffic automatisch dorthin geleitet wird:

   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. Sie können aber auch bei der Bereitstellung mit dem --version flag eine neue angeben. Das Google Cloud CLI gibt beim Bereitstellen ebenfalls die Versions-ID aus.

   Sie können die neue Version jetzt in der App Engine-Laufzeitumgebung testen. Prüfen Sie die zugehörigen Logs, um Fehler in der Anwendung zu beheben. Weitere Informationen finden Sie unter Anwendungslogs schreiben.

   App Engine leitet Anfragen, die an https://PROJECT_ID.REGION_ID.r.appspot.com gesendet wurden, zu der Version, die zuvor für den Empfang von 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.

Informationen zur Anzeige von Trace-Details in Cloud Trace finden Sie unter Traces suchen und untersuchen. Im Trace-Explorer können Sie die Filter verwenden, um nach Ihrem spezifischen App Engine-Dienst und Ihrer spezifischen App Engine-Version zu filtern.