Esegui la migrazione da Java 8 al runtime Java più recente

Questa pagina contiene le istruzioni per eseguire la migrazione dal da prima a seconda generazione runtime Java. Per eseguire l'upgrade dell'app di seconda generazione in modo che utilizzi l'app più recente supportata di Java, consulta l'articolo Eseguire l'upgrade di un'applicazione esistente.

Java 8 ha raggiunto la fine del supporto il 31 gennaio 2024. Le applicazioni Java 8 esistenti continueranno per eseguire e ricevere traffico. Tuttavia, App Engine potrebbe bloccare il rideployment delle applicazioni che utilizzano i runtime dopo la data di fine del supporto. Ti consigliamo di eseguire la migrazione all'ultima versione supportata di Java utilizzando le linee guida riportate in questa pagina.

Migrazione alla versione Java di seconda generazione runtime, consentono di usare funzionalità linguistiche aggiornate e di creare app portabile, con codice idiomatico.

Informazioni sulle opzioni di migrazione

Per ridurre le attività e la complessità della migrazione del runtime, l'ambiente standard di App Engine ti consente accedere a molti dei servizi e delle API in bundle legacy, come Memcache, nella seconda generazione runtime Java. La tua app Java può chiamare le API dei servizi in bundle tramite l'API App Engine JAR e accedere a gran parte delle stesse funzionalità del runtime Java 8.

Nota: non tutti i componenti App Engine in bundle disponibili per Java 8 hanno un servizio corrispondente nella runtime Java. Per l'elenco completo delle API dei servizi in bundle legacy disponibili per per i runtime Java di seconda generazione, consulta la documentazione sui riferimenti API per i servizi in bundle legacy.

Hai anche la possibilità di utilizzare i prodotti Google Cloud che offrono con funzionalità simili a quelle dei precedenti servizi in bundle. Questi progetti Google Cloud offrono librerie client Cloud per Java idiomatiche. Per i servizi in bundle che non sono disponibili come prodotti separati in Google Cloud, come elaborazione di immagini, ricerca e messaggistica, puoi utilizzare provider di terze parti o altre soluzioni alternative.

Per scoprire di più sulla migrazione ai servizi non in bundle, vedi Migrazione da servizi in bundle.

Esistono alcune differenze nella modalità di esecuzione della migrazione del runtime, a seconda se scegli di utilizzare i servizi in bundle legacy:

Migrazione ai runtime Java di seconda generazione con servizi in bundle	Migrazione a runtime Java di seconda generazione senza servizi in bundle
Accesso in bundle utilizzando il JAR delle API di App Engine.	Se vuoi, utilizza servizi di terze parti o prodotti Google Cloud consigliati.
Utilizza appengine-web.xml e web.xml per la configurazione dell'app. Potresti anche dover configurare altri file YAML a seconda delle funzionalità utilizzate dall'app.	Utilizza app.yaml per la configurazione dell'app. Potresti anche dover configurare file YAML aggiuntivi, a seconda del funzionalità utilizzate dalla tua app.
Il deployment delle app viene eseguito tramite Jetty. Utilizza il formato WAR per pacchettizzare la tua app.	Il deployment delle app viene eseguito usando il tuo server. Utilizza il formato JAR per pacchettizzare dell'app. Per scoprire di più sulla conversione del file WAR esistente in un JAR eseguibile, vedi Ripacchettizzazione di un file WAR.

Panoramica del processo di migrazione

Di seguito sono elencate alcune modifiche che potresti dover apportare alle impostazioni App Java 8 di App Engine e processo di deployment per utilizzare i runtime Java di seconda generazione:

• Scarica Google Cloud CLI.
• Esegui la migrazione dal plug-in autonomo Maven di App Engine al plug-in Maven basato su gcloud CLI o il plug-in Gradle basato sull'interfaccia a riga di comando gcloud.
• Installa JAR dell'API App Engine se utilizzi i servizi in bundle legacy.

