Migracja z aplikacji Google App Engine w Javie do Cloud Run przy użyciu Jib

1. Omówienie

Ta seria ćwiczeń z programowania (do samodzielnego ukończenia, praktycznych samouczków) ma na celu pomóc deweloperom aplikacji Java w Google App Engine (standardowym) w modernizacji ich aplikacji przez przeprowadzenie serii migracji. Wykonując te czynności, możesz zaktualizować aplikację, aby była bardziej przenośna, i zdecydować się na jej skonteneryzowanie na potrzeby Cloud Run, czyli usługi Google Cloud, która jest usługą siostrza App Engine hostującą kontenery, oraz innych usług hostujących kontenery.

Z tego samouczka dowiesz się, jak skonteneryzować aplikację App Engine w celu jej wdrożenia w ramach w pełni zarządzanej usługi Cloud Run za pomocą Jib. Jib umożliwia tworzenie obrazów w Docker – dobrze znanej w branży platformy do tworzenia, przesyłania i uruchamiania aplikacji w kontenerach.

Oprócz pokazania Ci wymaganych czynności, które należy wykonać, aby przenieść aplikację z App Engine do Cloud Run, pokażemy Ci też, jak uaktualnić aplikację App Engine w Javie 8 do wersji Java 17.

Jeśli Twoja aplikacja intensywnie korzysta z usług w starszych pakietach App Engine lub innych funkcji App Engine, zalecamy przeniesienie tych usług lub zastąpienie tych funkcji przed przejściem na Cloud Run. Jeśli potrzebujesz więcej czasu na zapoznanie się z opcjami migracji lub chcesz na razie korzystać ze starszych pakietów usług, możesz nadal przechodzić do pakietów usług App Engine dla Javy 11/17 po przejściu na nowszą wersję środowiska wykonawalnego. Gdy aplikacja będzie bardziej przenośna, wróć do tego Codelab, aby dowiedzieć się, jak zastosować te instrukcje w swojej aplikacji.

Dowiesz się, jak

• Korzystanie z Cloud Shell
• Włącz interfejsy Cloud Run API, Artifact Registry API i Cloud Build API
• Skonteneryzowanie aplikacji za pomocą Jib i Cloud Build
• Wdrażanie obrazów kontenera w Cloud Run

Czego potrzebujesz

• projekt Google Cloud Platform z aktywnym kontem rozliczeniowym GCP i włączonym App Engine
• praktyczna znajomość typowych poleceń systemu Linux;
• podstawowa wiedza o tworzeniu i wdrażaniu aplikacji App Engine;
• Aplikacja serwletu Java 8, którą chcesz przenieść do Javy 17 i wdrożyć w Cloud Run (może to być aplikacja w App Engine lub tylko aplikacja źródłowa).

Ankieta

Jak będziesz korzystać z tego samouczka?

Tylko przeczytać Przeczytać i wykonać ćwiczenia

Jak oceniasz swoje wrażenia z korzystania z języka Java?

Początkujący Średnio zaawansowany Zaawansowany

Jak oceniasz korzystanie z usług Google Cloud?

Początkujący Średnio zaawansowany Zaawansowany

2. Tło

Systemy platformy jako usługi (PaaS), takie jak App Engine i Cloud Functions, zapewniają wiele udogodnień dla Twojego zespołu i aplikacji, np. umożliwiają administratorom systemów i zespołom DevOps skupienie się na tworzeniu rozwiązań. Dzięki platformom bezserwerowym Twoja aplikacja może automatycznie skalować się w miarę potrzeby, a także zmniejszać do zera dzięki płatnościom za użycie, co pomaga kontrolować koszty. Możesz też używać różnych popularnych języków programowania.

Jednak elastyczność kontenerów również jest kusząca. Dzięki możliwości wyboru dowolnego języka, dowolnej biblioteki i dowolnego binarnego kontenery łączą w sobie to, co najlepsze z obu światów: wygodę bezserwerową i elastyczność kontenerów. O to właśnie chodzi Cloud Run.

