Differenze tra Go 1.11 e Go 1.12+

Nota: Go 1.11 ha raggiunto il termine del supporto il 30 gennaio 2024. Le applicazioni Go 1.11 esistenti continueranno a essere eseguite e a ricevere traffico. Tuttavia, App Engine potrebbe bloccare il nuovo deployment di applicazioni che utilizzano runtime dopo la data di fine dell'assistenza. Ti consigliamo di eseguire la migrazione all'ultima versione supportata di Go seguendo le linee guida in questa pagina.

La migrazione al runtime Go 1.12 e versioni successive consente di utilizzare funzionalità linguistiche aggiornate e di creare app più portabili, con codice idiomatico.

Modifiche al runtime di App Engine Go 1.12 e versioni successive

Se stai prendendo in considerazione una migrazione al runtime Go 1.12+, tieni presente le seguenti differenze tra Go 1.12+ e i runtime precedenti nell'ambiente standard di App Engine:

• Per ridurre lo sforzo e la complessità della migrazione del runtime, l'ambiente standard di App Engine consente di accedere a molti dei servizi e delle API in bundle legacy in runtime Go 1.12 e versioni successive, come Memcache. L'app Go 1.12 e versioni successive può chiamare le API dei servizi in bundle tramite l'SDK di App Engine per Go e accedere alla maggior parte delle stesse funzionalità del runtime Go 1.11.

  Nota: non tutti i servizi in bundle di App Engine disponibili per Go 1.11 hanno un servizio corrispondente in Go 1.12 e versioni successive. Per l'elenco completo delle API dei servizi in bundle legacy disponibili per Go 1.12 e versioni successive, consulta la documentazione sui riferimenti alle API dei servizi in bundle legacy.

  Hai anche la possibilità di utilizzare 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, ad esempio l'elaborazione di immagini, la ricerca e la messaggistica, puoi utilizzare provider di terze parti o altre soluzioni alternative.

  Per scoprire di più sulla migrazione a servizi non in bundle, consulta Migrazione dai servizi in bundle.

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

• Il logging nel runtime Go 1.12 o versioni successive segue lo standard di logging in Cloud Logging. Nel runtime Go 1.12 e versioni successive, i log delle app non sono più raggruppati con i log delle richieste, ma sono separati in record diversi. Per ulteriori informazioni sulla lettura e sulla scrittura dei log nel runtime di Go 1.12 e versioni successive, consulta la guida alla registrazione.

Differenze di utilizzo della memoria

Per i runtime di seconda generazione, la base di utilizzo della memoria è maggiore rispetto ai runtime di prima generazione. Ciò è dovuto a più fattori, ad esempio diverse versioni delle immagini di base e alle 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 di ciò che viene usato da un processo di applicazione e del numero di file dell'applicazione memorizzati nella cache in modo dinamico. Per evitare che le applicazioni che consumano 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 notare una base di utilizzo della CPU più elevata in caso di avvio a freddo delle istanze. A seconda della configurazione di scalabilità di un'applicazione, questo potrebbe avere effetti collaterali involontari, ad esempio un numero di istanze più elevato del 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à delle applicazioni per assicurarti che il numero di istanze sia accettabile.

Differenze nell'intestazione delle richieste

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 dell'applicazione, evita di utilizzare i 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	Applicabile solo a Go 1.12 e versioni successive	Deve essere impostato su true se vuoi accedere ai servizi in bundle legacy per Go 1.12 e versioni successive.
login	Supportata se app_engine_apis è true	Se non utilizzi i servizi in bundle legacy per Go 1.12 e versioni successive, utilizza questi metodi alternativi per autenticare gli utenti.
runtime	Modificato	Modifica l'elemento runtime per specificare Go 1.12+.

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 tuo servizio utilizza il pacchetto google.golang.org/appengine, includi una chiamata a appengine.Main().

Scrittura di un pacchetto principale

Se il servizio non contiene già un pacchetto main, aggiungi l'istruzione package main e scrivi una funzione main(). Come valore 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)
  }

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 tuoi pacchetti alla funzione main() del tuo 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 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 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 a questa:

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 la documentazione di riferimento 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 in GOPATH. Se utilizzi importazioni relative, ad esempio import ./guestbook, aggiorna le importazioni in modo da utilizzare il percorso completo: import github.com/example/myapp/guestbook.