Migrazione da Go 1.11 al runtime Go più recente

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

Il supporto di Go 1.11 è terminato il 30 gennaio 2024. Le applicazioni Go 1.11 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 di Go all'ultimo runtime supportato utilizzando linee guida in questa pagina.

Migrazione a un runtime Go di seconda generazione supportato consente di usare un linguaggio aggiornato e creare app più portabili con un codice idiomatico.

Modifiche ai runtime di seconda generazione

Considera le seguenti differenze quando esegui l'upgrade a un runtime Go di seconda generazione supportato:

  • Per ridurre le attività e la complessità della migrazione del runtime, l'ambiente standard di App Engine ti consente di accedere a molti dei servizi e delle API in bundle legacy nella piattaforma runtime, ad esempio Memcache. La tua app Go di seconda generazione può chiamare le API dei servizi in bundle tramite la SDK App Engine per Go e accedere alla maggior parte delle funzionalità Runtime Go 1.11.

    Hai anche la possibilità di utilizzare i prodotti Google Cloud che offrono simili a quelle dei servizi in bundle legacy. Questi progetti Google Cloud offrono librerie client Cloud per Go 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.

  • Il comportamento di alcuni elementi del file di configurazione app.yaml è stato modificato. Per ulteriori informazioni, vedi Modifiche al file app.yaml.

  • Il logging nel runtime di seconda generazione segue lo standard di logging in Cloud Logging. Nei runtime di seconda generazione, i log delle app non sono più integrati con i log delle richieste, ma sono separati in record diversi. Per scoprire di più sulla lettura e sulla scrittura dei log nel di seconda generazione, consulta la guida al logging.

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.

Modifiche al file app.yaml

Il comportamento di alcuni elementi del file di configurazione app.yaml è stato modificato:

Elemento Tipo di modifica Descrizione
app_engine_apis Obbligatorio per le app che utilizzano servizi in bundle legacy Deve essere impostato su true se vuoi accedere alle in bundle legacy per i runtime di seconda generazione.
login Supportato se app_engine_apis è true Se non utilizzi i servizi in bundle legacy per la seconda generazione utilizzare questi metodi alternativi per autenticare gli utenti.
runtime Modificato Cambia l'elemento runtime in specifica un runtime di seconda generazione.

Per ulteriori informazioni, consulta Riferimento app.yaml.

Creazione di un pacchetto main in corso...

Il servizio deve includere un'istruzione package main in almeno un'origine un file YAML. In alternativa, se il servizio utilizza google.golang.org/appengine un pacchetto, includi una chiamata a appengine.Main().

Scrittura di un pacchetto principale

Se il tuo servizio non contiene già un pacchetto main, aggiungi il metodo package main e scrivi una funzione main(). Per un minimo, la funzione main() deve:

  • Leggi la variabile di ambiente PORT e richiama http.ListenAndServe() :

    port := os.Getenv("PORT")
if port == "" {
	port = "8080"
	log.Printf("Defaulting to port %s", port)
}

log.Printf("Listening on port %s", port)
if err := http.ListenAndServe(":"+port, nil); err != nil {
	log.Fatal(err)
}

Registrazione dei gestori HTTP

Puoi registrare i tuoi gestori HTTP scegliendo una delle seguenti opzioni opzioni:

  • Il metodo preferito è spostare manualmente tutte le chiamate http.HandleFunc() dai pacchetti alla funzione main() nel pacchetto main.

  • In alternativa, importa i pacchetti della tua applicazione nel pacchetto main, assicurando che ogni funzione init() contenga chiamate a http.HandleFunc() viene eseguita all'avvio.

    Puoi trovare tutti i pacchetti che utilizzano la chiamata http.HandleFunc() con seguire lo script bash e copia l'output nella cartella main Blocco import:

    gp=$(go env GOPATH) && p=$(pwd) && pkg=${p#"$gp/src/"} && find . -name "*.go" | xargs grep "http.HandleFunc" --files-with-matches | grep -v vendor/ | grep -v '/main.go' | sed "s#\./\(.*\)/[^/]\+\.go#\t_ \"$pkg/\1\"#" | sort | uniq

Strutturazione dei file

Go richiede che ogni pacchetto abbia la propria directory. Puoi capire App Engine in cui si trova il tuo pacchetto main utilizzando main: nel tuo app.yaml del progetto. Ad esempio, se la struttura dei file dell'app ha nel seguente modo:

myapp/
├── app.yaml
├── foo.go
├── bar.go
└── web/
    └── main.go

Il file app.yaml avrebbe:

main: ./web # Relative filepath to the directory containing your main package.

Per ulteriori informazioni sul flag main, consulta app.yaml riferimento.

Spostamento dei file su GOPATH in corso...

Trova il tuo GOPATH utilizzando il seguente comando:

go env GOPATH

Sposta tutti i file e le importazioni pertinenti su GOPATH. Se utilizzi la relativa come import ./guestbook, aggiorna le tue importazioni per utilizzare percorso: import github.com/example/myapp/guestbook.