Ten projekt nie obejmuje nauki korzystania z Cloud Run. Informacje na ten temat znajdziesz w dokumentacji Cloud Run. Celem tego ćwiczenia jest zapoznanie się z konteneryzacją aplikacji App Engine na potrzeby Cloud Run (lub innych usług hostowanych w kontenerach). Jest kilka rzeczy, o których musisz wiedzieć, zanim przejdziesz dalej, przede wszystkim dlatego, że interfejs Twojej witryny będzie nieco inny.

Z tego ćwiczenia w Codelabs dowiesz się, jak tworzyć i wdrażać kontenery. Poznasz takie zagadnienia jak:

• Konteneryzowanie aplikacji za pomocą Jib
• Migracja z konfiguracji App Engine
• i opcjonalnie zdefiniuj kroki kompilacji w Cloud Build.

Oznacza to rezygnację z niektórych funkcji App Engine. Jeśli nie chcesz tego robić, możesz przejść na środowisko uruchomieniowe Java 11/17, zachowując przy tym aplikacje w App Engine.

3. Konfiguracja/wstępne przygotowanie

1. Skonfiguruj projekt

W tym samouczku użyjesz przykładowej aplikacji z repozytorium appengine-java-migration-samples w zupełnie nowym projekcie. Sprawdź, czy projekt ma aktywne konto rozliczeniowe.

Jeśli chcesz przenieść istniejącą aplikację App Engine do Cloud Run, możesz zamiast tego użyć tej aplikacji.

Aby włączyć wymagane interfejsy API w projekcie, uruchom to polecenie:

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

2. Pobieranie przykładowej aplikacji podstawowej

Sklonuj przykładową aplikację na swoim komputerze lub w Cloud Shell, a następnie przejdź do folderu baseline.

Przykładowa aplikacja to Servlet w Javie 8, przeznaczona do wdrożenia w App Engine. Postępuj zgodnie z instrukcjami w pliku README, aby przygotować tę aplikację do wdrożenia w App Engine.

3. (Opcjonalnie) Wdróż aplikację bazową

Poniższe czynności są konieczne tylko wtedy, gdy chcesz sprawdzić, czy aplikacja działa w App Engine, zanim przeprowadzimy ją do Cloud Run.

Zapoznaj się z instrukcjami w pliku README.md:

1. Zainstaluj interfejs wiersza poleceń gcloud lub przypomnij sobie, jak z niego korzystać
2. Zainicjuj gcloud CLI dla projektu za pomocą gcloud init
3. Tworzenie projektu App Engine w narzędziu gcloud app create
4. Wdrażanie przykładowej aplikacji w App Engine

./mvnw package appengine:deploy -Dapp.projectId=$PROJECT_ID

5. Sprawdź, czy aplikacja działa w App Engine bez problemów

4. Tworzenie repozytorium Artifact Registry

Po skonteneryzowaniu aplikacji musisz mieć miejsce na przesyłanie i przechowywanie obrazów. Zalecany sposób wykonania tej operacji w Google Cloud to użycie Artifact Registry.

Utwórz repozytorium o nazwie migration za pomocą gcloud w ten sposób:

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

Pamiętaj, że ten repozytorium używa formatu docker, ale dostępnych jest kilka typów repozytoriów.

W tym momencie masz już podstawową aplikację App Engine, a Twój projekt Google Cloud jest gotowy do przeniesienia jej do Cloud Run.

4. Modyfikowanie plików aplikacji

Jeśli Twoja aplikacja intensywnie korzysta ze starszych pakietów usług, konfiguracji lub innych funkcji App Engine, zalecamy dalsze korzystanie z tych usług podczas uaktualniania do nowego środowiska wykonawczego. Ten projekt pokazuje ścieżkę migracji aplikacji, które już korzystają z samodzielnych usług lub mogą zostać przekształcone w takie.

1. Przechodzenie na Java 17

Jeśli Twoja aplikacja jest napisana w wersji Java 8, rozważ przejście na nowszą wersję LTS, np. 11 lub 17, aby otrzymywać aktualizacje zabezpieczeń i mieć dostęp do nowych funkcji językowych.

Najpierw zaktualizuj właściwości w swoim pliku pom.xml, aby uwzględnić te elementy:

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

Spowoduje to ustawienie wersji projektu na 17, poinformowanie wtyczki kompilatora, że chcesz uzyskać dostęp do funkcji języka Java 17, oraz żądanie zgodności skompilowanych klas z Java 17 JVM.

