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

1. Übersicht

Diese Reihe von Codelabs – also praxisorientierten Anleitungen zum selbstbestimmten Lernen – soll Entwicklern von Google App Engine (Standard) bei der Modernisierung ihrer Anwendungen helfen, indem sie sie durch eine Reihe von Migrationen führen. Mit den folgenden Schritten können Sie Ihre Anwendung portabler machen und sie für Cloud Run, den Container-Hosting-Dienst von Google Cloud für App Engine, sowie andere Container-Hosting-Dienste in Container verlagern.

In dieser Anleitung erfahren Sie, wie Sie eine App Engine-Anwendung mit Jib für die Bereitstellung im vollständig verwalteten Cloud Run-Dienst containerisieren. Mit Jib können Sie Docker-Images erstellen, einer bekannten Plattform der Branche zum Entwickeln, Versenden und Ausführen von Anwendungen in Containern.

Sie lernen nicht nur die erforderlichen Schritte für den Wechsel von App Engine zu Cloud Run kennen, sondern auch, wie Sie eine Java 8-App Engine-Anwendung auf Java 17 aktualisieren.

Wenn Ihre Anwendung gebündelte Legacy-Dienste von App Engine oder andere App Engine-Funktionen intensiv nutzt, empfehlen wir Ihnen, vor dem Wechsel zu Cloud Run von diesen gebündelten Diensten zu migrieren oder diese Funktionen zu ersetzen. Wenn Sie mehr Zeit zur Prüfung Ihrer Migrationsoptionen benötigen oder vorerst weiter die gebündelten Legacy-Dienste verwenden möchten, können Sie beim Upgrade auf eine neuere Laufzeit weiterhin auf gebündelte App Engine-Dienste für Java 11/17 zugreifen. Wenn Ihre App mobiler 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 nutzen?

<ph type="x-smartling-placeholder"></ph> Nur bis zum Ende lesen Lies sie dir durch und absolviere die Übungen

Wie würden Sie Ihre Erfahrung mit Java bewerten?

<ph type="x-smartling-placeholder"></ph> Neuling Mittel Kompetent

Wie würden Sie Ihre Erfahrungen im Umgang mit Google Cloud-Diensten bewerten?

<ph type="x-smartling-placeholder"></ph> Neuling Mittel Kompetent

2. Hintergrund

PaaS-Systeme (Platform as a Service) wie App Engine und Cloud Functions bieten Ihrem Team und Ihrer Anwendung viele Vorteile. So können sich SysAdmins und DevOps auf die Entwicklung von Lösungen konzentrieren. Mit mehreren Plattformen kann Ihre App nach Bedarf automatisch hochskaliert und mit einer nutzungsbasierten Abrechnung auf null reduziert werden, um die Kosten zu kontrollieren. Außerdem können Sie eine Vielzahl gängiger Entwicklungssprachen verwenden.

Die Flexibilität von Containern ist jedoch auch überzeugend. Container können jede Sprache, Bibliothek und jedes Binärprogramm auswählen und bieten Ihnen das Beste aus beiden Welten: den Komfort von serverlosem Computing und die Flexibilität von Containern. Darum geht es bei Cloud Run.

Die Verwendung von Cloud Run wird in diesem Codelab nicht behandelt. die in der Cloud Run-Dokumentation behandelt werden. Hier erfahren Sie, wie Sie Ihre App Engine-Anwendung für Cloud Run (oder andere containergehostete Dienste) containerisieren. Es gibt einige Dinge, die Sie wissen sollten, bevor Sie fortfahren. Hauptsächlich wird die Nutzererfahrung etwas anders sein.

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

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

Dies beinhaltet die Abschaffung bestimmter App Engine-spezifischer Funktionen. Wenn Sie diesem Pfad nicht folgen möchten, können Sie trotzdem ein Upgrade auf eine Java 11/17-Laufzeit durchführen und Ihre Anwendungen stattdessen in App Engine beibehalten.

3. Einrichtung/Vorarbeit

1. Projekt einrichten

In dieser Anleitung verwenden Sie eine Beispiel-App aus dem Repository appengine-java-migration-samples für ein brandneues Projekt. Achten Sie darauf, dass das Projekt ein aktives Rechnungskonto hat.

Wenn Sie eine vorhandene App Engine-Anwendung nach Cloud Run verschieben möchten, können Sie stattdessen diese Anwendung 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. Baseline-Beispiel-App abrufen

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

Folgendes ist nur erforderlich, wenn Sie vor der Migration zu Cloud Run prüfen möchten, ob die Anwendung in App Engine funktioniert.

Befolgen Sie die Schritte in der Datei README.md:

  1. gcloud-Befehlszeile installieren/neu 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

Nach der Containerisierung Ihrer App müssen Sie Ihre Bilder an einen anderen Ort übertragen und speichern. In Google Cloud wird dazu Artifact Registry empfohlen.

Erstellen Sie das Repository mit dem Namen migration mit gcloud so:

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

Hinweis: Für dieses Repository wird der Formattyp docker verwendet. Es sind aber mehrere Repository-Typen verfügbar.

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

4. Anwendungsdateien modifizieren

