Migrazione dall'app Java di Google App Engine a Cloud Run con Jib

1. Panoramica

Questa serie di codelab (tutorial pratici e self-service) mira ad aiutare gli sviluppatori Java di Google App Engine (standard) a modernizzare le loro app, guidandoli attraverso una serie di migrazioni. Seguendo questi passaggi, puoi aggiornare la tua app per renderla più portabile e decidere di containerizzarla per Cloud Run, il servizio gemello di hosting di container di Google Cloud per App Engine e altri servizi di hosting di container.

Questo tutorial ti insegna a eseguire il containerizzazione di un'app App Engine per il deployment nel servizio completamente gestito Cloud Run utilizzando Jib. Con Jib puoi creare immagini Docker, una piattaforma ben nota nel settore per lo sviluppo, la distribuzione e l'esecuzione di applicazioni in container.

Oltre a insegnarti i passaggi necessari per passare da App Engine a Cloud Run, imparerai anche come eseguire l'upgrade di un'app App Engine Java 8 a Java 17.

Se la tua applicazione utilizza molto i servizi integrati precedenti di App Engine o altre funzionalità di App Engine, ti consigliamo di eseguire la migrazione da questi servizi integrati o di sostituire queste funzionalità prima di passare a Cloud Run. Se hai bisogno di più tempo per valutare le opzioni di migrazione o vuoi continuare a utilizzare i servizi in bundle legacy per il momento, puoi continuare ad accedere ai servizi in bundle di App Engine per Java 11/17 quando esegui l'upgrade a un runtime più recente. Quando la tua app è più portabile, torna a questo codelab per scoprire come applicare le istruzioni alla tua app.

Imparerai a utilizzare

  • Utilizza Cloud Shell
  • Abilita le API Cloud Run, Artifact Registry e Cloud Build
  • Containerizza la tua app con Jib e Cloud Build
  • Esegui il deployment delle immagini container in Cloud Run

Che cosa ti serve

Sondaggio

Come utilizzerai questo tutorial?

Leggi solo Leggi e completa gli esercizi

Come giudichi la tua esperienza con Java?

Principiante Intermedio Livello avanzato

Come giudichi la tua esperienza di utilizzo dei servizi Google Cloud?

Principiante Intermedio Proficiente

2. Sfondo

I sistemi Platform as a Service (PaaS) come App Engine e Cloud Functions offrono molti vantaggi per il team e l'applicazione, ad esempio consentono agli amministratori di sistema e ai professionisti DevOps di concentrarsi sulla creazione di soluzioni. Con le piattaforme serverless, la tua app può scalare automaticamente in base alle esigenze, scalare fino a zero con la fatturazione pay-per-use per contribuire a controllare i costi e utilizzare una serie di linguaggi di sviluppo comuni.

Tuttavia, anche la flessibilità dei container è convincente. Con la possibilità di scegliere qualsiasi linguaggio, libreria e programma binario, i container offrono il meglio di entrambi i mondi: la praticità del serverless e la flessibilità dei container. Questo è l'argomento di Cloud Run.

L'apprendimento dell'utilizzo di Cloud Run non rientra nell'ambito di questo codelab, ma è trattato nella documentazione di Cloud Run. L'obiettivo è farti acquisire familiarità con la procedura di containerizzazione dell'app App Engine per Cloud Run (o altri servizi ospitati in container). Prima di procedere, devi sapere alcune cose, in particolare che la tua esperienza utente sarà leggermente diversa.

In questo codelab imparerai a creare e implementare i container. Al termine del corso sarai in grado di:

  • Containerizza la tua app con Jib
  • Eseguire la migrazione da una configurazione di App Engine
  • e, facoltativamente, definire i passaggi di compilazione per Cloud Build.

Ciò comporterà l'abbandono di alcune funzionalità specifiche di App Engine. Se preferisci non seguire questo percorso, puoi comunque eseguire l'upgrade a un runtime Java 11/17 pur mantenendo le app su App Engine.

3. Configurazione/preparazione

1. Configura il progetto

Per questo tutorial, utilizzerai un'app di esempio del repository appengine-java-migration-samples in un nuovo progetto. Assicurati che il progetto abbia un account di fatturazione attivo.

Se intendi spostare un'app di App Engine esistente in Cloud Run, puoi utilizzare l'app per continuare.