2. Serwer WWW

Istnieje kilka różnic między App Engine i Cloud Run, które warto wziąć pod uwagę, przechodząc między nimi. Jedną z różnic jest to, że środowisko wykonawcze Java 8 w App Engine zapewniało i zarządzało serwerem Jetty dla hostowanych aplikacji, a Cloud Run tego nie robi. Użyjemy Spring Boot do utworzenia serwera WWW i kontenera servleta.

Dodaj te zależności:

<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 domyślnie osadza serwer Tomcat, ale w tym przykładzie wykluczymy ten element i użyjemy Jetty, aby zminimalizować różnice w domyślnym zachowaniu po migracji. W modelu Jetty możemy też pasować do wersji udostępnianej przez App Engine.

<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. Konfiguracja butów sprężynujących

Choć Spring Boot będzie mógł ponownie wykorzystywać serwlety bez modyfikacji, będzie to wymagać pewnej konfiguracji, by zapewnić wykrywalność.

Utwórz w pakiecie com.example.appengine klasę MigratedServletApplication.java:

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);
    }
}

Pamiętaj, że obejmuje to adnotację @ServletComponentScan, która domyślnie sprawdza (w aktualnym pakiecie) wszystkie te elementy z @WebServlets, i udostępnia je zgodnie z oczekiwaniami.

4. Pakowanie aplikacji jako pliku JAR

Chociaż można skonteneryzować aplikację za pomocą narzędzia Jib rozpoczynającego się wojnę, będzie to łatwiejsze, jeśli spakujesz aplikację jako wykonywalny plik JAR. Nie wymaga to wielu ustawień, zwłaszcza w przypadku projektów, które używają Maven jako narzędzia do kompilacji, ponieważ pakowanie jar jest domyślnym zachowaniem.

Usuń tag packaging w pliku pom.xml:

<packaging>war</packaging>

Następnie dodaj spring-boot-maven-plugin:

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

5. Migracja z konfiguracji, usług i zależności App Engine

Jak wspomniano na początku tego ćwiczenia, Cloud Run i App Engine są zaprojektowane tak, aby zapewniać użytkownikom różne wrażenia. Niektóre funkcje, które App Engine oferuje domyślnie, np. usługi Cron i kolejka zadań, trzeba ponownie utworzyć ręcznie. Więcej informacji na ten temat znajdziesz w kolejnych modułach.

Przykładowa aplikacja nie korzysta ze starszych usług w pakiecie, ale użytkownicy, których aplikacje korzystają z tych usług, mogą skorzystać z tych przewodników:

• Migracja z pakietu usług, aby znaleźć odpowiednie usługi samodzielne.
• Przeniesienie plików konfiguracji XML do formatu YAML – dla użytkowników, którzy migrują do środowisk wykonawczych Java 11/17, pozostając w App Engine.

Od teraz będziesz wdrażać aplikację w Cloud Run, więc możesz usunąć appengine-maven-plugin:

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

W tym momencie możesz ręcznie wdrożyć aplikację do Cloud Run bezpośrednio z kodu źródłowego. To doskonała opcja, która wykorzystuje Cloud Build w tle, aby zapewnić automatyczne wdrażanie. Wdrożenia źródłowe omówimy bardziej szczegółowo w kolejnych modułach.

Jeśli chcesz mieć większą kontrolę nad sposobem wdrażania aplikacji, możesz zdefiniować plik cloudbuild.yaml, który wyraźnie określa kroki kompilacji:

1. Definiowanie pliku cloudbuild.yaml

Utwórz plik cloudbuild.yaml na tym samym poziomie co plik 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']

Gdy podamy Cloud Buildowi te instrukcje, wykona on te czynności:

1. Uruchamianie testów za pomocą ./mvnw test
2. Utwórz obraz, przenieś go do Artifact Registry i dodaj do niego tagi za pomocą Jib.
3. Wdróż obraz w Cloud Run za pomocą gcloud run deploy

Pamiętaj, że ‘visitors' jest przekazywane do Cloud Run jako żądana nazwa usługi. Flaga –allow-unauthenticated umożliwia użytkownikom otwieranie aplikacji internetowej bez konieczności uwierzytelniania. Pamiętaj, aby w pliku cloudbuild.yaml zastąpić ciąg znaków PROJECT_ID identyfikatorem swojego projektu.

