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.

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.

Vor der Bereitstellung Ihrer Anwendung

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

Anwendung bereitstellen

Sie können Ihre Anwendung mit einer der folgenden Methoden bereitstellen:

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

Quellcode der Anwendung bereitstellen

Wenn Sie die lokalen Builds Ihrer Anwendung mit Maven oder Gradle verwalten und alle Abhängigkeiten Ihrer Anwendung öffentlich zum Download verfügbar sind, können Sie den Befehl gcloud app deploy aus dem Verzeichnis eingeben, das die pom.xml- oder build.gradle-Datei der Anwendung enthält:

gcloud app deploy

Der Befehl weist Cloud Build an, App Engine Buildpacks zum Erstellen Ihrer Anwendung und zum Bereitstellen in App Engine zu verwenden.

Wenn Sie Maven verwenden:

  • Das Buildpack verwendet den folgenden Build-Befehl: mvn clean package --batch-mode -DskipTests

  • Wenn das Stammverzeichnis Ihrer Anwendung eine mvnw-Datei enthält, ersetzt der Build-Befehl ./mvnw anstelle von mvn. Cloud Build prüft dann das target-Verzeichnis auf die .jar-Datei mit einem Manifesteintrag der Hauptklasse und erstellt einen entrypoint mit dem Wert java -jar <jarfile>.

Wenn Sie Gradle verwenden:

  • Das Buildpack verwendet den folgenden Build-Befehl: gradle clean assemble -x test --build-cache

  • Wenn das Stammverzeichnis Ihrer Anwendung eine gradlew-Datei enthält, ersetzt der Build-Befehl ./gradlew anstelle von gradle. Cloud Build prüft dann das build/libs-Verzeichnis für die .jar-Datei mit einem Manifesteintrag der Hauptklasse und erstellt einen entrypoint mit dem Wert java -jar <jarfile>.

  • Achten Sie darauf, dass sich im Stammverzeichnis Ihres Projekts kein pom.xml befindet. Maven-Projekte haben Vorrang vor Gradle-Projekten.

Build-Logs ansehen

Cloud Build streamt Build- und Bereitstellungslogs und Sie können diese im Abschnitt „Cloud Build-Verlauf“ der Cloud Console aufrufen. 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.

Beachten Sie bei dieser Bereitstellung folgende Punkte:

  • Wenn Ihre Anwendung Abhängigkeiten hat, die nur lokal verfügbar sind, kann Cloud Build Ihre Anwendung nicht erstellen und die Bereitstellung schlägt fehl. In diesem Fall empfehlen wir die Verwendung des Maven- oder Gradle-Plug-ins von App Engine.

  • Beim Erstellen einer Anwendung wird das Cloud Build-Kontingent und beim Speichern des Quellcodes Ihrer Anwendung das Cloud Storage-Kontingent verwendet. Cloud Build und Cloud Storage bieten kostenlose Kontingente. Daher fallen für die Bereitstellung von App Engine-Anwendungen keine Kosten an, bis Sie die kostenlosen Kontingente überschreiten. Weitere Informationen finden Sie unter Preise.

  • Derzeit ist es nicht möglich, zusätzliche Argumente für den Build-Befehl „Gradle“ anzugeben. Weitere Informationen finden Sie unter Google Issue Tracker.

Maven- oder Gradle-Plug-in von App Engine verwenden

App Engine bietet Maven- und Gradle-Plug-ins, mit denen Sie Ihre Anwendung erstellen und bereitstellen können. Nachdem Sie beispielsweise das Maven-Plug-in für App Engine eingerichtet haben, können Sie den folgenden Befehl aus dem Verzeichnis, das die pom.xml-Datei Ihres Projekts enthält, eingeben:

mvn package appengine:deploy -Dapp.deploy.projectId=PROJECT_ID

Ersetzen Sie PROJECT_ID durch die ID Ihres Cloud-Projekts. Wenn in der Datei pom.xml bereits Ihre Projekt-ID angegeben ist, müssen Sie das Attribut -Dapp.deploy.projectId nicht in dem von Ihnen ausgeführten Befehl einfügen.

Weitere Informationen finden Sie unter Apache Maven und das App Engine-Plug-in verwenden oder Gradle und das App Engine-Plug-in verwenden.

Eine ausführbare JAR-Datei bereitstellen

Verwenden Sie ein beliebiges Build-Framework, um eine ausführbare JAR-Datei lokal zu erstellen. Führen Sie dann je nachdem, ob Sie für Ihre Anwendung eine app.yaml-Datei erstellt haben, einen der folgenden Schritte aus:

  • Wenn Sie eine app.yaml-Datei erstellt haben:

    1. Kopieren Sie die Datei in dasselbe Verzeichnis wie die von Ihnen erstellte ausführbare JAR-Datei.

    2. Geben Sie im Verzeichnis, das die app.yaml- und Ihre JAR-Datei enthält, den folgenden Befehl ein:

      gcloud app deploy
  • Wenn Sie keine app.yaml-Datei erstellt haben, geben Sie den folgenden Befehl ein:

    gcloud app deploy your-executable.jar

    gcloud app deploy erstellt eine app.yaml-Datei mit den Mindesteinstellungen und allen Standardwerten.

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.

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:

    mvn appengine:deploy -Dapp.deploy.projectId=PROJECT_ID -Dapp.deploy.promote=False

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

Cloud Debugger verwenden

Mit dem Debugger können Sie den Zustand der bereitgestellten Anwendung an jeder beliebigen Stelle im Code prüfen, ohne die laufende Anwendung zu stoppen oder zu verlangsamen.

Damit Sie Debugger mit einer Java 11-Anwendung verwenden können, muss das folgende Flag in das Feld entrypoint der app.yaml-Datei eingefügt werden:

-agentpath:/opt/cdbg/cdbg_java_agent.so=--log_dir=/var/log

Wenn Sie bereits den entrypoint in app.yaml angegeben haben, fügen Sie das Agentpath-Flag zum Befehl java im Feld entrypoint hinzu.

Wenn Sie das Feld entrypoint nicht angegeben oder die Datei app.yaml beim Bereitstellen der Anwendung generiert haben, fügt App Engine das Flag dem Befehl hinzu, mit dem die Anwendung gestartet wird.

Cloud Profiler verwenden

Cloud Profiler ist ein statistischer Profiler mit geringem Overhead, der kontinuierlich Informationen zur CPU-Nutzung und Arbeitsspeicherzuweisung aus Ihren Produktionsanwendungen sammelt. Anschließend ordnet er diese Informationen dem Quellcode Ihrer Anwendung zu. So können Sie feststellen, welche Teile der Anwendung die meisten Ressourcen beanspruchen, und außerdem die Leistungsmerkmale des Codes unter die Lupe nehmen.

Richten Sie die Konfigurationsdateien Ihrer Anwendung ein, wie unter Programm starten beschrieben, und stellen Sie die Anwendung noch einmal bereit, um Cloud Profiler zu verwenden.