Esegui il seguente comando per abilitare le API necessarie per il tuo progetto:

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

2. Ottieni l'app di esempio di riferimento

Clona l'app di esempio sulla tua macchina o in Cloud Shell, quindi vai alla cartella baseline.

L'esempio è un'app Datastore basata su Java 8 e servlet destinata al deployment su App Engine. Segui le istruzioni nel file README su come preparare questa app per il deployment in App Engine.

3. (Facoltativo) Esegui il deployment dell'app di riferimento

Quanto riportato di seguito è necessario solo se vuoi verificare che l'app funzioni su App Engine prima della migrazione a Cloud Run.

Fai riferimento ai passaggi descritti nel file README.md:

  1. Installa/riprendi familiarità con l'interfaccia a riga di comando gcloud
  2. Inizializza l'interfaccia a riga di comando gcloud per il tuo progetto con gcloud init
  3. Crea il progetto App Engine con gcloud app create
  4. Esegui il deployment dell'app di esempio in App Engine
./mvnw package appengine:deploy -Dapp.projectId=$PROJECT_ID
  1. Verifica che l'app funzioni su App Engine senza problemi

4. Crea un repository Artifact Registry

Dopo aver containerizzato l'app, ti servirà un posto in cui eseguire il push e archiviare le immagini. Il modo consigliato per farlo su Google Cloud è utilizzare Artifact Registry.

Crea il repository denominato migration con gcloud nel seguente modo:

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

Tieni presente che questo repository utilizza il tipo di formato docker, ma sono disponibili diversi tipi di repository.

A questo punto, hai l'app App Engine di riferimento e il tuo progetto Google Cloud è pronto per la migrazione a Cloud Run.

4. Modifica file delle applicazioni

Nei casi in cui la tua app utilizzi frequentemente la configurazione, i servizi in bundle legacy di App Engine o altre funzionalità esclusive di App Engine, ti consigliamo di continuare ad accedere a questi servizi durante l'upgrade al nuovo runtime. Questo codelab mostra un percorso di migrazione per le applicazioni che utilizzano già servizi autonomi o che possono essere ristrutturate per farlo.

1. Upgrade a Java 17

Se la tua app utilizza Java 8, ti consigliamo di eseguire l'upgrade a una versione LTS candidate successiva, come 11 o 17, per non perdere gli aggiornamenti della sicurezza e accedere alle nuove funzionalità del linguaggio.

Per iniziare, aggiorna le proprietà in pom.xml in modo da includere quanto segue:

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

In questo modo, la versione del progetto verrà impostata su 17, il plug-in del compilatore verrà informato che vuoi accedere alle funzionalità del linguaggio Java 17 e che vuoi che le classi compilate siano compatibili con la JVM Java 17.

2. Includere un server web

Esistono alcune differenze tra App Engine e Cloud Run che vale la pena considerare quando si passa da uno all'altro. Una differenza è che, mentre il runtime Java 8 di App Engine fornisce e gestisce un server Jetty per le app che ospita, Cloud Run no. Utilizzeremo Spring Boot per fornirci un server web e un contenitore servlet.

Aggiungi le seguenti dipendenze:

<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 incorpora un server Tomcat per impostazione predefinita, ma questo esempio escluderà l'elemento e utilizzerà Jetty per ridurre al minimo le differenze nel comportamento predefinito dopo la migrazione. Possiamo anche configurare la versione di Jetty in modo che corrisponda a quella fornita da 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. Configurazione di Spring Boot

Sebbene Spring Boot possa riutilizzare i servlet senza modifiche, richiederà una certa configurazione per la rilevabilità.

Crea la seguente classe MigratedServletApplication.java nel pacchetto 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);
    }
}

Tieni presente che questo include l'annotazione @ServletComponentScan, che cercherà (nel pacchetto corrente per impostazione predefinita) eventuali @WebServlets e li renderà disponibili come previsto.

4. Pacchettizzazione dell'app come JAR

Sebbene sia possibile eseguire il containerizzazione dell'app con Jib a partire da un file WAR, è più facile se pacchettizzi l'app come file JAR eseguibile. Ciò non richiederà molta configurazione, in particolare per i progetti che utilizzano Maven come strumento di compilazione, poiché il packaging jar è il comportamento predefinito.

Rimuovi il tag packaging nel file pom.xml:

<packaging>war</packaging>