Następnie dodaj te reguły wiązania zasad uprawnień, aby umożliwić kontu usługi Cloud Build dostęp do usługi Artifact Registry:

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:$[e-mail] \
--role=roles/run.admin \
--project=$PROJECT_ID
gcloud iam service-accounts add-iam-policy-binding $[e-mail] \
--member=serviceAccount:$[e-mail] \
--role roles/iam.serviceAccountUser --project=$PROJECT_ID

2. Uruchomienie procesu kompilacji

Gdy już podasz Cloud Build odpowiednie kroki kompilacji, możesz wdrożyć usługę jednym kliknięciem.

Uruchom to polecenie:

gcloud builds submit

Po zakończeniu procesu obraz kontenera zostanie skompilowany, przechowywany w Artifact Registry i wdrożony w Cloud Run.

Na koniec tego ćwiczenia Twoja aplikacja powinna wyglądać tak samo jak ta w java17-and-cloud-run/finish.

I to wszystko! Udało Ci się przenieść aplikację App Engine w Javie 8 do Javi 17 i Cloud Run. Masz już większą świadomość tego, ile pracy wymaga przejście na nową wersję i wybór opcji hostingu.

6. Podsumowanie/czyszczenie

Gratulacje! Aplikacja została zaktualizowana, spakowana do kontenera i przeniesiona. To koniec tego samouczka.

Następnie dowiedz się więcej o funkcjach CI/CD i zabezpieczeniach łańcucha dostaw oprogramowania, które możesz wdrażać za pomocą Cloud Build:

• Tworzenie niestandardowych kroków kompilacji za pomocą Cloud Build
• Tworzenie aktywatorów kompilacji i zarządzanie nimi
• Korzystanie z skanowania na żądanie w potoku Cloud Build

Opcjonalnie: wyczyść lub wyłącz usługę

Jeśli w ramach tego samouczka wdrożono przykładową aplikację w App Engine, pamiętaj, aby ją wyłączyć, aby uniknąć opłat. Gdy uznasz, że chcesz przejść do kolejnego ćwiczenia z programowania, możesz je ponownie włączyć. Gdy aplikacje App Engine są wyłączone, nie będą generować ruchu, który powoduje naliczanie opłat. Użycie bazy danych może jednak być obciążone opłatą, jeśli przekroczy bezpłatny limit. Usuń więc wystarczającą liczbę aplikacji, aby nie przekroczyć tego limitu.

Jeśli z kolei nie chcesz kontynuować migracji i chcesz całkowicie usunąć wszystko, możesz usunąć usługę lub zamknąć projekt.

7. Dodatkowe materiały

Problemy i opinie dotyczące ćwiczeń w Codelab dotyczących modułu migracji App Engine

Jeśli zauważysz problemy z tym Codelab, najpierw je wyszukaj, a potem prześlij zgłoszenie. Linki do wyszukiwania i tworzenia nowych problemów:

• Wyszukiwanie problemów
• Przesyłanie nowego problemu lub opinii

Zasoby dotyczące migracji

• Opcje migracji w przypadku rozdzielenia usług App Engine
• Konfigurowanie aktywatorów kompilacji w Cloud Build
• Więcej informacji na temat migracji do środowiska Java 11/17

Zasoby online

Poniżej znajdziesz zasoby online, które mogą być przydatne w tym samouczku:

App Engine

• Dokumentacja App Engine
• informacje o cenach i limitach App Engine;
• Porównanie platform pierwszej i drugiej generacji
• Długoterminowe wsparcie dla starszych środowisk uruchomieniowych

Inne informacje dotyczące Cloud

• poziom „Zawsze bezpłatne” w Google Cloud
• Google Cloud CLI (gcloud CLI)
• Cała dokumentacja Google Cloud

Filmy

• Stacja migracji do technologii bezserwerowych
• Ekspedycje bezserwerowe
• Zasubskrybuj Google Cloud Tech
• Zasubskrybuj Google Developers

Licencja

To zadanie jest licencjonowane na podstawie ogólnej licencji Creative Commons Attribution 2.0.