• Esegui la migrazione dei file XML ai file yaml equivalenti.

  Nota: se prevedi di utilizzare i servizi in bundle legacy di App Engine per i runtime Java di seconda generazione, devi mantenere uno appengine-web.xml (anziché app.yaml) per configurare il server di seconda generazione app di runtime Java.

Differenze principali tra i runtime Java 8 e di seconda generazione

Di seguito un riepilogo delle differenze tra Java 8 e Java 8 di seconda generazione Runtime Java nell'ambiente standard di App Engine:

	Runtime Java 8	Runtime Java di seconda generazione
Deployment del server	Server implementato automaticamente tramite Jetty	Se la tua app non utilizza i servizi in bundle legacy, devi eseguire il deployment personalmente un server.^1
Servizi in bundle legacy di App Engine	Fornito da Google	Fornito da Google
Possibilità di utilizzare le librerie client di Cloud per Java	Sì	Sì
Supporto delle estensioni di lingua e della libreria di sistema	Sì	Sì
Accesso alla rete esterna	Sì	Sì
Accesso a Files System	Accesso in lettura/scrittura a /tmp	Accesso in lettura/scrittura a /tmp
Runtime linguaggio	Modificato per App Engine	Runtime open source non modificato
Meccanismo di isolamento	Sandbox del container basato su gVisor	Sandbox del container basato su gVisor
Test con il server di sviluppo locale	Supportato	Supportato
Configurazione di sicurezza dei thread	Può essere specificato nel file appengine-web.xml.	Non può essere specificato nei file di configurazione. Si presume che tutte le app siano sicure per i thread.^3
Logging	Utilizza un java.util.logging. ConsoleHandler, che scrive in stderr ed effettua il flush dello stream dopo ogni record.	Cloud Logging standard^2
Supporto del plug-in DataNucleus 2.x	Supportato	Non supportato^4

Note:

1. Se la tua app non utilizza i servizi in bundle legacy, il cluster I runtime Java possono eseguire qualsiasi framework Java, purché pacchettizzi configurato per rispondere alle richieste HTTP sul porta specificata dalla variabile di ambiente PORT (consigliata) oppure on la porta 8080. Ad esempio, i runtime Java di seconda generazione puoi eseguire un Uber JAR Spring Boot così com'è. Per altri esempi, consulta la sezione Flessibilità del framework.

   Se la tua app utilizza i servizi in bundle legacy, App Engine ne esegue il deployment utilizzando Jetty come nel runtime di Java 8.

2. Il logging nei runtime Java di seconda generazione segue lo standard di logging in Cloud Logging. Nei runtime Java di seconda generazione, i log delle app non sono più in bundle con i log delle richieste, ma sono separati in record diversi. Per ulteriori informazioni per saperne di più sulla lettura e sulla scrittura dei log nei runtime Java di seconda generazione, consulta il guida al logging.

3. Per configurare un'app non sicura per thread nella runtime Java di seconda generazione, in modo simile all'impostazione <threadsafe>false</threadsafe> in Java 8, imposta la contemporaneità massima su 1 nelle app.yaml oppure File appengine-web.xml se utilizzi i servizi legacy in bundle.

4. Google non supporta la libreria DataNucleus nei runtime di seconda generazione. Versioni più recenti di DataNucleus non sono compatibili con le versioni precedenti di Java 8. Per accedere a Datastore, ti consigliamo di utilizzare la libreria client in modalità Datastore o la soluzione Java Objectify (versione 6 o successive). Objectify è un'API open source per Datastore che fornisce un livello di astrazione superiore.

Differenze di utilizzo della memoria

I runtime di seconda generazione registrano una base di utilizzo della memoria più elevata rispetto ai runtime di prima generazione. Ciò è dovuto a più fattori, come diversi versioni delle immagini di base e le differenze nel modo in cui le due generazioni calcolano la memoria all'utilizzo delle risorse.

