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 insegna come containerizzare un'app App Engine per eseguire il deployment nel servizio completamente gestito Cloud Run con un Dockerfile. I Dockerfile sono il metodo di deployment più pratico per questa migrazione, ma offrono anche la maggior parte delle opzioni per personalizzare il processo di compilazione.
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 che ti interessa eseguire la migrazione fa un uso intensivo dei servizi in bundle legacy di App Engine o di altre funzionalità specifiche di App Engine, la guida Accesso ai servizi in bundle di App Engine per Java 11/17 potrebbe essere un punto di partenza migliore rispetto a questo codelab.
Imparerai a utilizzare
- Utilizzare Cloud Shell
- Abilita le API Cloud Run, Artifact Registry e Cloud Build
- Containerizza la tua app con Docker, Docker e Cloud Build
- Esegui il deployment delle immagini container in Cloud Run
Che cosa ti serve
- Un progetto piattaforma Google Cloud con un account di fatturazione Google Cloud attivo e App Engine abilitato.
- Conoscenza pratica dei comandi Linux più comuni
- Conoscenza di base dello sviluppo e del deployment delle app App Engine
- Un'app servlet Java 8 di cui desideri eseguire la migrazione a Java 17 ed eseguire il deployment in Cloud Run (può essere un'app su App Engine o solo l'origine)
Sondaggio
Come utilizzerai questo tutorial?
Come giudichi la tua esperienza con Java?
Come giudichi la tua esperienza di utilizzo dei servizi Google Cloud?
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ò fare lo scale up automatico in base alle esigenze, lo scale down fino a zero con la fatturazione pay-per-use per 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 è ciò che fa di Google Cloud Run.
Imparare a utilizzare Cloud Run non rientra nell'ambito di questo codelab; a cui si applica la 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 alcuni aspetti, in particolare che la tua esperienza utente sarà leggermente diversa.
In questo codelab, imparerai a creare container ed eseguirne il deployment. Imparerai a containerizzare la tua app con un Dockerfile, eseguire la migrazione dalla configurazione di App Engine e, facoltativamente, definire i passi di build 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/pre-lavoro
1. Configura progetto
Per questo tutorial, utilizzerai un'app di esempio tratte dal 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 questo comando per abilitare le API necessarie per il tuo progetto:
gcloud services enable artifactregistry.googleapis.com cloudbuild.googleapis.com run.googleapis.com
2. Scaricare l'app di esempio di riferimento
Clona l'app di esempio sulla tua macchina o su 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 di 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 nel file README.md:
- Installa/Acquisisci familiarità con l'interfaccia a riga di comando
gcloud
- Inizializza gcloud CLI per il tuo progetto con
gcloud init
- Crea il progetto App Engine con
gcloud app create
- Esegui il deployment dell'app di esempio in App Engine
./mvnw package appengine:deploy -Dapp.projectId=$PROJECT_ID
- Verifica che l'app venga eseguita 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 è con Artifact Registry.
Crea il repository denominato migration
con gcloud in questo 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. 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 illustra un percorso di migrazione per le applicazioni che utilizzano già servizi autonomi o che è possibile eseguire il refactoring.
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>
Questo imposterà la versione del progetto su 17, informa il plugin del compilatore che si desidera accedere alle caratteristiche del linguaggio Java 17 e desidera 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à quell'artefatto e continuerà a utilizzare Jetty per ridurre al minimo le differenze nel comportamento predefinito dopo la migrazione.
3. Configurazione di Spring Boot
Anche se Spring Boot sarà in grado di riutilizzare i servlet senza modifiche, richiederà una configurazione per garantire 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 è inclusa l'annotazione @ServletComponentScan
, che cercherà (per impostazione predefinita nel pacchetto attuale) tutti i @WebServlets
e li renderà disponibili come previsto.
4. Pacchettizzazione dell'app come JAR
Sebbene sia possibile containerizzare la tua app a partire da una guerra, diventa più semplice pacchettizzarla come JAR eseguibile. Non richiede molta configurazione, in particolare per i progetti che utilizzano Maven come strumento di creazione, in quanto il comportamento predefinito è il pacchetto jar.
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à pronte all'uso di 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:
- Eseguire la migrazione da servizi in bundle per trovare servizi autonomi adatti.
- Migrazione dei file di configurazione XML in YAML, per gli utenti che eseguono la migrazione ai runtime Java 11/17 pur rimangono su App Engine.
Dato che d'ora in poi eseguirai il deployment in Cloud Run, puoi rimuovere 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. Containerizza applicazione
A questo punto sei pronto per informare Cloud Build su come creare effettivamente il container della tua applicazione. Con questo metodo di containerizzazione, non è necessario un file di configurazione di compilazione separato (cloudbuild.yaml). Possiamo semplicemente definire un Dockerfile minimo come punto di partenza:
DA eclissi-temurino
ARG JAR_FILE=JAR_FILE_MUST_BE_SPECIFIED_AS_BUILD_ARG
COPIA app.jar ${JAR_FILE}
ENTRYPOINT ["java", "-jar","/app.jar"]
Questo file Docker raggruppa la versione uber-jar del tuo servizio di avvio primaverile in un unico livello. È l'approccio più semplice alla containerizzazione Dockerfile, ma presenta una serie di svantaggi, soprattutto quando si confrontano tempi ripetuti in cui le dipendenze sono relativamente stabili. Problemi come questo sono il motivo per cui questo metodo di containerizzazione è considerato più avanzato. Tra gli aspetti positivi, tuttavia, la scrittura di un file Docker personale offre il controllo completo dell'immagine di base e l'accesso ai vantaggi in termini di prestazioni derivanti dalla scrittura di un'immagine con livelli accuratamente.
2**. Esegui il processo di compilazione**
Ora che hai informato Cloud Build sui passaggi di build desiderati, puoi eseguire il deployment con un solo clic.
Esegui questo comando:
gcloud builds submit --tag LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE_NAME
Sostituisci i valori segnaposto del comando precedente con i seguenti:
- LOCATION: la località a una o più regioni del tuo repository.
- PROJECT_ID: l'ID progetto Cloud.
- REPOSITORY: il nome del tuo repository Artifact Registry.
- IMAGE_NAME: il nome dell'immagine container.
Al termine del processo, l'immagine container è stata creata, archiviata in Artifact Registry e sottoposta a deployment in Cloud Run.
Alla fine di questo codelab, la tua app dovrebbe essere uguale a quella presente nella cartella mod4-migrazione-to-cloud-run.
Ecco fatto! Hai eseguito correttamente la migrazione di un'app Java 8 App Engine a Java 17 e Cloud Run e ora hai una migliore comprensione del lavoro necessario per passare alla scelta tra opzioni di hosting e viceversa.
6. Riepilogo/Pulizia
Complimenti, hai eseguito l'upgrade, la containerizzazione e la migrazione della tua app e per questo il tutorial è stato concluso.
Da qui, il passaggio successivo è scoprire di più sulle funzionalità di sicurezza della catena di fornitura del software e CI/CD che sono a portata di mano ora che puoi eseguire il deployment con Cloud Build:
- Creazione di passi di build personalizzati con Cloud Build
- Creazione e gestione dei trigger di build
- Utilizzo della scansione on demand nella pipeline di 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 è tutto pronto per passare al codelab successivo, puoi riabilitarlo. Sebbene le app di App Engine siano disabilitate, non riceveranno traffico che comporterà addebiti, tuttavia l'utilizzo di Datastore potrebbe essere fatturabile se supera la relativa quota senza costi, quindi eliminane un numero sufficiente per rientrare nel limite.
Se invece non intendi continuare con le migrazioni e vuoi eliminare tutto completamente, puoi eliminare il servizio o arrestare il progetto completamente.
7. Risorse aggiuntive
Problemi/feedback dei codelab per i moduli di migrazione di App Engine
Se riscontri problemi con questo codelab, cercali prima di procedere con l'invio. Link per eseguire ricerche e creare nuovi problemi:
Risorse di migrazione
- Opzioni di migrazione per la separazione dei servizi App Engine
- Configurazione dei trigger di build per Cloud Build
- Ulteriori informazioni sulla migrazione a Java 17/11
Risorse online
Di seguito sono riportate alcune risorse online che potrebbero essere pertinenti per questa esercitazione:
App Engine
- Documentazione di App Engine
- Informazioni su prezzi e quote di App Engine
- Confronto tra primo e piattaforme di seconda generazione
- Assistenza a lungo termine per i runtime legacy
Altre informazioni sul cloud
- "Sempre senza costi" di Google Cloud livello
- interfaccia a riga di comando di Google Cloud (
gcloud
CLI) - Tutta la documentazione di Google Cloud
Video
- Stazione di migrazione serverless
- Esplorazioni serverless
- Iscriviti a Google Cloud Tech
- Iscriviti a Google Developers
Licenza
Questo lavoro è concesso in licenza ai sensi di una licenza Creative Commons Attribution 2.0 Generic.