Mit Buildpacks von der Google App Engine-Java-Anwendung zu Cloud Run 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. 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 eine App Engine-Anwendung mithilfe von Buildpacks für die Bereitstellung im vollständig verwalteten Cloud Run-Dienst containerisieren. Buildpacks sind ein CNCF-Projekt, mit dem Sie Ihre App direkt vom Quellcode in äußerst portable Images aufnehmen können, die in jeder Cloud ausgeführt werden können.

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 in der Anwendung, die Sie migrieren möchten, häufig gebündelte App Engine-Legacy-Dienste oder andere App Engine-spezifische Funktionen verwendet werden, ist der Leitfaden Auf gebündelte App Engine-Dienste für Java 11/17 zugreifen möglicherweise besser geeignet als dieses Codelab.

Sie lernen,

  • Cloud Shell verwenden
  • Cloud Run-, Artifact Registry- und Cloud Build APIs aktivieren
  • Anwendung mit Buildpacks in 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 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. 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 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 Google Cloud Run.

Die Verwendung von Cloud Run wird in diesem Codelab nicht behandelt. Weitere Informationen finden Sie in der Cloud Run-Dokumentation. Hier erfahren Sie, 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. Sie erfahren, wie Sie Ihre Anwendung mit Buildpacks containerisieren, von der App Engine-Konfiguration migrieren und Buildschritte für Cloud Build definieren. Dies bedeutet, dass bestimmte App Engine-spezifische Funktionen nicht mehr unterstützt werden. Wenn Sie diesem Weg 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 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 der 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.

Folgen Sie der Anleitung in der README.md-Datei:

  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 App in der App Engine ohne Probleme 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 die 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 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 Properties in Ihrer pom.xml, um Folgendes aufzunehmen:

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

Es gibt eine Reihe von Unterschieden zwischen der App Engine und Cloud Run, die Sie bei der Migration berücksichtigen sollten. 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 einen Webserver und einen Servlet-Container bereitzustellen.

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. In diesem Beispiel wird dieses Artefakt jedoch ausgeschlossen und Jetty verwendet, um Unterschiede im Standardverhalten nach der Migration zu minimieren.

3. Spring Boot-Einrichtung

Spring Boot kann Ihre Servlets zwar ohne Änderungen wiederverwenden, es ist jedoch eine gewisse Konfiguration erforderlich, um sicherzustellen, dass sie auffindbar sind.

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 @ServletComponentScan-Anmerkung, die standardmäßig im aktuellen Paket nach allen @WebServlets sucht und sie wie erwartet verfügbar macht.

4. Build-Konfiguration

Entfernen Sie als Nächstes die Konfiguration, um unsere Anwendung als WAR-Paket zu 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 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 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.

In der Beispielanwendung werden keine gebündelten Legacy-Dienste verwendet. Nutzer, deren Apps diese Dienste verwenden, können die folgenden Anleitungen verwenden:

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 und bereitstellen

Jetzt können Sie Ihre Anwendung direkt über den Quellcode in Cloud Run bereitstellen. Dies ist eine hervorragende Option, die Cloud Build im Hintergrund verwendet, um eine automatische Bereitstellung zu ermöglichen. Um diese Funktion nutzen zu können, benötigen Sie entweder ein Konto mit mindestens einer der folgenden Berechtigungen und müssen die Schritte zur Umgebungseinrichtung ausgeführt haben oder die Cloud Shell verwenden:

Wenn diese Voraussetzungen erfüllt sind, führen Sie einfach folgenden Befehl aus Ihrem Quellverzeichnis aus:

gcloud run deploy SERVICE --source .

Während des Befehls „Bereitstellen ausführen“ werden Sie zur Eingabe verschiedener Informationen aufgefordert, z. B.:

  • Speicherort des Quellcodes angeben
  • Dienstnamen angeben
  • Cloud Run API aktivieren
  • Region auswählen

Nachdem Sie diese Prompts beantwortet haben, beginnt der Build- und Bereitstellungsprozess. Dabei führt Cloud Build die folgenden Schritte aus:

  • Ihre Quelle wird gezippt und in einem Cloud Storage-Bucket gespeichert.
  • verwendet die Cloud Native Computing Foundation-Buildpacks im Hintergrund, um Ihr Image zu erstellen
  • Erstellt eine Registry zum Speichern des resultierenden Container-Images (falls nicht bereits vorhanden)
  • und erstellt einen Cloud Run-Dienst zum Hosten Ihrer Anwendung (falls noch nicht vorhanden)

Sobald der Build und die Bereitstellung abgeschlossen sind, sollten Sie eine Nachricht erhalten, in der Sie darüber informiert werden, dass eine neue Version live geschaltet ist und 100% des Traffics verarbeitet.

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: Speicherplatz bereinigen und/oder Dienst 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 mit dem nächsten Codelab fortfahren möchten, können Sie die Funktion 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 Ihrem Problem, bevor Sie es einreichen. Links zum Suchen und Erstellen neuer Probleme:

Ressourcen für die Migration

Onlineressourcen

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