I runtime di seconda generazione calcolano l'utilizzo della memoria dell'istanza come la somma di quanto un degli utilizzi da parte del processo dell'applicazione e il numero di file delle applicazioni memorizzati in modo dinamico nella cache in memoria. Per evitare che le applicazioni che usano molta memoria utilizzino l'istanza arresti anomali dovuti al superamento dei limiti di memoria, esegui l'upgrade a una versione classe dell'istanza con più memoria.

Differenze di utilizzo della CPU

I runtime di seconda generazione possono vedere una base di utilizzo più alta della CPU al momento dell'istanza avvio a freddo. A seconda della configurazione di scalabilità di un'applicazione, effetti collaterali imprevisti, come un conteggio delle istanze più elevato del previsto è configurata per la scalabilità in base all'utilizzo della CPU. Per evitare che questo accada esaminare e testare le configurazioni di scalabilità delle applicazioni per garantire di istanze sono accettabili.

Differenze nell'intestazione della richiesta

I runtime di prima generazione consentono intestazioni delle richieste con trattini bassi (ad es. X-Test-Foo_bar) da inoltrare alla domanda. Di seconda generazione introduce Nginx nell'architettura host. Per effetto di ciò, modifica, i runtime di seconda generazione sono configurati per rimuovere automaticamente intestazioni con trattini bassi (_). Per evitare problemi con l'applicazione, evita di utilizzare trattini bassi nelle intestazioni delle richieste dell'applicazione.

Flessibilità del framework

I runtime Java di seconda generazione non includere framework per la pubblicazione sul web, a meno che tu non stia utilizzando in bundle legacy. Ciò significa che puoi utilizzare un framework diverso da uno basato su servlet. Se utilizzi i servizi in bundle legacy, i runtime Java di seconda generazione fornire il framework per la pubblicazione sul web di Jetty.

Sono disponibili hello world esempi che utilizzano i framework web Java più diffusi sulla Repository GitHub di Google Cloud:

• Stivale a molla
• Vert.x
• SparkJava
• Ktor
• Micronaut
• Quarkus

Migrazione dei formati di file XML in YAML

gcloud CLI non supporta i seguenti formati file:

• cron.xml
• datastore-index.xml
• dispatch.xml
• queue.xml

I seguenti esempi mostrano come eseguire la migrazione dei file xml in yaml file.

Migrazione automatica dei file

Beta

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Per eseguire automaticamente la migrazione dei file xml:

1. Devi avere gcloud CLI versione 226.0.0 o successiva. Per eseguire l'aggiornamento alla versione più recente:

   gcloud components update
   

2. Per ogni file di cui vuoi eseguire la migrazione, specifica uno dei seguenti sottocomandi (cron-xml-to-yaml, datastore-indexes-xml-to-yaml, dispatch-xml-to-yaml, queue-xml-to-yaml) e nome del file:

   gcloud beta app migrate-config queue-xml-to-yaml MY-QUEUE-XML-FILE.xml
   

3. Controlla manualmente il file convertito prima di eseguire il deployment in produzione.

   Per un esempio di conversione di file da xml a yaml riuscita, consulta la Schede per la migrazione manuale dei file.

Migrazione manuale dei file

Per eseguire manualmente la migrazione dei file xml ai file yaml:

cron.yaml

Crea un file cron.yaml con un oggetto cron contenente un elenco di oggetti, ciascuno con campi che corrispondono a ciascuno degli attributi del tag <cron> in il tuo file cron.xml, come mostrato di seguito.

File cron.yaml convertito:

cron:
- url: '/recache'
  schedule: 'every 2 minutes'
  description: 'Repopulate the cache every 2 minutes'
- url: '/weeklyreport'
  schedule: 'every monday 08:30'
  target: 'version-2'
  timezone: 'America/New_York'
  description: 'Mail out a weekly report'

File cron.xml originale:

<?xml version="1.0" encoding="UTF-8"?>
<cronentries>
  <cron>
    <url>/recache</url>
    <description>Repopulate the cache every 2 minutes</description>
    <schedule>every 2 minutes</schedule>
  </cron>
  <cron>
    <url>/weeklyreport</url>
    <description>Mail out a weekly report</description>
    <schedule>every monday 08:30</schedule>
    <timezone>America/New_York</timezone>
    <target>version-2</target>
  </cron>
