Migrazione da Go 1.11 al runtime Go più recente

Questa pagina fornisce istruzioni per eseguire la migrazione dai runtime Go di prima generazione alla seconda generazione. Per eseguire l'upgrade dell'app di seconda generazione in modo che utilizzi l'ultima versione supportata 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 a essere eseguite e riceveranno 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'ultimo runtime supportato di Go utilizzando le linee guida riportate in questa pagina.

La migrazione a un runtime Go di seconda generazione supportato ti consente di utilizzare funzionalità linguistiche aggiornate e di creare app più portabili con 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 consente di accedere a molti dei servizi in bundle legacy e delle API nei runtime di seconda generazione, come Memcache. L'app Go di seconda generazione può chiamare le API dei servizi in bundle tramite l'SDK di App Engine per Go e accedere alla maggior parte delle funzionalità del runtime Go 1.11.

    Puoi anche scegliere di utilizzare i prodotti Google Cloud che offrono funzionalità simili a quelle dei servizi in bundle legacy. Questi prodotti Google Cloud forniscono 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, consulta Migrazione da servizi in bundle.

  • Il comportamento di alcuni elementi nel 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 vengono più raggruppati con i log delle richieste, ma sono separati in record diversi. Per ulteriori informazioni sulla lettura e sulla scrittura dei log nei runtime 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 le diverse versioni delle immagini di base e le differenze nel modo in cui le due generazioni calcolano l'utilizzo della memoria.

I runtime di seconda generazione calcolano l'utilizzo della memoria dell'istanza come somma della quantità utilizzata da un processo dell'applicazione e del numero di file delle applicazioni memorizzati in modo dinamico nella memoria. Per evitare che le applicazioni che usano molta memoria subiscano arresti delle istanze a causa del superamento dei limiti di memoria, esegui l'upgrade a una classe di istanza più grande con più memoria.

Differenze di utilizzo della CPU

I runtime di seconda generazione possono registrare una base di utilizzo più elevata della CPU con l'avvio a freddo dell'istanza. A seconda della configurazione di scalabilità di un'applicazione, ciò potrebbe avere effetti collaterali imprevisti, ad esempio un conteggio delle istanze maggiore del previsto se un'applicazione è configurata per la scalabilità in base all'utilizzo della CPU. Per evitare questo problema, rivedi e testa le configurazioni di scalabilità delle applicazioni per assicurarti che il numero di istanze sia accettabile.

Differenze nell'intestazione della richiesta

I runtime di prima generazione consentono di inoltrare all'applicazione le intestazioni delle richieste con trattini bassi (ad es. X-Test-Foo_bar). I runtime di seconda generazione introducono Nginx nell'architettura host. A seguito di questa modifica, i runtime di seconda generazione sono configurati in modo da rimuovere automaticamente le intestazioni con trattini bassi (_). Per evitare problemi con l'applicazione, evita di utilizzare i trattini bassi nelle intestazioni delle richieste dell'applicazione.

Modifiche al file app.yaml

Il comportamento di alcuni elementi nel 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 ai servizi 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 i runtime di seconda generazione, utilizza questi metodi alternativi per autenticare gli utenti.
runtime Modificata Modifica l'elemento runtime in modo da specificare un runtime di seconda generazione.

Per maggiori informazioni, consulta la documentazione di riferimento di app.yaml.

Creazione di un pacchetto main in corso...

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

Scrittura di un pacchetto principale

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

  • Leggi la variabile di ambiente PORT e richiama la funzione 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:

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

  • In alternativa, importa i pacchetti dell'applicazione nel pacchetto main, assicurandoti che ogni funzione init() che contiene chiamate a http.HandleFunc() venga eseguita all'avvio.

    Puoi trovare tutti i pacchetti che utilizzano la chiamata http.HandleFunc() con il seguente script bash e copiare l'output nel blocco import del tuo pacchetto main:

    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 indicare ad App Engine dove si trova il pacchetto main utilizzando main: nel file app.yaml del tuo progetto. Ad esempio, se la struttura dei file dell'app era simile alla seguente:

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 il riferimento di app.yaml.

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 importazioni relative, ad esempio import ./guestbook, aggiorna le importazioni in modo che utilizzino il percorso completo: import github.com/example/myapp/guestbook.