Von der Google App Engine-Java-Anwendung zu Cloud Run mit Jib migrieren

1. Übersicht

Diese Reihe von Codelabs (eigenständige, praktische Anleitungen) soll Java-Entwicklern in der Google App Engine (Standard) dabei helfen, ihre Apps zu modernisieren, indem sie durch eine Reihe von Migrationen geführt werden. So können Sie Ihre App aktualisieren, damit sie plattformunabhängiger ist, und sie für Cloud Run, den Container-Hosting-Schwesterdienst der App Engine von Google Cloud, und andere Container-Hosting-Dienste containerisieren.

In dieser Anleitung erfahren Sie, wie Sie mit Jib eine App Engine-Anwendung containerisieren, um sie für den vollständig verwalteten Cloud Run-Dienst bereitzustellen. Mit Jib können Sie Docker erstellen, eine bekannte Plattform in der Branche zum Entwickeln, Bereitstellen und Ausführen von Anwendungen in Containern.

Sie erfahren nicht nur, wie Sie von der App Engine zu Cloud Run migrieren, sondern auch, wie Sie eine Java 8-App Engine-Anwendung auf Java 17 umstellen.

Wenn Ihre Anwendung die gebündelten Legacy-Dienste der App Engine oder andere App Engine-Funktionen häufig verwendet, empfehlen wir, diese Dienste zu migrieren oder diese Funktionen zu ersetzen, bevor Sie zu Cloud Run wechseln. Wenn Sie mehr Zeit benötigen, um Ihre Migrationsoptionen zu prüfen, oder die Legacy-gebündelten Dienste vorerst weiter verwenden möchten, können Sie beim Upgrade auf eine neuere Laufzeit weiterhin auf die gebündelten App Engine-Dienste für Java 11/17 zugreifen. Wenn Ihre App portabel ist, kehren Sie zu diesem Codelab zurück, um zu erfahren, wie Sie die Anleitung auf Ihre App anwenden.

Sie werden lernen,

  • Cloud Shell verwenden
  • Cloud Run API, Artifact Registry API und Cloud Build API aktivieren
  • Anwendung mit Jib und Cloud Build containerisieren
  • Container-Images in Cloud Run bereitstellen

Voraussetzungen

Umfrage

Wie möchten Sie diese Anleitung verwenden?

Nur durchlesen Durchlesen und die Übungen absolvieren

Wie würden Sie Ihre Erfahrung mit Java bewerten?

Anfänger Fortgeschrittene Erfahren

Wie würden Sie Ihre Erfahrungen mit der Nutzung von Google Cloud-Diensten bewerten?

Anfänger Mittelstufe Fortgeschritten

2. Hintergrund

PaaS-Systeme (Platform as a Service) wie App Engine und Cloud Functions bieten viele Vorteile für Ihr Team und Ihre Anwendung. So können sich Systemadministratoren und Entwickler auf die Entwicklung von Lösungen konzentrieren. Bei serverlosen Plattformen kann Ihre App bei Bedarf automatisch hochskaliert und mit der Abrechnung nach Nutzung auf null herunterskaliert werden, um die Kosten zu kontrollieren. Außerdem können Sie eine Vielzahl gängiger Entwicklungssprachen verwenden.

Die Flexibilität von Containern ist jedoch ebenfalls überzeugend. Da Sie mit Containern jede Sprache, jede Bibliothek und jedes Binärprogramm auswählen können, bieten sie das Beste aus beiden Welten: die Vorteile des serverlosen Computings und die Flexibilität von Containern. Genau das ist Cloud Run.

Die Verwendung von Cloud Run wird in diesem Codelab nicht behandelt. Weitere Informationen finden Sie in der Cloud Run-Dokumentation. Sie lernen hier, wie Sie Ihre App Engine-Anwendung für Cloud Run (oder andere containergehostete Dienste) containerisieren. Bevor Sie fortfahren, sollten Sie einige Dinge wissen. Vor allem, dass sich die Nutzerfreundlichkeit etwas unterscheidet.

In diesem Codelab erfahren Sie, wie Sie Container erstellen und bereitstellen. Die folgenden Themen werden behandelt:

  • Anwendung mit Jib containerisieren
  • Von der App Engine-Konfiguration migrieren
  • und optional Buildschritte für Cloud Build definieren.

Dies bedeutet, dass bestimmte App Engine-spezifische Funktionen nicht mehr unterstützt werden. Wenn Sie diesen Weg nicht gehen möchten, können Sie trotzdem auf eine Java 11/17-Laufzeit umstellen und Ihre Apps in der App Engine belassen.

3. Einrichtung/Vorbereitung

1. Projekt einrichten

