Migracja z aplikacji Google App Engine w Javie do Cloud Run za pomocą pakietu Buildpacks

1. Omówienie

Ta seria ćwiczeń z programowania (do samodzielnego ukończenia, praktycznych samouczków) ma pomóc programistom w Google App Engine (w wersji standardowej) Java w modernizacji aplikacji przez przeprowadzenie serii migracji. Wykonując te czynności, możesz zaktualizować aplikację, aby stała się bardziej przenośna, i zdecydować się na jej skonteneryzowanie na potrzeby Cloud Run, siostrzanej usługi hostowania kontenerów w Google Cloud do App Engine i innych usług hostingu kontenerów.

Z tego samouczka dowiesz się, jak skonteneryzować aplikację App Engine na potrzeby wdrożenia w w pełni zarządzanej usłudze Cloud Run za pomocą pakietów Buildpack. Buildpacks to projekt CNCF, który pozwala przenieść aplikację bezpośrednio z kodu źródłowego do wysoce przenośnych obrazów działających w dowolnej chmurze.

Oprócz instrukcji, jak przejść z App Engine na Cloud Run, dowiesz się też, jak zaktualizować aplikację App Engine w języku Java 8 do wersji 17.

Jeśli aplikacja, którą chcesz przenieść, intensywnie korzysta ze starszych pakietów usług App Engine lub innych funkcji związanych z App Engine, lepiej może zapoznać się z przewodnikiem Uzyskiwanie dostępu do pakietów usług App Engine w języku Java 11/17.

Dowiesz się, jak:

  • Użyj Cloud Shell
  • Włączanie interfejsów Cloud Run API, Artifact Registry API i Cloud Build API
  • Konteneryzowanie aplikacji za pomocą pakietów Buildpack w Cloud Build
  • Wdrażanie obrazów kontenerów w Cloud Run

Czego potrzebujesz

Ankieta

Jak wykorzystasz ten samouczek?

Tylko do przeczytania Przeczytaj go i wykonaj ćwiczenia

Jak oceniasz swoje doświadczenia z Javą?

Początkujący Poziom średnio zaawansowany Biegły

Jak oceniasz korzystanie z usług Google Cloud?

Początkujący Poziom średnio zaawansowany Biegły

2. Tło

Systemy PaaS, takie jak App Engine i Cloud Functions, zapewniają wiele udogodnień dla Twojego zespołu i aplikacji, na przykład umożliwiając administratorom i Devopsom skupienie się na tworzeniu rozwiązań. Dzięki platformom bezserwerowym aplikacja może autoskalować w górę w razie potrzeby, skalować w dół do zera za pomocą płatności za wykorzystanie, co pomaga kontrolować koszty. Aplikacja jest też dostępna w różnych popularnych językach programowania.

Jednak elastyczność kontenerów także jest bardzo atrakcyjna. Kontenery umożliwiają wybór dowolnego języka, biblioteki i pliku binarnego, co łączy zalety obu rozwiązań: wygodę obsługi rozwiązań bezserwerowych i elastyczność kontenerów. Właśnie na tym polega Google Cloud Run.

W ramach tego ćwiczenia z programowania dowiesz się, jak korzystać z Cloud Run. które znajdziesz w dokumentacji Cloud Run. Dzięki temu dowiesz się, jak skonteneryzować aplikację 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. Dowiesz się, jak skonteneryzować aplikację za pomocą pakietu Buildpacks, przejść z niej z konfiguracji App Engine i jak definiować kroki kompilacji w Cloud Build. Wiąże się to z odejściem od niektórych funkcji App Engine. Jeśli nie chcesz podążać tą ścieżką, możesz uaktualnić środowisko wykonawcze Java do wersji 11/17, a jednocześnie pozostawić aplikacje w App Engine.

3. Konfiguracja/praca

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 użyć tej aplikacji.

Uruchom to polecenie, aby włączyć interfejsy API niezbędne w projekcie:

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

2. Pobierz przykładową aplikację bazową

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

Przykład to aplikacja Datastore w języku Java 8 oparta na serwletach i przeznaczona do wdrożenia w App Engine. Postępuj zgodnie z instrukcjami w pliku README, aby dowiedzieć się, jak przygotować tę aplikację do wdrożenia App Engine.

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

Wykonaj te czynności tylko wtedy, gdy przed migracją do Cloud Run chcesz potwierdzić, że aplikacja działa w App Engine.

Zapoznaj się z instrukcjami w pliku README.md:

  1. Zainstaluj i ponownie zapoznaj się z interfejsem wiersza poleceń gcloud
  2. Zainicjuj interfejs wiersza poleceń gcloud dla swojego projektu za pomocą interfejsu 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
  1. Sprawdź, czy aplikacja działa w App Engine bez problemów

4. Utwórz repozytorium Artifact Registry

Po skonteneryzowaniu aplikacji musisz mieć miejsce, w którym będzie można przekazać i przechowywać obrazy. Zalecanym sposobem na rozwiązanie tego problemu w Google Cloud jest użycie Artifact Registry.

Utwórz repozytorium o nazwie migration za pomocą gcloud:

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

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

W tej chwili masz już bazową aplikację App Engine i Twój projekt Google Cloud jest gotowy do migracji do Cloud Run.

4. Modyfikuj pliki 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. To ćwiczenie w Codelabs pokazuje ścieżkę migracji aplikacji, które korzystają już z samodzielnych usług lub które można refaktoryzować, aby to zrobić.