Wenn Ihre App die gebündelten Legacy-Dienste, die Konfiguration oder andere reine App Engine-Funktionen stark in Anspruch nimmt, empfehlen wir Ihnen, beim Upgrade auf die neue Laufzeit weiterhin auf diese Dienste zuzugreifen. Dieses Codelab zeigt einen Migrationspfad für Anwendungen, die bereits eigenständige Dienste verwenden oder für diesen Fall refaktoriert werden können.

1. Upgrade auf Java 17

Wenn Ihre Anwendung auf Java 8 läuft, sollten Sie ein Upgrade auf einen neueren LTS-Kandidaten wie 11 oder 17 in Betracht ziehen, um über Sicherheitsupdates auf dem Laufenden zu bleiben 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 eingestellt, das Compiler-Plug-in wird darüber informiert, dass Sie auf Java 17-Sprachfunktionen zugreifen möchten und dass die kompilierten Klassen mit der Java 17 JVM kompatibel sein sollen.

2. Webserver einschließen

Zwischen App Engine und Cloud Run gibt es eine Reihe von Unterschieden, die beim Wechsel zwischen App Engine und Cloud Run zu berücksichtigen sind. Ein Unterschied besteht darin, dass die Java 8-Laufzeit von App Engine einen Jetty-Server für die gehosteten Anwendungen bereitgestellt und verwaltet hat, Cloud Run jedoch nicht. 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 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 Paket com.example.appengine:

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 Annotation @ServletComponentScan, die standardmäßig im aktuellen Paket nach @WebServlets sucht und sie wie erwartet zur Verfügung stellt.

4. Anwendung als JAR-Datei verpacken

Es ist zwar möglich, Ihre Anwendung mit Jib aus einem Krieg in Container zu verlagern, es wird jedoch einfacher, wenn Sie Ihre Anwendung als ausführbare JAR-Datei verpacken. Dies erfordert keine umfangreiche Konfiguration, insbesondere bei Projekten, bei denen Maven als Build-Tool verwendet wird, da die JAR-Paketerstellung das Standardverhalten ist.

Entfernen Sie das packaging-Tag in 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. Migration weg von App Engine-Konfiguration, ‐Diensten und ‐Abhängigkeiten

Wie zu Beginn des Codelabs erwähnt, sind Cloud Run und App Engine auf unterschiedliche Nutzerumgebungen ausgelegt. Bestimmte sofort verfügbare Funktionen von App Engine – wie die Dienste Cron und Task Queue – müssen manuell neu erstellt werden. Diese 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 die Bereitstellung ab jetzt in Cloud Run erfolgt, kann 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

An dieser Stelle können Sie Ihre Anwendung direkt aus Ihrem Quellcode manuell in Cloud Run bereitstellen. Dies ist eine hervorragende Option, die Cloud Build im Hintergrund verwendet, um eine automatische Bereitstellung zu ermöglichen. Bereitstellungen von Quellen werden in späteren Modulen ausführlicher behandelt.

Wenn Sie mehr Kontrolle darüber haben möchten, wie Ihre App bereitgestellt wird, können Sie dies erreichen, indem Sie eine cloudbuild.yaml-Datei definieren, in der die beabsichtigten Build-Schritte explizit aufgeführt sind:

1. Datei cloudbuild.yaml 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']

Sobald wir Cloud Build angewiesen haben, diese Schritte auszuführen, geschieht Folgendes:

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

Beachten Sie, dass ‘visitors' als gewünschter Dienstname an Cloud Run übergeben wird. Mit dem Flag –allow-unauthenticated können Nutzer die Web-App ohne Authentifizierung aufrufen. Ersetzen Sie PROJECT_ID in der Datei cloudbuild.yaml 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

Sobald der Vorgang abgeschlossen ist, wurde das Container-Image erstellt, in Artifact Registry gespeichert und in Cloud Run bereitgestellt.

Am Ende dieses Codelabs sollte Ihre Anwendung 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 Anwendung aktualisiert, containerisiert und migriert. Damit ist diese Anleitung abgeschlossen.

Im nächsten Schritt erfahren Sie mehr über die Sicherheitsfunktionen für CI/CD und die Softwarelieferkette, die jetzt für die Bereitstellung mit Cloud Build verfügbar sind:

Optional: Speicherplatz bereinigen und/oder Dienst deaktivieren

Wenn Sie die Beispielanwendung im Rahmen dieser Anleitung in App Engine bereitgestellt haben, denken Sie daran, die Anwendung zu deaktivieren, um Gebühren zu vermeiden. Wenn Sie bereit sind, mit dem nächsten Codelab fortzufahren, können Sie es wieder aktivieren. Während App Engine-Anwendungen deaktiviert sind, wird für sie kein Traffic erzeugt, der Kosten verursacht. Die Datenspeichernutzung kann jedoch kostenpflichtig werden, wenn das kostenlose Kontingent überschritten wird. Löschen Sie daher so viel, dass Sie unter dieses Limit fallen.

Wenn Sie jedoch nicht mit der Migration fortfahren und alles vollständig löschen möchten, können Sie entweder den Dienst löschen oder das Projekt vollständig herunterfahren.

7. Zusätzliche Ressourcen

Codelabs-Probleme/Feedback mit App Engine-Migrationsmodul

Wenn Sie Probleme mit diesem Codelab feststellen, suchen Sie bitte zuerst nach dem Problem, bevor Sie es einreichen. Links zum Suchen und Erstellen neuer Ausgaben:

Ressourcen für die Migration

Online-Ressourcen

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.