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

1. Panoramica

Questa serie di codelab (tutorial pratici con il proprio ritmo) ha lo scopo di aiutare gli sviluppatori Java di Google App Engine (Standard) a modernizzare le loro app guidandoli attraverso una serie di migrazioni. Se segui questi passaggi, puoi aggiornare l'app per renderla più portabile e decidere di eseguirne il containerizzazione per Cloud Run, il servizio di hosting di container di Google Cloud complementare ad App Engine, e per altri servizi di hosting di container.

Questo tutorial spiega come eseguire il containerizzazione di un'app App Engine per il deployment nel servizio completamente gestito Cloud Run utilizzando Buildpack. I buildpack sono un progetto CNCF che ti consente di trasferire la tua app direttamente dal codice sorgente a immagini altamente portatili che possono essere eseguite su qualsiasi cloud.

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

Se l'applicazione di cui ti interessa eseguire la migrazione fa un uso intensivo dei servizi integrati legacy di App Engine o di altre funzionalità specifiche di App Engine, la guida Accesso ai servizi integrati di App Engine per Java 11/17 potrebbe essere più adatta di questo codelab.

Imparerai a utilizzare

  • Utilizzare Cloud Shell
  • Abilita le API Cloud Run, Artifact Registry e Cloud Build
  • Containerizza l'app utilizzando Buildpack su 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 Proficiente

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

Principiante Intermedio Proficiente

2. Sfondo

I sistemi PaaS come App Engine e Cloud Functions offrono molte comodità per il tuo team e l'applicazione, ad esempio consentendo a SysAdmin e 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 comodità del serverless e la flessibilità dei container. Questo è lo scopo di Google Cloud Run.

Imparare a utilizzare Cloud Run non rientra nell'ambito di questo codelab ed è trattato nella documentazione di Cloud Run. L'obiettivo è acquisire familiarità con la containerizzazione dell'app App Engine per Cloud Run (o altri servizi ospitati su 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. Scoprirai come eseguire la containerizzazione dell'app con Buildpack, eseguire la migrazione dalla configurazione di App Engine e definire i passaggi di compilazione per Cloud Build. Ciò comporterà l'abbandono di alcune funzionalità specifiche di App Engine. Se preferisci non seguire questa strada, puoi comunque eseguire l'upgrade a un runtime Java 11/17 mantenendo le tue app su App Engine.

3. Configurazione/pre-lavoro

1. Configura 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 App Engine esistente in Cloud Run, puoi utilizzare questa app per seguire la procedura.

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 Servlet Java 8 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

I passaggi che seguono sono necessari solo se vuoi verificare che l'app funzioni su App Engine prima di eseguire la migrazione a Cloud Run.

Fai riferimento ai passaggi 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, dovrai trovare un luogo 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 di base di App Engine e il tuo progetto Google Cloud è pronto per eseguirne la migrazione a Cloud Run.

4. Modificare i file dell'applicazione

Se la tua app utilizza molto i servizi integrati precedenti di App Engine, la configurazione o altre funzionalità solo 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, valuta la possibilità di eseguire l'upgrade a un candidato LTS successivo come 11 o 17 per stare al passo con gli aggiornamenti della sicurezza e ottenere l'accesso alle nuove funzionalità del linguaggio.

Inizia aggiornando 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. Incluso un server web

Esistono una serie di differenze tra App Engine e Cloud Run che vale la pena considerare quando passi da un servizio all'altro. Una differenza è che, mentre il runtime Java 8 di App Engine forniva e gestiva un server Jetty per le app ospitate, Cloud Run non lo fa. 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à quell'artefatto e continuerà a utilizzare Jetty per ridurre al minimo le differenze nel comportamento predefinito dopo la migrazione.

3. Configurazione di Spring Boot

Sebbene Spring Boot possa riutilizzare i servlet senza modifiche, sarà necessaria una certa configurazione per assicurarsi che siano rilevabili.

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. Configurazione build

Rimuovi la configurazione per pacchettizzare la nostra applicazione come WAR. 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 dal 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 Task Queue, devono essere ricreate manualmente e verranno trattate in modo più dettagliato nei moduli successivi.

L'app di esempio non utilizza i servizi legacy in bundle, ma gli utenti le cui app lo fanno possono fare riferimento alle 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 ed esegui il deployment dell'applicazione

A questo punto, puoi eseguire il deployment dell'app in Cloud Run direttamente dal codice sorgente. Si tratta di un'opzione eccellente che utilizza Cloud Build in background per offrire un'esperienza di deployment senza intervento. Tieni presente che per utilizzare questa funzionalità devi disporre di un account con almeno una delle seguenti autorizzazioni e aver seguito questi passaggi di configurazione dell'ambiente oppure utilizzare Cloud Shell:

Una volta soddisfatti i prerequisiti, esegui quanto segue dalla directory di origine:

gcloud run deploy SERVICE --source .

Durante l'esecuzione del comando di deployment ti verranno chieste alcune informazioni, ad esempio:

  • Fornire la posizione del codice sorgente
  • Fornire il nome del servizio
  • Attivazione dell'API Cloud Run
  • Selezionare la regione

Dopo aver risposto a questi prompt, inizia il processo di compilazione e deployment, durante il quale Cloud Build esegue le seguenti operazioni:

  • comprime e salva la sorgente in un bucket Cloud Storage
  • utilizza i buildpack della Cloud Native Computing Foundation in background per creare l'immagine
  • crea un registro per archiviare l'immagine container risultante (se non già presente)
  • e crea un servizio Cloud Run per ospitare la tua app (se non è già presente).

Al termine della compilazione e del deployment, dovresti ricevere un messaggio che ti informa che una nuova revisione è attiva e gestisce il 100% del traffico.

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) Ripulisci e/o disattiva il servizio

Se hai eseguito il deployment dell'app di esempio su App Engine durante questo tutorial, ricordati di disattivare l'app per evitare addebiti. Quando è tutto pronto per passare al codelab successivo, puoi riabilitarlo. 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 per la migrazione

Risorse online

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

App Engine

Informazioni su altri cloud

Video

Licenza

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