In dieser Anleitung verwenden Sie eine Beispielanwendung aus dem Repository appengine-java-migration-samples in einem brandneuen Projekt. Das Projekt muss ein aktives Rechnungskonto haben.

Wenn Sie eine vorhandene App Engine-Anwendung zu Cloud Run migrieren möchten, können Sie stattdessen diese App verwenden.

Führen Sie den folgenden Befehl aus, um die erforderlichen APIs für Ihr Projekt zu aktivieren:

gcloud services enable artifactregistry.googleapis.com cloudbuild.googleapis.com run.googleapis.com

2. Referenzbeispielanwendung herunterladen

Klonen Sie die Beispielanwendung entweder auf Ihrem eigenen Computer oder in Cloud Shell und rufen Sie dann den Ordner Baseline auf.

Bei dem Beispiel handelt es sich um eine Java 8-Servlet-basierte Datenspeicher-App, die für die Bereitstellung in App Engine vorgesehen ist. Folgen Sie der Anleitung in der README-Datei, um diese App für die App Engine-Bereitstellung vorzubereiten.

3. (Optional) Referenzanwendung bereitstellen

Die folgenden Schritte sind nur erforderlich, wenn Sie prüfen möchten, ob die App in der App Engine funktioniert, bevor wir sie zu Cloud Run migrieren.

Befolgen Sie die Schritte in der Datei README.md:

  1. gcloud CLI installieren oder noch einmal kennenlernen
  2. Initialisieren Sie die gcloud CLI für Ihr Projekt mit gcloud init.
  3. App Engine-Projekt mit gcloud app create erstellen
  4. Beispielanwendung in App Engine bereitstellen
./mvnw package appengine:deploy -Dapp.projectId=$PROJECT_ID
  1. Prüfen, ob die Anwendung in App Engine problemlos ausgeführt wird

4. Artifact Registry-Repository erstellen

Nachdem Sie Ihre App containerisiert haben, müssen Sie Ihre Images irgendwo hochladen und speichern. In Google Cloud wird dazu Artifact Registry empfohlen.

Erstellen Sie mit gcloud das Repository migration:

gcloud artifacts repositories create migration --repository-format=docker \
--description="Docker repository for the migrated app" \
--location="northamerica-northeast1"

Dieses Repository verwendet das Format docker. Es gibt jedoch verschiedene Repository-Typen.

Sie haben jetzt Ihre App Engine-Basisanwendung und Ihr Google Cloud-Projekt ist für die Migration zu Cloud Run vorbereitet.

4. Anwendungsdateien ändern

Wenn Ihre App die Legacy-gebündelten Dienste, die Konfiguration oder andere nur für die App Engine verfügbare Funktionen der App Engine intensiv nutzt, empfehlen wir Ihnen, während der Umstellung auf die neue Laufzeit weiterhin auf diese Dienste zuzugreifen. In diesem Codelab wird ein Migrationspfad für Anwendungen veranschaulicht, die bereits eigenständige Dienste verwenden oder so umgestaltet werden können, dass sie dies tun.

1. Upgrade auf Java 17

Wenn Ihre App Java 8 verwendet, sollten Sie auf einen späteren LTS-Kandidaten wie Java 11 oder Java 17 umstellen, um Sicherheitsupdates zu erhalten und Zugriff auf neue Sprachfunktionen zu erhalten.

Aktualisieren Sie zuerst die Attribute in pom.xml. Sie sollten Folgendes enthalten:

<properties>
    <java.version>17</java.version>
    <maven.compiler.source>17</maven.compiler.source>
    <maven.compiler.target>17</maven.compiler.target>
</properties>

Dadurch wird die Projektversion auf 17 festgelegt und das Compiler-Plug-in darüber informiert, dass Sie Zugriff auf die Sprachfunktionen von Java 17 benötigen und dass die kompilierten Klassen mit der Java 17-JVM kompatibel sein sollen.

2. Webserver einschließen

Es gibt eine Reihe von Unterschieden zwischen App Engine und Cloud Run, die beim Wechsel zwischen ihnen berücksichtigt werden sollten. Ein Unterschied besteht darin, dass die Java 8-Laufzeit der App Engine einen Jetty-Server für die gehosteten Apps bereitstellte und verwaltete, Cloud Run dies jedoch nicht tut. Wir verwenden Spring Boot, um uns einen Webserver und einen Servlet-Container zur Verfügung zu stellen.

Fügen Sie die folgenden Abhängigkeiten hinzu:

<dependencies>
<!-- ... -->
   <dependency>
       <groupId>org.springframework.boot</groupId>
       <artifactId>spring-boot-starter-web</artifactId>
       <version>2.6.6</version>
       <exclusions>
           <!-- Exclude the Tomcat dependency -->
           <exclusion>
               <groupId>org.springframework.boot</groupId>
               <artifactId>spring-boot-starter-tomcat</artifactId>
           </exclusion>
       </exclusions>
   </dependency>
   <!-- Use Jetty instead -->
   <dependency>
       <groupId>org.springframework.boot</groupId>
       <artifactId>spring-boot-starter-jetty</artifactId>
       <version>2.6.6</version>
   </dependency>