Poi, aggiungi 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. Migrazione da configurazione, servizi e dipendenze di App Engine

Come menzionato all'inizio del codelab, Cloud Run e App Engine sono progettati per offrire esperienze utente diverse. Alcune funzionalità offerte da App Engine, come i servizi Cron e Coda di lavoro, devono essere ricreati manualmente e verranno trattate in modo più dettagliato nei moduli successivi.

L'app di esempio non utilizza i servizi in bundle precedenti, ma gli utenti le cui app li utilizzano possono consultare le seguenti guide:

Dato che d'ora in poi eseguirai il deployment in Cloud Run, appengine-maven-plugin può essere rimosso:

<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. Containerizza applicazione

A questo punto puoi eseguire manualmente il deployment dell'app in Cloud Run direttamente dal codice sorgente. Si tratta di un'opzione eccellente che utilizza Cloud Build dietro le quinte per offrire un'esperienza di deployment senza intervento. Tratteremo i deployment delle origini in maggiore dettaglio nei moduli successivi.

In alternativa, se hai bisogno di un maggiore controllo sul modo in cui viene eseguito il deployment dell'app, puoi farlo definendo un file cloudbuild.yaml che delinei esplicitamente i passaggi di compilazione previsti:

1. Definire un file cloudbuild.yaml

Crea il seguente file cloudbuild.yaml allo stesso livello di 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']

Una volta che diciamo a Cloud Build di seguire questi passaggi, eseguirà i seguenti compiti:

  1. Esegui i test con ./mvnw test
  2. Crea, esegui il push e tagga l'immagine in Artifact Registry con Jib
  3. Esegui il deployment dell'immagine in Cloud Run con gcloud run deploy

Tieni presente che ‘visitors' viene fornito a Cloud Run come nome di servizio desiderato. Il flag –allow-unauthenticated consente agli utenti di visitare la web app senza richiedere l'autenticazione. Assicurati di sostituire PROJECT_ID con l'ID del tuo progetto nel file cloudbuild.yaml.

Aggiungi le seguenti associazioni di criteri IAM per consentire all'account di servizio Cloud Build di accedere ad 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:$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. Eseguire il processo di compilazione

Ora che hai comunicato a Cloud Build i passaggi di compilazione che ti interessano, puoi eseguire il deployment con un solo clic.

Esegui questo comando:

gcloud builds submit

Al termine del processo, l'immagine container è stata creata, archiviata in Artifact Registry ed eseguita in Cloud Run.

Al termine di questo codelab, la tua app dovrebbe avere lo stesso aspetto di quella in java17-and-cloud-run/finish.

Ecco fatto! Hai eseguito la migrazione di un'app App Engine Java 8 a Java 17 e Cloud Run e ora hai una comprensione più chiara del lavoro necessario per il passaggio e la scelta tra le opzioni di hosting.

6. Riepilogo/pulizia

Congratulazioni, hai eseguito l'upgrade, il contenimento e la migrazione della tua app. Questo tutorial è terminato.

A questo punto, il passaggio successivo è scoprire di più sulle funzionalità di sicurezza della catena di approvvigionamento del software e CI/CD ora a tua disposizione con Cloud Build:

(Facoltativo) Esegui la pulizia e/o disattiva il servizio

Se hai eseguito il deployment dell'app di esempio su App Engine durante questo tutorial, ricordati di disabilitare l'app per evitare addebiti. Quando vuoi passare al prossimo codelab, puoi riattivarlo. Quando le app App Engine sono disattivate, non generano traffico che comporta addebiti, ma l'utilizzo di Datastore potrebbe essere fatturabile se supera la quota senza costi, quindi eliminane abbastanza per rientrare in questo limite.

Se invece non intendi continuare con le migrazioni e vuoi eliminare completamente tutto, puoi eliminare il servizio o arrestare il progetto completamente.

7. Risorse aggiuntive

Problemi/feedback dei codelab del modulo di migrazione di App Engine

Se riscontri problemi con questo codelab, cerca prima il problema prima di segnalarlo. Link per cercare e creare nuovi problemi:

Risorse di migrazione

Risorse online

Di seguito sono riportate alcune risorse online che potrebbero essere pertinenti per questo tutorial:

App Engine

Altre informazioni sul cloud

Video

Licenza

Questo lavoro è concesso in licenza ai sensi di una licenza Creative Commons Attribution 2.0 Generic.