</cronentries>

Per ulteriori informazioni, consulta la documentazione di riferimento di cron.yaml documentazione.

dispatch.yaml

Crea un file dispatch.yaml con un oggetto dispatch contenente un elenco di oggetti, ciascuno con campi che corrispondono a ciascuno del tag <dispatch> nel tuo file dispatch.xml, come mostrato di seguito.

File dispatch.yaml convertito:

dispatch:
- url: '*/favicon.ico'
  module: default
- url: 'simple-sample.uc.r.appspot.com/'
  module: default
- url: '*/mobile/*'
  module: mobile-frontend

File dispatch.xml originale

<?xml version="1.0" encoding="UTF-8"?>
<dispatch-entries>
  <dispatch>
      <url>*/favicon.ico</url>
      <module>default</module>
  </dispatch>
  <dispatch>
      <url>simple-sample.uc.r.appspot.com/</url>
      <module>default</module>
  </dispatch>
  <dispatch>
      <url>*/mobile/*</url>
      <module>mobile-frontend</module>
  </dispatch>
</dispatch-entries>

Per ulteriori informazioni, consulta la documentazione di riferimento di dispatch.yaml documentazione

index.yaml

Crea un file index.yaml con un oggetto indexes contenente un elenco di con campi che corrispondono a ciascuno degli elementi <datastore-index> nel tuo file datastore-indexes.xml, come mostrato di seguito.

File index.yaml convertito:

indexes:
- ancestor: false
  kind: Employee
  properties:
  - direction: asc
    name: lastName
  - direction: desc
    name: hireDate
- ancestor: false
  kind: Project
  properties:
  - direction: asc
    name: dueDate
  - direction: desc
    name: cost

File datastore-index.xml originale:

<?xml version="1.0" encoding="utf-8"?>
<datastore-indexes
 autoGenerate="true">
   <datastore-index kind="Employee" ancestor="false">
       <property name="lastName" direction="asc" />
       <property name="hireDate" direction="desc" />
   </datastore-index>
   <datastore-index kind="Project" ancestor="false">
       <property name="dueDate" direction="asc" />
       <property name="cost" direction="desc" />
   </datastore-index>
</datastore-indexes>

Per ulteriori informazioni, consulta la documentazione di riferimento di index.yaml documentazione.

queue.yaml

Crea un file queue.yaml con un oggetto queue contenente un elenco di oggetti, ciascuno con campi che corrispondono a ciascuno del tag <queue> nel tuo file queue.xml, come mostrato di seguito.

File queue.yaml convertito:

queue:
- name: fooqueue
  mode: push
  rate: 1/s
  retry_parameters:
    task_retry_limit: 7
    task_age_limit: 2d
- name: barqueue
  mode: push
  rate: 1/s
  retry_parameters:
    min_backoff_seconds: 10
    max_backoff_seconds: 200
    max_doublings: 0

File queue.xml originale:

<queue-entries>
  <queue>
    <name>fooqueue</name>
    <rate>1/s</rate>
    <retry-parameters>
      <task-retry-limit>7</task-retry-limit>
      <task-age-limit>2d</task-age-limit>
    </retry-parameters>
  </queue>
  <queue>
    <name>barqueue</name>
    <rate>1/s</rate>
    <retry-parameters>
      <min-backoff-seconds>10</min-backoff-seconds>
      <max-backoff-seconds>200</max-backoff-seconds>
      <max-doublings>0</max-doublings>
    </retry-parameters>
  </queue>
<queue-entries>

Attenzione: la creazione di code per il servizio coda di attività può essere gestita anche utilizzando I metodi di gestione delle code disponibili tramite l'API Cloud Tasks, ma in combinazione il metodo queue.yaml con i metodi di gestione delle code può generare risultati imprevisti e non è consigliato. Per ulteriori informazioni, vedi Utilizzo della gestione delle code e della gestione delle code.yaml.