1. Uaktualnianie do wersji Java 17

Jeśli Twoja aplikacja działa w Javie 8, rozważ przejście na nowszą wersję kandydującą kanału LTS, taką jak 11 lub 17, aby być na bieżąco z aktualizacjami zabezpieczeń i uzyskać dostęp do nowych funkcji językowych.

Zacznij od dodania tych właściwości w elemencie pom.xml:

<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 i informację, że chcesz uzyskać dostęp do funkcji języka Java 17 oraz że skompilowane klasy będą zgodne z kodem Java 17 JVM.

2. Uwzględnienie serwera 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 chociaż środowisko wykonawcze Java 8 w App Engine udostępniało serwer Jetty dla hostowanych aplikacji i zarządzał nim, Cloud Run tego nie robi. Użyjemy Spring Boot, aby udostępnić serwer WWW i kontener serwletu.

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 ten przykład wyklucza ten artefakt i pozostaje przy Jetty, aby zminimalizować różnice w domyślnym działaniu po migracji.

3. Konfiguracja buta sprężynowego

Usługa Spring Boot będzie mogła ponownie wykorzystywać serwlety bez modyfikacji, ale wymaga pewnej konfiguracji, by zapewnić wykrywalność.

Utwórz te zajęcia MigratedServletApplication.java w pakiecie 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);
    }
}

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. Konfiguracja kompilacji

Następnie usuń konfigurację, aby spakować naszą aplikację jako WAR. Nie wymaga to dużej konfiguracji, zwłaszcza w przypadku projektów, w których jako narzędzie do kompilacji używasz Maven – pakiet jar jest działaniem domyślnym.

Usuń tag packaging z 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 wspomnieliśmy na początku ćwiczeń z programowania, usługi Cloud Run i App Engine zostały zaprojektowane tak, aby oferować różne możliwości użytkownikom. Niektóre funkcje dostępne w App Engine, takie jak usługi Cron i Kolejka zadań, trzeba odtworzyć ręcznie. Zostaną one omówione bardziej szczegółowo w kolejnych modułach.

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

Ponieważ od teraz będziesz wdrażać w Cloud Run, interfejs appengine-maven-plugin można usunąć:

<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 Wdrażanie aplikacji

Na tym etapie możesz wdrożyć aplikację w Cloud Run bezpośrednio z kodu źródłowego. To doskonała opcja, która wykorzystuje za kulisy Cloud Build, aby zapewnić praktyczne doświadczenie podczas wdrażania. Aby korzystać z tej funkcji, musisz mieć konto z co najmniej jednym z tych uprawnień oraz wykonać te kroki konfiguracji środowiska lub użyć Cloud Shell:

Po spełnieniu tych wymagań wstępnych po prostu uruchom to polecenie z katalogu źródłowego:

gcloud run deploy SERVICE --source .

Podczas wykonywania polecenia wdrożenia pojawi się kilka informacji, na przykład:

  • Podawanie lokalizacji kodu źródłowego
  • Podawanie nazwy usługi
  • Włączanie Cloud Run API
  • Wybieranie regionu

Po udzieleniu odpowiedzi na te prompty rozpoczyna się proces kompilacji i wdrażania, podczas którego Cloud Build wykonuje te działania:

  • kompresuje i zapisuje źródło w zasobniku Cloud Storage
  • do kompilacji obrazu korzysta w tle pakiety kompilacji Cloud Native Computing Foundation
  • tworzy rejestr do przechowywania wynikowego obrazu kontenera (jeśli jeszcze go nie ma);
  • Tworzy usługę Cloud Run hostującą Twoją aplikację (jeśli jeszcze jej nie ma)

Po zakończeniu kompilacji i wdrożenia powinien wyświetlić się komunikat wyjaśniający, że nowa wersja jest już aktywna i obsługuje 100% ruchu.

6. Podsumowanie/Czyszczenie

Gratulujemy! Udało Ci się przejść na nową wersję, skonteneryzować i przeprowadzić migrację, a Twoja aplikacja to już koniec samouczka.

Następnym krokiem jest zapoznanie się z funkcjami zabezpieczeń CI/CD i łańcucha dostaw oprogramowania, które są w zasięgu ręki, które można wdrożyć za pomocą Cloud Build.

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

Jeśli w ramach tego samouczka wdrożysz przykładową aplikację w App Engine, pamiętaj o wyłączeniu tej aplikacji, aby uniknąć naliczania opłat. Gdy uznasz, że chcesz przejść do kolejnego ćwiczenia z programowania, możesz je ponownie włączyć. Aplikacje App Engine są wyłączone, ale nie generują ruchu, który powoduje naliczanie opłat. Jednak wykorzystanie magazynu danych może zostać obciążone, jeśli przekroczy bezpłatny limit, więc usuń tyle miejsca, by zmieścić się w tym limicie.

Jeśli natomiast nie zamierzasz kontynuować migracji i chcesz całkowicie usunąć wszystko, możesz usunąć usługę lub wyłączyć projekt.

7. Dodatkowe materiały

Problemy/opinie dotyczące modułu migracji App Engine

Jeśli podczas korzystania z tych ćwiczeń z programowania zauważysz jakiekolwiek problemy, najpierw je wyszukaj. Linki do wyszukiwania i tworzenia nowych problemów:

Zasoby migracji

Zasoby online

Poniżej znajdują się zasoby online, które mogą być pomocne w przypadku tego samouczka:

App Engine

Inne informacje o Google Cloud

Filmy

Licencja

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