<!-- ... -->
</dependencies>

Spring Boot bettet standardmäßig einen Tomcat-Server ein, aber in diesem Beispiel wird dieses Artefakt ausgeschlossen und bei Jetty verwendet, um Unterschiede im Standardverhalten nach der Migration zu minimieren. Wir können die Jetty-Version auch so konfigurieren, dass sie der von der App Engine bereitgestellten Version entspricht.

<properties>
    <java.version>17</java.version>
    <maven.compiler.source>17</maven.compiler.source>
    <maven.compiler.target>17</maven.compiler.target>
    <jetty.version>9.4.46.v20220331</jetty.version>
</properties>

3. Spring Boot-Einrichtung

Spring Boot kann Ihre Servlets zwar ohne Änderungen wiederverwenden, es ist jedoch eine gewisse Konfiguration für die Sichtbarkeit erforderlich.

Erstellen Sie die folgende MigratedServletApplication.java-Klasse im com.example.appengine-Paket:

package com.example.appengine;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.EnableAutoConfiguration;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.web.servlet.ServletComponentScan;

@ServletComponentScan
@SpringBootApplication
@EnableAutoConfiguration
public class MigratedServletApplication {
    public static void main(String[] args) {
        SpringApplication.run(MigratedServletApplication.class, args);
    }
}

Dazu gehört auch die @ServletComponentScan-Anmerkung, die standardmäßig im aktuellen Paket nach allen @WebServlets sucht und sie wie erwartet verfügbar macht.

4. App als JAR-Datei verpacken

Es ist zwar möglich, Ihre App mit Jib zu containerisieren, indem Sie mit einer WAR-Datei beginnen, aber es ist einfacher, wenn Sie Ihre App als ausführbare JAR-Datei verpacken. Dies erfordert nicht viel Konfiguration, insbesondere bei Projekten, bei denen Maven als Build-Tool verwendet wird, da das JAR-Paket das Standardverhalten ist.

Entfernen Sie das packaging-Tag aus der Datei pom.xml:

<packaging>war</packaging>

Fügen Sie als Nächstes spring-boot-maven-plugin hinzu:

<plugins>
<!-- ... -->
  <plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <version>2.6.6</version>
  </plugin>
<!-- ... -->
</plugins>

5. Von App Engine-Konfiguration, -Diensten und -Abhängigkeiten migrieren

Wie bereits zu Beginn des Codelabs erwähnt, sind Cloud Run und App Engine für unterschiedliche Anwendungsfälle konzipiert. Bestimmte Funktionen, die in der App Engine standardmäßig verfügbar sind, wie die Cron- und Task Queue-Dienste, müssen manuell neu erstellt werden. Sie werden in späteren Modulen ausführlicher behandelt.

Die Beispielanwendung verwendet keine gebündelten Legacy-Dienste. Nutzer, deren Anwendungen dies jedoch tun, können auf die folgenden Anleitungen zurückgreifen:

Da Sie die Bereitstellung ab sofort in Cloud Run vornehmen, kann die appengine-maven-plugin entfernt werden:

<plugin>
 <groupId>com.google.cloud.tools</groupId>
 <artifactId>appengine-maven-plugin</artifactId>
 <version>2.4.1</version>
 <configuration>
   <!-- can be set w/ -DprojectId=myProjectId on command line -->
   <projectId>${app.projectId}</projectId>
   <!-- set the GAE version or use "GCLOUD_CONFIG" for an autogenerated GAE version -->
   <version>GCLOUD_CONFIG</version>
 </configuration>
</plugin>

5. Anwendung containerisieren

Sie können Ihre Anwendung jetzt manuell direkt aus dem Quellcode in Cloud Run bereitstellen. Dies ist eine hervorragende Option, bei der Cloud Build im Hintergrund verwendet wird, um eine einfache Bereitstellung zu ermöglichen. In späteren Modulen werden wir die Bereitstellung von Quellen genauer behandeln.

Wenn Sie mehr Kontrolle über die Bereitstellung Ihrer App benötigen, können Sie eine cloudbuild.yaml-Datei definieren, in der die gewünschten Build-Schritte explizit festgelegt sind:

1. cloudbuild.yaml-Datei definieren

Erstellen Sie die folgende cloudbuild.yaml-Datei auf derselben Ebene wie die pom.xml:

