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

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

Lokal ausführen

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

Vor der Bereitstellung Ihrer Anwendung

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

• Der Inhaber des Google Cloud-Projekts muss App Engine aktivieren.
• 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 App Engine-Standardumgebung ausgeführt wird. Die Builds werden in der Region der Anwendung erstellt. Weitere Informationen finden Sie unter Build-Images verwalten.

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

Dienst erstellen

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

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

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

Build-Logs ansehen

Cloud Build streamt Build- und Bereitstellungslogs, die im Abschnitt „Cloud Build-Verlauf“ der Google Cloud Console angezeigt werden können. Wählen Sie im Drop-down-Menü Region oben auf der Seite die Region aus, nach der Sie filtern möchten, um Builds in der Region der Anwendung aufzurufen.

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 bei der Bereitstellung 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.

Build-Images verwalten

Jedes Mal, wenn Sie eine neue Version bereitstellen, wird mit dem Dienst Cloud Build ein Container-Image erstellt. Dieses Container-Image wird in der Region der Anwendung erstellt und dann in der App Engine-Standardumgebung ausgeführt.

Erstellte Container-Images werden im Ordner app-engine-tmp/app in Container Registry gespeichert. Sie können diese Images herunterladen, um sie an einem anderen Ort aufzubewahren oder auszuführen. Sobald die Bereitstellung abgeschlossen ist, benötigt App Engine die Container-Images nicht mehr. Sie werden allerdings nicht automatisch gelöscht. Wenn Sie also verhindern möchten, dass Ihr Speicherkontingent ausgeschöpft wird, können Sie nicht mehr benötigte Images bedenkenlos löschen. Weitere Informationen zum Verwalten von Images in Container Registry finden Sie in der Dokumentation zu Container Registry.

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

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

Build-Umgebungsvariablen verwenden

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

Build-Umgebungsvariablen sind Schlüssel/Wert-Paare, die zusammen mit einer Anwendung bereitgestellt werden und es ermöglichen, Konfigurationsinformationen an Buildpacks zu übergeben. Sie können damit beispielsweise Compiler-Optionen anpassen. Sie haben die Möglichkeit, diese Build-Umgebungsvariablen hinzuzufügen oder zu entfernen und dafür das Feld build_env_variables in Ihrer Datei app.yaml entsprechend zu konfigurieren.

Hinweis: Schlüssel müssen mit einem ASCII-Großbuchstaben beginnen und dürfen nur aus ASCII-Großbuchstaben, Ziffern und Unterstrichen bestehen. Sie sollten keine Variablenschlüssel mit dem Präfix GOOGLE_* erstellen. Alle unterstützten Buildpacks-Umgebungsvariablen ansehen

Lokalen Entwicklungsserver verwenden

Mit dev_appserver können Sie Ihre Anwendungen lokal ausführen, um die Ausführung der Anwendung in der App Engine-Produktionsumgebung zu simulieren. Dieser Entwicklungsserver simuliert teilweise die Umgebung, in der Ihre Anwendung ausgeführt wird. Dadurch können Sie Anwendungen testen, die für eine der Standardlaufzeiten der Umgebung geschrieben wurden.

Seit Go 1.11 das Ende des Supports erreicht hat, können Sie Ihre Anwendungen nicht mehr mit der neuesten Version von dev_appserver.py lokal ausführen. Folgen Sie der Anleitung unter Lokalen Entwicklungsserver verwenden, um weiterhin dev_appserver.py zu verwenden.

Lokalen Entwicklungsserver ausführen

Wichtig: Bevor Sie den lokalen Entwicklungsserver ausführen, folgen Sie der Einrichtungsanleitung. Unabhängig von der Laufzeit- oder der Sprachversion Ihrer Anwendung müssen Sie dev_appserver.py mit Python 3 ausführen und die Umgebungsvariable CLOUDSDK_DEVAPPSERVER_PYTHON in Ihrer Shell auf den Pfad Ihres Python 2-Interpreters festlegen.

Nachdem Sie die Konfigurationsdatei app.yaml für die Anwendung erstellt haben, können Sie mit dem Befehl dev_appserver.py den lokalen Entwicklungsserver starten und die Anwendung lokal ausführen.

1. Führen Sie folgenden Befehl aus, um Anmeldedaten für Ihr Nutzerkonto abzurufen:

   gcloud auth login
   

2. Erlauben Sie Ihrer lokalen Anwendung, Ihre Nutzeranmeldedaten vorübergehend für den API-Zugriff zu verwenden:

   gcloud auth application-default login
   

3. So starten Sie den lokalen Entwicklungsserver:

   Führen Sie in dem Verzeichnis, das die app.yaml-Konfigurationsdatei enthält, den dev_appserver.py-Befehl aus und geben Sie Ihre Projekt-ID und den Pfad zu Ihrer app.yaml-Datei an:

   python2 DEVAPPSERVER_ROOT/google_appengine/dev_appserver.py/dev_appserver.py --application=PROJECT_ID app.yaml

   Fügen Sie zum Ändern des Ports die Option --port hinzu:

   python2 DEVAPPSERVER_ROOT/google_appengine/dev_appserver.py/dev_appserver.py --application=PROJECT_ID app.yaml --port=9999

   Ersetzen Sie DEVAPPSERVER_ROOT durch den Pfad zu dem Ordner, in den Sie die archivierte Version von devapp_server.py extrahieren. Weitere Informationen zum Herunterladen und Verwenden der archivierten Version von dev_appserver.py finden Sie unter Lokalen Entwicklungsserver verwenden.

   Weitere Informationen zu dev_appserver.py-Befehlsoptionen finden Sie unter Lokale Entwicklungsserver-Optionen.

