Esegui la migrazione da Go 1.11 all'ultima versione del runtime Go

Questa pagina contiene le istruzioni per la migrazione dai runtime Go di prima generazione a quelli di seconda generazione. Per eseguire l'upgrade dell'app di seconda generazione in modo che utilizzi l'ultima versione di Go supportata, vedi Eseguire l'upgrade di un'applicazione esistente.

Go 1.11 è deprecato. Non potrai eseguire il deployment delle applicazioni Go 1.11, anche se la tua organizzazione in precedenza utilizzava un criterio dell'organizzazione per riattivare i deployment dei runtime legacy. Le applicazioni Go 1.11 esistenti continueranno a essere eseguite e a ricevere traffico. Ti consigliamo di eseguire la migrazione all'ultima versione di Go supportata.

La migrazione a un runtime Go di seconda generazione supportato ti consente di utilizzare funzionalità del linguaggio aggiornate e di creare app più portatili, con codice idiomatico.

Modifiche nei runtime di seconda generazione

Quando esegui l'upgrade a un runtime Go di seconda generazione supportato, tieni presente le seguenti differenze:

  • Per ridurre l'impegno 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 nei runtime di seconda generazione, ad esempio Memcache. La tua app Go di seconda generazione può chiamare le API dei servizi in bundle tramite l'SDK App Engine per Go e accedere alla maggior parte delle stesse funzionalità del runtime Go 1.11.

    Hai anche la possibilità di utilizzare Google Cloud prodotti che offrono funzionalità simili ai servizi in bundle legacy. Questi Google Cloud prodotti forniscono librerie client Cloud idiomatiche per Go. Per i servizi in bundle non disponibili come prodotti separati in Google Cloud, ad esempio l'elaborazione delle immagini, la ricerca e la messaggistica, puoi utilizzare provider di terze parti o altre soluzioni alternative.

    Per saperne di più sulla migrazione ai servizi non in bundle, vedi Eseguire la migrazione dai servizi in bundle.

  • Il comportamento di alcuni elementi nel file di configurazione app.yaml è stato modificato. Per saperne di più, vedi Modifiche al file app.yaml.

  • La registrazione nei runtime di seconda generazione segue lo standard di registrazione in Cloud Logging. Nei runtime di seconda generazione, i log delle app non sono più in bundle con i log delle richieste, ma sono separati in record diversi. Per saperne di più sulla lettura e la scrittura dei log nei runtime di seconda generazione, consulta la guida alla registrazione.

Differenze nella memoria utilizzata

I runtime di seconda generazione hanno una baseline di memoria utilizzata più elevata rispetto ai runtime di prima generazione. Ciò è dovuto a diversi 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 la memoria utilizzata dall'istanza come la somma di ciò che utilizza un processo dell'applicazione e del numero di file dell'applicazione memorizzati dinamicamente nella cache in memoria. Per evitare che le applicazioni che richiedono molta memoria subiscano arresti anomali dell'istanza a causa del superamento dei limiti di memoria, esegui l'upgrade a una classe di istanza più grande con più memoria.

Differenze nell'utilizzo della CPU

I runtime di seconda generazione possono avere una baseline di utilizzo della CPU più elevata all'avvio a freddo dell'istanza. A seconda della configurazione di scalabilità di un'applicazione, ciò potrebbe avere effetti collaterali indesiderati, ad esempio un numero di istanze superiore a quello previsto se un'applicazione è configurata per la scalabilità in base all'utilizzo della CPU. Per evitare questo problema, esamina e testa le configurazioni di scalabilità dell'applicazione per assicurarti che il numero di istanze sia accettabile.

Differenze nelle intestazioni delle richieste

I runtime di prima generazione consentono l'inoltro delle intestazioni delle richieste con trattini bassi (ad es. X-Test-Foo_bar) all'applicazione. I runtime di seconda generazione introducono Nginx nell'architettura host. Di conseguenza, i runtime di seconda generazione sono configurati per rimuovere automaticamente le intestazioni con trattini bassi (_). Per evitare problemi con l'applicazione, non utilizzare 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_bundled_services Obbligatorio per le app che utilizzano i servizi in bundle legacy Configura questo campo per accedere a servizi in bundle legacy specifici per le versioni di Go supportate. Per saperne di più sulle impostazioni di configurazione app_engine_bundled_services, consulta il app.yaml riferimento al file.
login Supportato se abiliti l'API Users configurando l'impostazione user nell'elenco app_engine_bundled_services. Se non utilizzi i servizi in bundle legacy per i runtime di seconda generazione utilizza questi metodi alternativi per autenticare gli utenti.
runtime Modificato Modifica l'elemento runtime per specificare un runtime di seconda generazione.

Per saperne di più, consulta il app.yaml riferimento.

Creare un pacchetto main

Il servizio deve includere un'istruzione package main in almeno un file di origine.

Servizi in bundle legacy di App Engine

Se il tuo servizio utilizza i servizi in bundle legacy per i runtime di seconda generazione:

  • Il servizio deve utilizzare solo i pacchetti v2 (google.golang.org/appengine/v2). L'utilizzo dei pacchetti v1 precedenti (google.golang.org/appengine) causa errori.

  • Nella funzione main(), chiama appengine.Main() anziché http.ListenAndServe(). In questo modo, le API user e appengine hanno accesso al contesto della richiesta corrente.

Scrivere un pacchetto main

Se il 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 chiama 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)
}

Registrare i gestori HTTP

Puoi registrare i gestori HTTP scegliendo una delle seguenti opzioni:

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

  • 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 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

Strutturare i file

Go richiede che ogni pacchetto abbia la propria directory. Puoi indicare a App Engine dove si trova il pacchetto main utilizzando main: nel file app.yaml del progetto. Ad esempio, se la struttura dei file dell'app è simile alla seguente:

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

Il file app.yaml avrà:

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

Per saperne di più sul flag main, consulta il app.yaml riferimento.

Spostare i file in GOPATH

Trova GOPATH utilizzando il seguente comando:

go env GOPATH

Sposta tutti i file e gli import pertinenti in GOPATH. Se utilizzi import relativi, ad esempio import ./guestbook, aggiorna gli import in modo che utilizzino il percorso completo: import github.com/example/myapp/guestbook.