steps:
  # Test your build
  - name: maven:eclipse-temurin
    entrypoint: mvn
    args: ["test"]
  # Build with Jib
  - name: maven:eclipse-temurin
    entrypoint: mvn
    args: [ "compile", "com.google.cloud.tools:jib-maven-plugin:3.2.1:build", "-Dimage=northamerica-northeast1-docker.pkg.dev/PROJECT_ID/migration/visitors:jib"]
  # Deploy to Cloud Run
  - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
    entrypoint: gcloud
    args: [ 'run', 'deploy', 'visitors', '--image', 'northamerica-northeast1-docker.pkg.dev/PROJECT_ID/migration/visitors:jib', '--region', 'northamerica-northeast1', '--allow-unauthenticated']

Wenn wir Cloud Build anweisen, diese Schritte auszuführen, geschieht Folgendes:

  1. Tests mit ./mvnw test ausführen
  2. Mit Jib ein Image erstellen, per Push in die Artifact Registry übertragen und taggen
  3. Image mit gcloud run deploy in Cloud Run bereitstellen

Hinweis: ‘visitors' wird Cloud Run als gewünschter Dienstname übergeben. Mit dem Flag –allow-unauthenticated können Nutzer die Webanwendung aufrufen, ohne sich authentifizieren zu müssen. Ersetzen Sie in der Datei cloudbuild.yaml PROJECT_ID durch die ID Ihres Projekts.

Fügen Sie als Nächstes die folgenden IAM-Richtlinienbindungen hinzu, um das Cloud Build-Dienstkonto für Artifact Registry zuzulassen:

export PROJECT_ID=$(gcloud config list --format 'value(core.project)')
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format="value(projectNumber)" )

gcloud projects add-iam-policy-binding $PROJECT_ID \
--member=serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
--role=roles/run.admin \
--project=$PROJECT_ID
gcloud iam service-accounts add-iam-policy-binding $PROJECT_NUMBER-compute@developer.gserviceaccount.com \
--member=serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
--role roles/iam.serviceAccountUser --project=$PROJECT_ID

2. Build-Prozess ausführen

Nachdem Sie Cloud Build nun über die gewünschten Build-Schritte informiert haben, können Sie mit nur einem Klick bereitstellen.

Führen Sie dazu diesen Befehl aus:

gcloud builds submit

Nach Abschluss des Vorgangs wurde Ihr Container-Image erstellt, in Artifact Registry gespeichert und in Cloud Run bereitgestellt.

Am Ende dieses Codelabs sollte Ihre App genauso aussehen wie die in java17-and-cloud-run/finish.

Sie haben das Lab erfolgreich abgeschlossen. Sie haben eine Java 8-App Engine-Anwendung erfolgreich zu Java 17 und Cloud Run migriert und wissen jetzt besser, was mit dem Wechsel und der Auswahl zwischen Hostingoptionen verbunden ist.

6. Zusammenfassung/Bereinigung

Herzlichen Glückwunsch, Sie haben Ihre App aktualisiert, containerisiert, migriert und damit dieses Tutorial abgeschlossen.

Im nächsten Schritt erfahren Sie mehr über die CI/CD- und Sicherheitsfunktionen für die Softwarelieferkette, die Sie jetzt mit Cloud Build bereitstellen können:

Optional: Dienst bereinigen und/oder deaktivieren

Wenn Sie die Beispiel-App in dieser Anleitung in der App Engine bereitgestellt haben, denken Sie daran, die App zu deaktivieren, um Gebühren zu vermeiden. Wenn Sie bereit sind, mit dem nächsten Codelab fortzufahren, können Sie es wieder aktivieren. Wenn App Engine-Anwendungen deaktiviert sind, werden keine Zugriffe gezählt und es fallen keine Kosten an. Die Datastore-Nutzung kann jedoch in Rechnung gestellt werden, wenn sie das kostenlose Kontingent überschreitet. Löschen Sie daher so viele Daten, dass das Limit nicht überschritten wird.

Wenn Sie die Migrationen jedoch nicht fortsetzen und alles vollständig löschen möchten, können Sie entweder Ihren Dienst löschen oder Ihr Projekt vollständig beenden.

7. Zusätzliche Ressourcen

Probleme/Feedback zu Codelabs zum App Engine-Migrationsmodul

Wenn Sie Probleme mit diesem Codelab feststellen, suchen Sie bitte zuerst nach einer Lösung, bevor Sie eine Meldung senden. Links zum Suchen und Erstellen neuer Probleme:

Ressourcen zur Migration

Onlineressourcen

Nachfolgend finden Sie Onlineressourcen, die für diese Anleitung relevant sein könnten:

App Engine

Weitere Cloud-Informationen

Videos

Lizenz

Dieser Text ist mit einer Creative Commons Attribution 2.0 Generic License lizenziert.