4. Wenn der lokale Entwicklungsserver gestartet wird, richtet er eine Entwicklungsumgebung ein. Dort werden die Abhängigkeiten vorinstalliert, die in Ihrer requirements.txt-Datei gefundenen werden.

5. Der lokale Entwicklungsserver wird jetzt ausgeführt und ist für Anfragen bereit. Rufen Sie http://localhost:8080/ in Ihrem Webbrowser auf, um die Anwendung in Aktion zu sehen.

   Wenn Sie einen benutzerdefinierten Port mit der Option --port angegeben haben, müssen Sie den Port in Ihrem Browser öffnen.

6. Wenn Sie den lokalen Server über die Befehlszeile stoppen möchten, drücken Sie Control-C auf Ihrer Tastatur.

Laufzeitumgebung der Anwendung erkennen

Wenn Sie ermitteln möchten, ob der Code in der Produktionsumgebung oder auf dem lokalen Entwicklungsserver ausgeführt wird, prüfen Sie die Umgebungsvariable GAE_ENV:

if os.getenv('GAE_ENV', '').startswith('standard'):
  # Production in the standard environment
else:
  # Local execution.

Lokalen Entwicklungsserver mit Google Cloud-Diensten verwenden

Sie können dev_appserver mit anderen Google Cloud-Komponenten verknüpfen.

Cloud-Clientbibliotheken

Viele Google Cloud-Clientbibliotheken hängen vom Vorhandensein der Umgebungsvariablen GOOGLE_CLOUD_PROJECT ab, die Ihre Google Cloud Projekt-ID sein sollte. Sie können den Wert ermitteln, indem Sie den Befehl gcloud config list project ausführen oder sich Ihre Projektseite in der Google Cloud Console ansehen.

Initialisieren Sie dev_appserver mit dem Parameter --application=PROJECT_ID wie im Beispiel oben, damit diese Umgebungsvariable während der lokalen Entwicklung korrekt eingestellt wird.

Cloud-Emulatoren

Sie können Ihre Anwendung mit Emulatoren für Cloud Datastore, Cloud Bigtable und Cloud Pub/Sub testen.

requirements.txt- und app.yaml-Änderungen automatisch neu laden

Der lokale Entwicklungsserver installiert automatisch Abhängigkeiten, die in der Datei requirements.txt enthalten sind. Mit dev_appserver können Sie auch Funktionen testen, die über app.yaml konfiguriert wurden. Es lässt sich beispielsweise testen, ob Ihre Anwendung statische Dateien bereitstellen kann. Wenn dev_appserver ausgeführt wird, werden Änderungen an requirements.txt und app.yaml Ihre App automatisch neu starten. Dies kann zu einer vorübergehenden Verzögerung führen, wenn Abhängigkeiten heruntergeladen und installiert werden.

Instanzverwaltung und Routing im Entwicklungsserver

Instanzadressen ermitteln

Der lokale Entwicklungsserver erstellt beim Start alle manuellen Skalierungsinstanzen. Instanzen für automatische und einfache Skalierungsdienste werden dynamisch verwaltet. Der Server weist jedem Dienst einen Port zu. Für die Ausführung bestimmter Clients ist es erforderlich, dass der Server für das Load-Balancing sorgt und automatisch eine Instanz auswählt. Die Portzuweisungen für die Adressierung jedes Dienstes werden im Log-Nachrichtenstream des Servers angezeigt.

Dies sind die Ports für eine Anwendung, die drei Dienste definiert:

INFO Starting module "default" running at: http://localhost:8084
INFO Starting module "service1" running at: http://localhost:8082
INFO Starting module "service2" running at: http://localhost:8083

Wenn Sie die Adresse eines Dienstes verwenden (z. B. http://localhost:8082/), wählt der Server eine Instanz des Dienstes aus oder erstellt eine Instanz und sendet die Anfrage an diese Instanz.

Der Server weist jeder Instanz eines Dienstes eindeutige Ports zu. Sie können den Admin-Server verwenden, um diese Ports zu erkennen. Es gibt einen eindeutigen Port für den Admin-Server, der im Nachrichtenlog angezeigt wird.

INFO Starting admin server at: http://localhost:8000

Mit dieser Adresse werden Sie zur Admin-Serverkonsole geleitet. Klicken Sie auf Instanzen, um den dynamischen Status der Instanzen Ihrer Anwendung anzeigen zu lassen.

Für jede manuelle und einfache Instanz wird ein separater Eintrag angezeigt. Die Instanznummern sind Links mit eindeutigen Portadressen für jede Instanz. Klicken Sie auf den Link, um eine Anfrage direkt an diese Instanz zu senden.

Weiterleitungsdateien

Enthält Ihre App eine dispatch.yaml-Datei, enthält der Lognachrichtenstream einen Weiterleitungsport:

INFO Starting dispatcher running at: http://localhost:8080

Anfragen an diesen Port werden gemäß den Regeln in der Weiterleitungsdatei weitergeleitet. Der Server unterstützt keine dispatch.yaml-Dateiregeln, die Hostnamen (z. B. url: "customer1.myapp.com/*") enthalten. Regeln mit relativen Pfadmustern (url: "*/fun") funktionieren, sodass Sie URLs wie http://localhost/fun/mobile verwenden können, um Instanzen zu erreichen. Der Server meldet einen Fehler im Logstream, wenn Sie versuchen, eine Anwendung mit einer dispatch.yaml-Datei zu starten, die hostbasierte Regeln enthält.